werf에서 단일 저장소 및 다중 저장소에 대한 지원 및 Docker 레지스트리와 관련이 있는 작업

단일 리포지토리의 주제는 한 번 이상 논의되었으며 일반적으로 매우 활발한 논란을 일으 킵니다. 생성하여 워프 Git에서 Docker 이미지로 애플리케이션 코드를 빌드한 다음 이를 Kubernetes로 전달하는 프로세스를 개선하도록 설계된 오픈 소스 도구로서 우리는 어떤 선택이 최선인지에 대해 많이 생각하지 않습니다. 우리에게는 다양한 의견을 지지하는 사람들에게 필요한 모든 것을 제공하는 것이 기본입니다(물론 이것이 상식에 위배되지 않는 경우).

werf의 최근 모노 레포 지원이 이에 대한 좋은 예입니다. 그러나 먼저 이 지원이 일반적으로 werf 사용과 어떤 관련이 있으며 Docker 레지스트리가 그것과 어떤 관련이 있는지 알아봅시다...

문제

그런 상황을 상상해 봅시다. 이 회사에는 독립적인 프로젝트를 수행하는 많은 개발 팀이 있습니다. 대부분의 애플리케이션은 Kubernetes에서 실행되므로 컨테이너화됩니다. 컨테이너, 이미지를 저장하기 위해서는 레지스트리(registry)가 필요합니다. 이러한 레지스트리로서 회사는 단일 계정으로 Docker Hub를 사용합니다. COMPANY. 대부분의 소스 코드 저장 시스템과 유사하게, Docker Hub는 중첩된 저장소 계층 구조를 허용하지 않습니다., 와 같은 COMPANY/PROJECT/IMAGE. 이 경우… 각 프로젝트에 대해 별도의 계정을 생성하지 않고 이러한 제한이 있는 레지스트리에 비모놀리식 애플리케이션을 어떻게 저장할 수 있습니까?

아마도 설명 된 상황은 누군가에게 직접 익숙하지만 일반적으로 애플리케이션 스토리지 구성 문제를 고려해 봅시다. 위의 예와 Docker Hub를 참조하지 않고.

솔루션

신청하는 경우 단단히 짜여 하나로 되어 있는, 하나의 이미지로 제공되면 질문이 없으며 이미지를 프로젝트의 컨테이너 레지스트리에 저장하기만 하면 됩니다.

응용 프로그램이 여러 구성 요소로 표시되는 경우 마이크로서비스, 특정 접근 방식이 필요합니다. 두 개의 이미지로 구성된 일반적인 웹 애플리케이션의 예: frontend и backend - 가능한 옵션은 다음과 같습니다.

1. 별도의 중첩 저장소에 이미지 저장:

   

2. 모든 것을 하나의 리포지토리에 저장하고 예를 들어 다음과 같이 태그의 이미지 이름을 고려하십시오.

   

NB: 사실 다른 저장소에 저장하는 또 다른 옵션이 있습니다. PROJECT-frontend и PROJECT-backend, 그러나 지원, 조직 및 사용자 간의 권리 분배의 복잡성 때문에 고려하지 않을 것입니다.

늑대 지원

처음에 werf는 중첩된 리포지토리로 제한했습니다. 다행히도 대부분의 레지스트리에서 이 기능을 지원합니다. 버전부터 시작 v1.0.4-alpha.3, 레지스트리 작업 추가 중첩이 지원되지 않습니다, Docker Hub가 그 중 하나입니다. 그 시점부터 사용자는 애플리케이션 이미지를 저장하는 방법을 선택할 수 있습니다.

옵션으로 구현 가능 --images-repo-mode=multirepo|monorepo (기본 multirepo, 즉. 중첩된 저장소에 저장). 이미지가 레지스트리에 저장되는 패턴을 정의합니다. 기본 명령을 사용할 때 원하는 모드를 선택하는 것으로 충분하며 다른 모든 것은 변경되지 않습니다.

대부분의 werf 옵션을 설정할 수 있기 때문에 환경 변수, CI / CD 시스템에서 저장 모드는 일반적으로 전체 프로젝트에 대해 전역적으로 쉽게 설정할 수 있습니다. 예를 들어, 깃랩의 경우 프로젝트 설정에서 환경 변수를 추가하기만 하면 됩니다. 설정 -> CI/CD -> 변수: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

이미지 게시 및 애플리케이션 롤아웃에 대해 이야기하는 경우(관련 문서 문서에서 이러한 프로세스에 대해 자세히 읽을 수 있습니다. 게시 프로세스 и 배포 프로세스), 모드는 이미지로 작업할 수 있는 템플릿만 결정합니다.

악마가 세부 사항에있다.

새로운 저장 방법을 추가할 때의 차이점과 주요 어려움은 레지스트리를 정리하는 과정에 있습니다. (werf에서 지원하는 제거 기능은 다음을 참조하십시오. 청소 과정).

정리할 때 werf는 Kubernetes 클러스터에서 사용되는 이미지와 사용자가 구성한 정책을 고려합니다. 정책은 태그를 전략으로 나누는 것을 기반으로 합니다. 현재 지원되는 전략:

1. 태그, 분기 및 커밋과 같은 Git 프리미티브로 연결된 3가지 전략;
2. 임의의 사용자 지정 태그에 대한 1가지 전략.

최종 이미지의 레이블에 이미지를 게시할 때 태그 전략에 대한 정보를 저장합니다. 의미 자체는 소위 메타 태그 - 일부 정책을 적용하기 위해 필요합니다. 예를 들어 Git 리포지토리에서 브랜치나 태그를 삭제할 때 관련 항목을 삭제하는 것이 논리적입니다. 미사용 Google 정책의 일부가 적용되는 레지스트리의 이미지.

하나의 저장소(monorepo) 이미지 태그에는 메타 태그 외에 이미지 이름도 저장할 수 있습니다. PROJECT:frontend-META-TAG. 이를 구분하기 위해 별도의 구분자를 도입하지 않고, 퍼블리싱 시 최종 이미지의 레이블에 필요한 값을 추가했을 뿐입니다.

NB: werf 소스 코드에 설명된 모든 내용을 살펴보고 싶다면 시작점이 될 수 있습니다. PR 1684.

이 기사에서는 태깅 전략, 레이블에 데이터 저장 및 전체 게시 프로세스와 같은 접근 방식의 문제와 정당성에 더 많은 관심을 기울이지 않을 것입니다. 이 모든 것은 Dmitry Stolyarov의 최근 보고서에 자세히 설명되어 있습니다.werf는 Kubernetes의 CI/CD용 도구입니다.".

요약

중첩되지 않은 레지스트리에 대한 지원 부족은 우리 또는 우리에게 알려진 werf 사용자에게 차단 요인이 아니었습니다. 결국 언제든지 별도의 이미지 레지스트리를 올릴 수 있습니다(또는 Google Cloud의 조건부 Container Registry로 전환)... 그러나, 도구가 더 넓은 DevOps 커뮤니티에서 더 편리해지기 위해서는 이러한 제한을 제거하는 것이 논리적으로 보였습니다. 이를 구현하면서 컨테이너 레지스트리 정리 메커니즘을 재작업하는 데 주요 어려움에 직면했습니다. 이제 모든 것이 준비되었으므로 누군가에게 더 쉬워졌다는 것을 깨닫는 것이 좋으며 우리(프로젝트의 주요 개발자)는 이 기능을 추가로 지원하는 데 눈에 띄는 어려움이 없을 것입니다.

우리와 함께 있으면 곧 다른 혁신에 대해 알려 드리겠습니다. 워프!

PS

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

• «이제 일반 Dockerfile을 사용하여 werf에서 Docker 이미지를 빌드할 수 있습니다.";
• «werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)".

출처 : habr.com