Dockerfiles 또는 이미지 커밋을 사용해야합니까?

이 두 가지 옵션에 대해 약간 혼란 스럽습니다. 관련이있는 것으로 보입니다. 그러나 그들은 실제로 호환되지 않습니다.

예를 들어 Dockerfiles를 사용하면 실제로 이미지에 커밋해서는 안되는 것 같습니다. git에서 Dockerfile을 실제로 추적하고 변경해야하기 때문입니다. 그렇다면 권위있는 것에 대한 모호성이 없습니다.

그러나 이미지 커밋은 정말 멋져 보입니다. 컨테이너를 직접 수정하고 변경 사항에 태그를 지정하여 다른 이미지를 만들 수 있다는 점이 정말 대단합니다. 이미지 커밋 기록에서 파일 시스템 차이와 같은 것을 얻을 수도 있다는 것을 이해합니다. 대박. 그러나 Dockerfiles를 사용해서는 안됩니다. 그렇지 않으면 이미지 커밋을 수행 한 경우 Dockerfile로 돌아가서 수행 한 작업을 나타내는 몇 가지 변경 작업을 수행해야합니다.

그래서 나는 찢어졌습니다. 이미지 커밋이라는 아이디어가 마음에 듭니다. Dockerfile에서 이미지 상태를 표시 할 필요가 없습니다. 바로 추적 할 수 있습니다. 그러나 이미지에있는 내용에 대한 빠른 개요를 제공하는 일종의 매니페스트 파일에 대한 아이디어를 포기하는 것이 불편합니다. 동일한 소프트웨어 패키지에서 호환되지 않는 두 가지 기능을 보는 것도 당황 스럽습니다.

누구든지 이것에 대해 생각이 있습니까? 이미지 커밋을 사용하는 것이 나쁜 습관으로 간주됩니까? 아니면 Puppet 시절의 파일을 매니페스트하기 위해 첨부 파일을 놓아야합니까? 어떻게해야합니까?

업데이트 :

이것이 의견 기반 질문이라고 생각하는 모든 사람들에게 나는 그렇게 확신하지 못합니다. 주관적인 특성이 있지만 대부분 객관적인 질문이라고 생각합니다. 또한이 주제에 대한 좋은 토론이 유익 할 것이라고 믿습니다.

결국이 게시물을 읽는 사람이 Dockerfile과 이미지 커밋이 서로 어떻게 관련되어 있는지 더 잘 이해할 수 있기를 바랍니다.

업데이트-2017/7/18 :

최근에 이미지 커밋의 합법적 인 사용을 발견했습니다. 회사에서 CI 파이프 라인을 설정하기 만하면 파이프 라인의 한 단계에서 앱 테스트가 컨테이너 내부에서 실행됩니다. 테스트 실행기 프로세스가이를 생성하고 (컨테이너의 파일 시스템에서) 컨테이너가 실행을 중지 한 후 종료 된 컨테이너에서 커버리지 결과를 검색해야합니다. 중지 된 컨테이너를 커밋하여 새 이미지를 만든 다음 커버리지 파일을 표시하고 stdout에 덤프하는 명령을 실행하여 이미지 커밋을 사용합니다. 그래서 이것을 갖는 것이 편리합니다. 이 매우 특정한 경우와는 별도로 Dockerfile을 사용하여 환경을 정의합니다.

Dockerfile은 이미지를 만드는 데 사용되는 도구입니다.

실행 결과는 docker build .커밋이있는 이미지이므로 commit 을 생성하지 않고 Dockerfile을 사용할 수 없습니다 . 문제는 어떤 것이 변경 될 때마다 이미지를 수동으로 업데이트 하여 황금 이미지의 저주에 자신을 파멸 시켜야한다는 것입니다 .

황금 이미지의 저주는 소프트웨어를 실행하기 위해 버그가있는 보안 구멍을 타는 기본 이미지로 계속 살아야하는 사람들에게 주어지는 끔찍한 저주입니다. 왜냐하면 그것을 만든 사람이 오래 전에 고대인에게 삼켜 졌거나 새로운 직업) 그리고 그 이미지에 들어간 imagemagic 버전을 어디서 얻었는지 아무도 모릅니다. 그리고 사장의 아들이 3 년 전에 고용 한 컨설턴트가 제공 한 C ++ 모듈과 연결되는 유일한 것입니다. 어쨌든 상관 없습니다. 왜냐하면 imagemagic이 사용하는 libstdc ++ 버전에서 어디서 왔는지 알아 내더라도 JNI는 지원 도구에서 긴 머리를 가진 인턴이 어쨌든 지원되지 않는 버전의 우분투에만 존재한다고 호출합니다.

솔루션의 장점과 불편 함을 모두 아는 것은 좋은 시작입니다. 두 가지를 혼합하는 것이 아마도 유효한 방법이기 때문입니다.

단점 : 골든 이미지 막 다른 골목을 피하십시오 .

이미지를 다시 빌드하는 방법을 잊어 버린 경우 커밋 만 사용하는 것은 좋지 않습니다. 이미지를 다시 빌드 할 수없는 상태를 원하지는 않습니다 . 이 최종 상태를 황금 이미지 라고합니다. 이미지는 각 단계에서 유일한 참조, 시작 지점 및 끝 지점입니다. 풀면 재건 할 수 없기 때문에 많은 문제가 발생합니다. 치명적인 막 다른 길은 언젠가는 새 시스템을 다시 빌드해야한다는 것입니다 (예를 들어 모든 시스템 라이브러리가 쓸모 없기 때문입니다). 무엇을 설치해야할지 모를 것입니다. 결국 시간이 많이 낭비됩니다.

참고로 , 히스토리 로그가 git에서와 같이 쉽게 사용 가능하다면 (diffs를 참조하고 다른 이미지에서 반복) 커밋보다 커밋을 사용하는 것이 더 좋을 것입니다. 이 딜레마.

장점 : 배포를위한 매끄러운 업그레이드

반면에, 계층화 커밋은 분산 업그레이드 측면에서 상당한 이점이 있으므로 대역폭 및 배포 시간에있어 상당한 이점이 있습니다. 제빵사가 팬케이크 (정확히도 커가 허용하는 것)를 처리 할 때 도커 이미지를 처리하기 시작하거나 테스트 버전을 즉시 배포하려는 경우, 작은 커밋 형식으로 작은 업데이트를 보내는 것이 더 기쁠 것입니다. 완전히 새로운 이미지. 특히 버그 수정을 조만간 자주 배포해야하는 고객을 위해 지속적으로 통합하는 경우.

두 가지 세계를 최대한 활용하십시오.

이러한 유형의 시나리오에서는 이미지의 주요 버전 에 태그를 지정하고 싶을 것입니다.Dockerfiles . 또한 태그가 지정된 버전을 기반으로 한 커밋 덕분에 지속적인 통합 버전을 제공 할 수 있습니다. 이는 Dockerfiles 및 계층화 커밋 시나리오의 장점과 불편 함을 완화합니다. 여기서 핵심은 이미지에 대해 수행 할 수있는 커밋 수를 제한하여 이미지 추적을 중단하지 않는다는 것입니다.

따라서 시나리오에 따라 다르며 단일 규칙을 찾으려고 시도해서는 안됩니다. 그러나 솔루션이 무엇이든간에 실제로 피해야 할 몇 가지 막 다른 골목이있을 수 있습니다 ( "골든 이미지"시나리오로 끝남).