도커 태그 버전 관리에 대한 모범 사례는 무엇입니까?

최근에 CI 서버를 연결하여 자식 커밋시 도커 이미지를 빌드했습니다.

각각 고유 한 언어 / 프레임 워크를 가진 약 8 가지 컨테이너가 있습니다. 일부는 node이고 package.json을 가지고 있고, 다른 것은 의미 버전 정보가없는 파이썬 서비스입니다.

내 질문은 태그를 만드는 방법, 태그의 값을 만드는 방법에 관한 것이 아닙니다.

각 태그에 특정 이미지의 고유 한 의미 버전 번호가 있는지 확인하는 방법 빌드 버전을 추적 / 증가하는 권한은 누구에게 있습니까?

dmaze가 공식 forums.docker.com 에서 응답 한 내 게시물 Coupling docker 레지스트리 및 소스 제어 로 안내 합니다. 커밋 해시 및 분기 이름 또는 태그가 충분합니다.

Dockerfile에서 LABEL을 사용하여 빌드 소스를 기록하십시오. 분산 소스 제어 (git, Mercurial)의 커밋 해시, 관련이있는 브랜치 이름, 존재하는 경우 모든 릴리스 태그 및 마지막 커밋의 타임 스탬프와 같은 세부 사항이 포함됩니다. docker history 및 docker inspect는 이것을 보여줄 수 있어야합니다.

도 커가 이미지를 푸시 할 때 커밋 해시와 분기 이름을 "버전"부분 (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test)으로 두 번 이상 푸시합니다. ). 릴리스 태그를 쉽게 사용할 수 있으면 CI 시스템에서 이러한 태그가있는 이미지도 푸시해야합니다.

현재 지점 이름 / 커밋 해시 조합을 사용하고 있습니다. 우리에게는 충분 해 보입니다. 타임 스탬프는 유용한 반면 IMO는 커밋 해시가 제공하지 않는 것을 제공하지 않기 때문에 혼란을 더합니다.

나는 030 에 동의합니다 :

빌드 버전을 추적 / 증가하는 권한을 가진 사람

100 %는 다른 팀간에 적절한 의사 소통을 통해 CI를 유지 관리 할 책임이 있습니다.

각 태그에 특정 이미지의 고유 한 의미 버전 번호가 있는지 확인하는 방법

타임 스탬프, git commit 해시 및 시맨틱 버전의 조합과 같은 여러 요소로 구성된 태그를 만들 수 있습니다. 후자는 수동으로 설정해야하며 처음 두 개는 자동화 할 수 있습니다. 이러한 태그는 다음과 같습니다.

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

이 태그에는 빌드 날짜, 커밋 및 시맨틱 버전이 포함됩니다. 도커 이미지가 프로덕션 환경에서 실행되고 버그가 발견되면 제품의 버전, 이미지의 내부 및시기 및 이미지가 작성된 환경을 알 수 있습니다.

빌드 버전을 추적 / 증가하는 권한은 누구에게 있습니까?

제 생각에는 이것이 프로세스를 자동화 할 수 있고 태그 생성을 자동화 할 수 있기 때문에 CI의 책임이어야합니다. 이러한 도구는 작업에 적합한 도구입니다.

Jenkins와 같은 CI / CD 용 DevOps 도구 중 하나를 사용한다고 가정합니다. 다음과 같은 접근법을 제안합니다.

Jenkins와 같은 것을 사용하면

• Jenkins 환경 변수 "BUILD_ID"를 사용하여 작업을 구성하여 이미지에 태그를 지정하도록 트리거 될 때 작업의 빌드 ID를 검색 할 수 있습니다. 이렇게하면 도커 이미지를 버전 제어 할 수 있습니다. 아래 예를 확인하십시오.

전의:- sudo docker build -t <image_name>:<BUILD_ID>

따라서 SCM에 대한 태그와 같은 메커니즘이있는 경우 작업 기반 빌드 또는 JENKINS HOME_FOLDER에있는 빌드 ID의 config.xml에서 각 빌드 ID의 태그를 확인할 수 있습니다.