웹·DB·캐시를 각각 docker run으로 띄우면 컨테이너마다 긴 명령어를 외워야 하고, 네트워크를 손으로 만들어 연결해야 한다. 더 흔한 문제는 DB가 아직 안 떴는데 앱이 먼저 떠서 접속 에러로 죽는 것이다. Docker Compose는 스택 전체를 YAML 한 장에 선언하고 한 명령으로 띄운다. 멀티 컨테이너에서 실제로 발목을 잡는 건 서비스 시작 순서다. 헬스체크로 DB가 준비된 다음에 앱을 띄우는 스택을 만들고 docker compose up을 돌려 그 순서가 지켜지는지 로그로 확인한다. 출력은 Docker Compose v5.1.1에서 돌린 결과다. ...
Docker 이미지 최적화는 컨테이너 기반 애플리케이션의 빌드 시간 단축, 배포 속도 향상, 스토리지 비용 절감, 보안 취약점 감소에 직접적인 영향을 미치는 핵심 기술이다. 적절한 베이스 이미지 선택, 멀티 스테이지 빌드, 레이어 최적화 등의 기법을 적용하면 이미지 크기를 10배 이상 줄일 수 있고, 이는 CI/CD 파이프라인의 효율성과 클라우드 인프라 비용 절감에도 도움이 된다. Docker 이미지 크기 문제의 이해 왜 이미지 크기가 중요한가? Docker 이미지 크기는 빌드 시간, 푸시/풀 시간, 컨테이너 시작 시간, 스토리지 비용, 보안 공격 표면에 직접적인 영향을 미치므로, 프로덕션 환경에서 효율적인 운영을 위해서는 이미지 최적화가 필수적이다. ...
소스 코드 한 줄만 바꿨는데 빌드할 때마다 npm install이 처음부터 다시 도는 경우가 있다. 이미지는 레이어(layer)의 스택이고 Docker는 레이어 단위로 빌드 결과를 캐시하기 때문이다. 어떤 레이어가 깨지면 그 아래 레이어가 줄줄이 다시 빌드된다. 그래서 Dockerfile의 명령어 순서가 빌드 속도를 좌우한다. 아래에서는 이미지를 빌드하면서 캐시가 깨지는 순간을 docker build 로그로 확인하고, 명령어 순서가 빌드 시간을 어떻게 바꾸는지 측정한다. 모든 출력은 Docker 29.3.1에서 돌린 결과다. 이미지는 읽기 전용 레이어의 스택이다 Dockerfile의 각 명령어(RUN, COPY, ADD 등)는 직전 상태로부터의 변경분만 담은 읽기 전용 레이어를 하나씩 만든다. 컨테이너를 실행하면 이 레이어들이 OverlayFS(현재 기본 스토리지 드라이버 overlay2) 위에서 하나의 파일 시스템 뷰로 합쳐진다. ...