KOMAS

Data

Docker에서 볼륨을 지정할 때, -v 옵션 뒤에 경로가 아닌 단순한 문자열(예: myvolume)을 지정하면, 

Docker는 이를 네임드 볼륨(named volume)으로 간주합니다. 반면에 슬래시(/)를 포함한 경로 형태(예: /path/on/host:/path/in/container)를 지정하면 바인드 마운트(bind mount)로 간주합니다.

예를 들면:

네임드 볼륨:
docker run -v myvolume:/path/in/container my_image
위의 명령어는 myvolume이라는 네임드 볼륨을 컨테이너의 /path/in/container 위치에 마운트합니다.

바인드 마운트:
docker run -v /path/on/host:/path/in/container my_image
위의 명령어는 호스트의 /path/on/host 디렉토리를 컨테이너의 /path/in/container 위치에 마운트합니다.

결론적으로, 슬래시(/)가 없는 단순한 문자열을 지정하면 Docker는 이를 네임드 볼륨으로 인식합니다.

바인드 마운트

호스트의 특정 디렉토리를 컨테이너에 마운트합니다.
-v 왼쪽경로디렉토리(로컬):오른쪽 경로디렉토리(컨테이너)
이 명령어를 사용하여 호스트의 디렉토리를 컨테이너에 마운트합니다.
주의점으로 bind mount가 컨테이너 내부의 폴더에 우선시 되므로, 기존에 컨테이너 안에 있던 데이터가 덮어쓰일 수 있습니다.
로컬 디렉토리가 우선되며, 로컬을 변경하면 컨테이너에 즉시 반영

도커 파일 캐싱

Docker는 이미지를 빌드할 때 효율적으로 처리하기 위해 캐싱 메커니즘이 있습니다.

Dockerfile의 각 줄은 독립적인 레이어로 생성되며, 이전에 빌드했을 때 변경되지 않은 레이어는 캐싱되어 재사용됩니다.

이 Dockerfile을 처음 빌드할 때, 모든 단계가 실행되어 새 이미지가 생성됩니다. 

하지만 COPY 단계에서 소스 코드에 변경사항이 발생하면, 이후의 모든 단계는 캐시를 사용하지 않고 다시 실행됩니다.

캐싱 전략
변경 빈도가 높은 단계는 Dockerfile의 하단에 위치시키는 것이 좋습니다. 

그렇게 하면 변경 빈도가 낮은 단계는 최대한 캐싱을 활용할 수 있습니다.

예를 들어, 애플리케이션의 종속성을 설치하는 단계와 소스 코드를 복사하는 단계가 있다면, 

종속성 설치 단계를 먼저 위치시키고 소스 코드 복사 단계를 그 이후에 위치시키는 것이 좋습니다. 

그러면 종속성 변경이 없는 경우에는 캐싱을 효율적으로 활용할 수 있습니다.

도커 컴포즈의 목적

다중 컨테이너 관리: docker-compose는 여러 서비스로 구성된 애플리케이션을

각 서비스의 이미지, 환경 변수, 포트, 볼륨 등을 설정

의존성 관리: 서비스 간의 의존 관계를 정의

예를 들어, 백엔드 서비스가 데이터베이스 서비스를 필요로 할 경우,

docker-compose를 사용하여 백엔드가 데이터베이스가 준비된 후에 시작

일관된 환경: 개발, 테스팅, 스테이징, 프로덕션 등 다양한 환경에서

동일한 docker-compose.yml 파일을 사용하여 애플리케이션을 실행

한 번의 명령으로 서비스 관리: 

docker-compose up 명령을 사용하여 모든 서비스를 시작하거나 

docker-compose down 명령을 사용하여 모든 서비스를 종료

이미지 다운로드: docker-compose를 사용하면 docker-compose.yml에 정의된 모든 이미지를 

한 번의 명령으로 다운로드 (docker-compose pull). 

배포 순서: ci.yml build -> docker-compose.yml -> cd.yml deploy