Docker 이미지는 불변(immutable)입니다. 한 번 빌드되면 변경되지 않으며, 이 덕분에 일관성·예측 가능성·안정성이 보장됩니다. 동일한 이미지로 생성된 모든 컨테이너는 똑같이 작동하고, 버전 관리도 안전하고 간편해집니다.
하지만 실행 중인 컨테이너 안에서 패키지를 설치하거나 설정을 바꿔야 할 때는 어떻게 해야 할까요? 바로 이럴 때 docker commit이 유용합니다. 이 명령은 실행 중인 컨테이너의 변경 사항을 캡처해 원본 이미지는 전혀 건드리지 않은 채 새로운 이미지를 만들어 줍니다. 수정 사항 테스트, 빠른 반복 작업, 처음부터 다시 빌드하지 않는 커스텀 이미지 배포에 딱 맞는 도구입니다.
Docker 이미지가 변경되지 않는 이유
Docker 이미지는 여러 개의 읽기 전용(read-only) 레이어로 구성됩니다. 컨테이너를 실행하면 Docker는 그 위에 '컨테이너 레이어'라는 얇은 쓰기 가능한 레이어를 추가합니다. 사용자가 만드는 모든 변경 사항은 이 최상위 레이어에만 기록됩니다. 컨테이너가 삭제되면 이 레이어의 변경 내용도 함께 사라지고, 원본 이미지는 그대로 유지됩니다.
이러한 설계는 다음과 같은 이점을 제공합니다.
- 동일한 이미지로 만든 모든 컨테이너가 같게 작동하여 일관성을 보장합니다.
- 한 컨테이너의 변경이 다른 컨테이너에 영향을 주지 않아 예측 가능성을 높입니다.
- 특정 이미지 버전을 위험 부담 없이 안전하게 태그할 수 있습니다.
훌륭한 안정성을 제공하는 설계이지만, 실행 중인 컨테이너에 빠르게 변경을 가하고 싶을 때는 제약이 됩니다. 그래서 docker commit이 필요합니다.
실행 중인 컨테이너로 새 이미지 만들기
docker commit 명령을 실행하면 Docker는 실행 중인 컨테이너의 현재 상태를 캡처해 새 이미지를 생성합니다. 컨테이너 파일 시스템의 스냅샷을 찍어, 설치한 패키지·수정한 설정·변경한 파일 등을 새 이미지 레이어로 저장합니다. 원본 이미지는 그대로 남아 있으므로 자유롭게 실험하고 빠르게 반복 작업을 진행할 수 있습니다.
이 기능은 다음과 같은 상황에 특히 유용합니다.
- 향후 재사용을 위한 커스텀 베이스 환경 저장
- 테스트 과정에서의 소소한 수정 및 설정 변경 적용
- Dockerfile을 처음부터 다시 작성하지 않고 팀과 업데이트된 이미지 공유
새 이미지를 만드는 기본 문법은 다음과 같습니다.
docker commit [OPTIONS] CONTAINER_ID NEW_IMAGE_NAME[:TAG]CONTAINER_ID는 캡처할 컨테이너의 ID 또는 이름, NEW_IMAGE_NAME은 새 이미지의 이름이며, TAG는 선택 사항으로 기본값은 latest입니다.
참고: docker commit은 docker container commit의 레거시 별칭으로, 두 명령은 완전히 동일하게 작동합니다.
주요 옵션 정리
docker commit은 메타데이터 추가, 설정 변경, 커밋 동작 제어를 위한 다양한 옵션을 제공합니다.
| 옵션 | 긴 형식 | 설명 | 예시 |
|---|---|---|---|
| -a | --author | 새 이미지 메타데이터에 작성자 이름을 추가합니다. | docker commit -a "Anees" my-container my-image |
| -c | --change | ENV, LABEL, CMD 같은 Dockerfile 지시문을 새 이미지에 적용합니다. | docker commit -c "ENV APP_ENV=prod" my-container my-image |
| -m | --message | 변경 내용을 설명하는 짧은 메시지를 추가합니다. | docker commit -m "Installed curl" my-container my-image |
| -p | --pause | 일관성을 위해 커밋 중 컨테이너를 일시 중지합니다.(기본값: true) | docker commit --pause=false my-container my-image |
docker commit 실습 따라 하기
Dockerfile을 다시 빌드하지 않고 Alpine 컨테이너에 curl을 설치하는 예제를 살펴보겠습니다. 먼저 베이스 이미지로 컨테이너를 실행합니다.
docker run -it alpine:latest /bin/sh컨테이너에 접속했다면 필요한 변경을 수행합니다.
apk update && apk add curl
작업이 끝나면 컨테이너를 종료합니다.
exit그다음 컨테이너를 새 이미지로 커밋합니다.
docker commit <CONTAINER_ID> alpine-with-curl:1.0
새 이미지가 잘 생성되었는지 확인해 보겠습니다.
docker images이제 curl이 미리 설치된 새 이미지가 준비되었으며, 어디서든 바로 실행할 수 있습니다.
새 이미지를 실행해 저장된 변경 사항 검증하기
새 이미지를 만든 후에는 해당 이미지로 컨테이너를 실행해 변경 사항이 제대로 저장되었는지 확인할 수 있습니다.
docker run -it alpine-with-curl:1.0 /bin/sh이 명령은 alpine-with-curl:1.0 이미지 기반 컨테이너 안에서 대화형 셸을 열어 줍니다. 접속한 뒤 아래 명령으로 수정 사항이 그대로 유지되었는지 확인하세요.
curl --versioncurl 버전 정보가 출력되면, 변경 사항이 새 이미지에 성공적으로 저장된 것입니다.
docker commit vs Dockerfile: 무엇을 언제 써야 할까?
Dockerfile과 docker commit은 모두 Docker 이미지를 만들 수 있지만, 작동 방식이 크게 다르고 각각 어울리는 상황도 다릅니다.
Dockerfile은 신뢰할 수 있고 재현 가능한 빌드가 필요할 때 최선의 선택입니다. 특히 CI/CD 파이프라인이나 프로덕션 환경에 적합합니다. 모든 변경 사항이 코드로 명확히 정의되어 있어 추적·검토·버전 관리가 쉽고, 누가 빌드하더라도 항상 동일한 결과를 얻을 수 있습니다. 장기적인 유지보수와 팀 협업에는 필수적인 방식입니다.
반면 docker commit은 Dockerfile 전체를 다시 작성하거나 재빌드하지 않고 빠르게 시도해 볼 긴급 수정, 테스트, 소소한 조정에 적합합니다. 실험, 디버깅, 즉석 변경 검증에 유용하지만, 변경 내역이 파일로 문서화되지 않기 때문에 프로덕션이 아닌 단기적인 용도에 더 알맞습니다.
정리하자면, docker commit은 실험이나 임시 수정용으로 활용하고, 프로덕션용 이미지는 반드시 Dockerfile로 관리하는 것이 좋습니다. Docker를 더 깊이 활용하고 싶다면 컨테이너·이미지·워크플로우 작업을 편하게 해 주는 다른 핵심 명령어들도 함께 익혀두는 것을 추천합니다.