🥇werf 수집기의 콘텐츠 기반 태그 지정: 왜 그리고 어떻게 작동하나요?

워프 Kubernetes에 애플리케이션을 구축하고 제공하기 위한 오픈 소스 GitOps CLI 유틸리티입니다. 안에 릴리스 v1.1 이미지 수집기에 새로운 기능이 도입되었습니다. 콘텐츠별로 이미지에 태그를 지정하거나 콘텐츠 기반 태그 지정. 지금까지 werf의 일반적인 태깅 방식에는 Git 태그, Git 브랜치 또는 Git 커밋을 통해 Docker 이미지에 태그를 지정하는 것이 포함되었습니다. 그러나 이러한 모든 방식에는 새로운 태그 지정 전략으로 완전히 해결되는 단점이 있습니다. 이에 대한 자세한 내용과 이것이 왜 그렇게 좋은지는 아래에 나와 있습니다.

하나의 Git 저장소에서 마이크로서비스 세트 롤아웃

애플리케이션이 다소 독립적인 서비스로 분할되는 경우가 종종 발생합니다. 이러한 서비스의 릴리스는 독립적으로 발생할 수 있습니다. 한 번에 하나 이상의 서비스가 릴리스될 수 있으며 나머지 서비스는 변경 없이 계속 작동해야 합니다. 그러나 코드 저장 및 프로젝트 관리의 관점에서 보면 이러한 애플리케이션 서비스를 단일 저장소에 보관하는 것이 더 편리합니다.

서비스가 진정으로 독립적이고 단일 애플리케이션과 연결되지 않는 상황이 있습니다. 이 경우 별도의 프로젝트에 위치하게 되며, 릴리스는 각 프로젝트에서 별도의 CI/CD 프로세스를 통해 수행됩니다.

그러나 실제로 개발자는 단일 애플리케이션을 여러 마이크로서비스로 분할하는 경우가 많지만 각각에 대해 별도의 저장소와 프로젝트를 만드는 것은 분명 과잉입니다. 더 자세히 논의할 상황은 바로 이 상황입니다. 이러한 여러 마이크로서비스는 단일 프로젝트 저장소에 위치하며 릴리스는 CI/CD의 단일 프로세스를 통해 발생합니다.

Git 브랜치 및 Git 태그로 태그 지정

가장 일반적인 태그 지정 전략이 사용된다고 가정해 보겠습니다. 태그 또는 분기. Git 브랜치의 경우 이미지에는 브랜치 이름으로 태그가 지정됩니다. 한 번에 하나의 브랜치에는 해당 브랜치 이름으로 게시된 이미지가 하나만 있습니다. Git 태그의 경우 태그 이름에 따라 이미지에 태그가 지정됩니다.

새 버전이 출시되는 등 새 Git 태그가 생성되면 Docker 레지스트리의 모든 프로젝트 이미지에 대해 새 Docker 태그가 생성됩니다.

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

이러한 새 이미지 이름은 Helm 템플릿을 통해 Kubernetes 구성으로 전달됩니다. 명령으로 배포를 시작할 때 werf deploy 필드를 업데이트하는 중입니다. image Kubernetes 리소스 매니페스트에서 변경된 이미지 이름으로 인해 해당 리소스를 다시 시작합니다.

문제: 실제로 이전 롤아웃(Git 태그) 이후 이미지의 내용이 변경되지 않고 Docker 태그만 변경된 경우에 이런 일이 발생합니다. 이상한 이 애플리케이션을 다시 시작하면 가동 중지 시간이 발생할 수 있습니다. 이 재시작을 수행할 실제 이유는 없었지만.

결과적으로, 현재 태그 지정 체계를 사용하면 여러 개의 개별 Git 저장소를 보호해야 하며 이러한 여러 저장소의 롤아웃을 구성하는 데 문제가 발생합니다. 일반적으로 이러한 계획은 과부하되고 복잡합니다. 불필요한 재시작이 발생하지 않도록 많은 서비스를 단일 리포지토리로 결합하고 Docker 태그를 생성하는 것이 좋습니다.

Git 커밋으로 태그 지정

werf에는 Git 커밋과 관련된 태그 지정 전략도 있습니다.

Git-commit은 Git 저장소의 콘텐츠에 대한 식별자이며 Git 저장소의 파일 편집 기록에 따라 달라지므로 Docker 레지스트리에서 이미지에 태그를 지정하는 데 이를 사용하는 것이 논리적인 것 같습니다.

그러나 Git 커밋으로 태그를 지정하는 것은 Git 브랜치나 Git 태그로 태그를 지정하는 것과 동일한 단점이 있습니다.

파일을 변경하지 않는 빈 커밋을 생성할 수 있지만 이미지의 Docker 태그는 변경됩니다.
파일을 변경하지 않는 병합 커밋을 생성할 수 있지만 이미지의 Docker 태그는 변경됩니다.
이미지로 가져오지 않은 Git의 파일을 변경하는 커밋이 이루어질 수 있으며 이미지의 Docker 태그가 다시 변경됩니다.

태그 지정 Git 분기 이름에 이미지 버전이 반영되지 않습니다.

Git 브랜치의 태그 지정 전략과 관련된 또 다른 문제가 있습니다.

해당 브랜치의 커밋이 시간순으로 순차적으로 수집되는 한 브랜치 이름별 태그 지정이 작동합니다.

현재 체계에서 사용자가 특정 분기와 관련된 이전 커밋을 다시 빌드하기 시작하면 werf는 해당 Docker 태그를 사용하여 이전 커밋에 대해 새로 빌드된 이미지 버전으로 이미지를 다시 작성합니다. 이제부터 이 태그를 사용하는 배포에서는 포드를 다시 시작할 때 다른 버전의 이미지를 가져올 위험이 있으며, 그 결과 애플리케이션이 CI 시스템과의 연결이 끊어지고 동기화가 해제됩니다.

또한 짧은 시간 간격을 두고 하나의 브랜치에 연속적으로 푸시하면 이전 커밋이 새 커밋보다 늦게 컴파일될 수 있습니다. 이전 버전의 이미지는 Git 브랜치 태그를 사용하여 새 버전을 덮어씁니다. 이러한 문제는 CI/CD 시스템으로 해결할 수 있습니다(예를 들어 GitLab CI에서는 후자의 파이프라인이 일련의 커밋을 위해 시작됩니다). 그러나 모든 시스템이 이를 지원하는 것은 아니며 이러한 근본적인 문제를 방지할 수 있는 보다 안정적인 방법이 있어야 합니다.

콘텐츠 기반 태그란 무엇입니까?

그렇다면 콘텐츠 기반 태그란 무엇입니까? 콘텐츠별로 이미지에 태그를 지정하는 것입니다.

Docker 태그를 생성하기 위해 사용되는 것은 Git 기본 요소(Git 분기, Git 태그...)가 아니라 다음과 관련된 체크섬입니다.

이미지의 내용. 이미지 ID 태그는 해당 내용을 반영합니다. 새 버전을 빌드할 때 이미지의 파일이 변경되지 않은 경우 이 식별자는 변경되지 않습니다.
Git에서 이 이미지를 생성한 내역. Werf를 통해 다양한 Git 브랜치 및 다양한 빌드 기록과 연결된 이미지에는 다양한 ID 태그가 있습니다.

이러한 식별자 태그는 소위 이미지스테이지 사인.

각 이미지는 일련의 단계로 구성됩니다. from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch 등. 각 단계에는 해당 내용을 반영하는 식별자가 있습니다. 무대 서명 (무대 사인).

이러한 단계로 구성된 최종 이미지에는 소위 이러한 단계 세트의 시그니처라는 태그가 지정됩니다. 무대 서명, - 이는 이미지의 모든 단계에 대해 일반화됩니다.

구성의 각 이미지에 대해 werf.yaml 일반적으로 자체 서명과 이에 따른 Docker 태그가 있습니다.

무대 서명은 이러한 모든 문제를 해결합니다.

빈 Git 커밋에 강합니다.
이미지와 관련이 없는 파일을 변경하는 Git 커밋에 저항합니다.
브랜치의 이전 Git 커밋에 대한 빌드를 다시 시작할 때 이미지의 현재 버전을 정밀 검사하는 문제가 발생하지 않습니다.

이는 이제 권장되는 태그 지정 전략이며 모든 CI 시스템에 대한 werf의 기본값입니다.

werf에서 활성화하고 사용하는 방법

이제 명령에 해당 옵션이 있습니다. werf publish: --tag-by-stages-signature=true|false

CI 시스템에서 태그 지정 전략은 다음 명령으로 지정됩니다. werf ci-env. 이전에는 매개변수가 정의되었습니다. werf ci-env --tagging-strategy=tag-or-branch. 이제 지정하면 werf ci-env --tagging-strategy=stages-signature 또는 이 옵션을 지정하지 않으면 werf는 기본적으로 태그 지정 전략을 사용합니다. stages-signature. 팀 werf ci-env 명령에 필요한 플래그를 자동으로 설정합니다. werf build-and-publish (또는 werf publish)이므로 이러한 명령에는 추가 옵션을 지정할 필요가 없습니다.

예를 들어 다음 명령은 다음과 같습니다.

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...다음 이미지를 생성할 수 있습니다.

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

여기에 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d 이미지 단계의 시그니처입니다. backend과 f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - 이미지 단계의 서명 frontend.

특수 기능을 사용할 때 werf_container_image и werf_container_env Helm 템플릿에서는 아무 것도 변경할 필요가 없습니다. 이러한 함수는 자동으로 올바른 이미지 이름을 생성합니다.

CI 시스템의 구성 예:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

구성에 대한 자세한 내용은 다음 설명서에서 확인할 수 있습니다.

전체로

새로운 옵션 werf publish --tag-by-stages-signature=true|false.
새로운 옵션 값 werf ci-env --tagging-strategy=stages-signature|tag-or-branch (지정하지 않으면 기본값은 stages-signature).
이전에 Git 커밋에 태그 지정 옵션을 사용한 경우(WERF_TAG_GIT_COMMIT 또는 옵션 werf publish --tag-git-commit COMMIT) 그런 다음 태그 지정 전략으로 전환하세요. 스테이지 시그니처.
새 프로젝트를 새 태그 지정 체계로 즉시 전환하는 것이 좋습니다.
werf 1.1로 이전할 때 기존 프로젝트를 새로운 태그 지정 방식으로 전환하는 것이 좋습니다. 태그 또는 분기 여전히 지원됩니다.

콘텐츠 기반 태그 지정은 기사에서 다루는 모든 문제를 해결합니다.

빈 Git 커밋에 대한 Docker 태그 이름 저항입니다.
Git 커밋에 대한 Docker 태그 이름의 복원력은 이미지와 관련 없는 파일을 변경합니다.
Git 브랜치에 대한 이전 Git 커밋에 대한 빌드를 다시 시작할 때 이미지의 현재 버전을 정밀 검사하는 문제가 발생하지 않습니다.

그걸 써! 그리고 우리를 방문하는 것을 잊지 마세요 GitHub의이슈를 생성하거나 기존 이슈를 찾고, 플러스를 추가하고, PR을 생성하거나, 단순히 프로젝트 진행 상황을 지켜보세요.

PS

블로그에서도 읽어보세요.

출처 : habr.com

Werf 수집기의 콘텐츠 기반 태깅: 왜 그리고 어떻게 작동합니까?