werf 1.1 릴리스: 현재 빌더 개선 사항 및 향후 계획

워프 Kubernetes에 애플리케이션을 구축하고 제공하기 위한 오픈 소스 GitOps CLI 유틸리티입니다. 약속대로, v1.0 버전 출시 werf에 새로운 기능을 추가하고 기존 접근 방식을 수정하는 시작을 알렸습니다. 이제 우리는 개발의 큰 진전이자 미래를 위한 기반인 릴리스 v1.1을 발표하게 된 것을 기쁘게 생각합니다. 수집기 werf. 버전은 현재 다음에서 사용할 수 있습니다. 채널 1.1개.

릴리스의 기본은 새로운 스테이지 스토리지 아키텍처와 두 수집기(Stapel 및 Dockerfile용) 작업의 최적화입니다. 새로운 스토리지 아키텍처는 여러 호스트의 분산 어셈블리와 동일한 호스트의 병렬 어셈블리를 구현할 수 있는 가능성을 열어줍니다.

작업 최적화에는 단계 서명 계산 단계에서 불필요한 계산을 제거하고 파일 체크섬 계산 메커니즘을 보다 효율적인 것으로 변경하는 것이 포함됩니다. 이 최적화는 werf를 사용하여 프로젝트 빌드의 평균 시간을 단축합니다. 유휴 빌드(모든 단계가 캐시에 존재하는 경우) 스테이지 저장, 이제 정말 빠릅니다. 대부분의 경우 빌드를 다시 시작하는 데는 1초도 채 걸리지 않습니다! 이는 팀 작업 과정의 단계를 확인하는 절차에도 적용됩니다. werf deploy и werf run.

또한 이번 릴리스에서는 콘텐츠별로 이미지에 태그를 지정하는 전략이 나타났습니다. 콘텐츠 기반 태그 지정, 이제 기본적으로 활성화되어 있으며 권장되는 유일한 옵션입니다.

werf v1.1의 주요 혁신 사항을 자세히 살펴보는 동시에 미래에 대한 계획도 알려드리겠습니다.

werf v1.1에서 무엇이 변경되었나요?

캐시에서 단계를 선택하기 위한 새로운 단계 이름 지정 형식 및 알고리즘

새로운 무대 이름 생성 규칙. 이제 각 단계 빌드는 서명(v2과 동일)과 고유한 임시 식별자라는 두 부분으로 구성된 고유한 단계 이름을 생성합니다.

예를 들어 전체 스테이지 이미지 이름은 다음과 같습니다.

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...또는 일반적으로:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Здесь :

• SIGNATURE 스테이지 콘텐츠의 식별자를 나타내며 이 콘텐츠로 이어진 Git의 편집 내역에 따라 달라지는 스테이지 서명입니다.
• TIMESTAMP_MILLISEC 새 이미지가 빌드될 때 생성되는 보장된 고유 이미지 식별자입니다.

캐시에서 단계를 선택하는 알고리즘은 Git 커밋의 관계 확인을 기반으로 합니다.

1. Werf는 특정 단계의 시그니처를 계산합니다.
2. В 스테이지 저장 특정 서명에는 여러 단계가 있을 수 있습니다. Werf는 서명과 일치하는 모든 단계를 선택합니다.
3. 현재 단계가 Git(git-archive, Git 패치가 있는 사용자 정의 단계)에 연결된 경우: install, beforeSetup, setup; 또는 git-latest-patch), werf는 현재 커밋(빌드가 호출됨)의 조상인 커밋과 연결된 단계만 선택합니다.
4. 나머지 적합한 단계 중에서 생성 날짜를 기준으로 가장 오래된 단계 중 하나가 선택됩니다.

서로 다른 Git 브랜치의 스테이지는 동일한 서명을 가질 수 있습니다. 그러나 werf는 서명이 일치하더라도 다른 분기와 연관된 캐시가 이러한 분기 간에 사용되는 것을 방지합니다.

→ 문서.

스테이지 저장소에 스테이지를 생성하고 저장하는 새로운 알고리즘

캐시에서 단계를 선택할 때 werf가 적합한 단계를 찾지 못하면 새 단계를 조립하는 프로세스가 시작됩니다.

하나 이상의 호스트에서 여러 프로세스가 거의 동시에 동일한 단계 구축을 시작할 수 있습니다. Werf는 낙관적 차단 알고리즘을 사용합니다. 스테이지 저장 새로 수집된 이미지를 저장하는 순간 스테이지 저장. 이렇게 하면 새 스테이지 빌드가 준비되면 werf 블록이 스테이지 저장 적절한 이미지가 더 이상 존재하지 않는 경우에만 새로 수집된 이미지를 저장합니다. (서명 및 기타 매개변수 기준 - 캐시에서 단계를 선택하는 새로운 알고리즘 참조).

새로 조립된 이미지는 다음을 통해 고유한 식별자를 갖도록 보장됩니다. TIMESTAMP_MILLISEC (새로운 스테이지 이름 지정 형식 참조). 경우에 스테이지 저장 적절한 이미지가 발견되면 werf는 새로 컴파일된 이미지를 삭제하고 캐시의 이미지를 사용합니다.

즉, 이미지 빌드를 완료하는 첫 번째 프로세스(가장 빠른 프로세스)는 이를 스테이지 스토리지에 저장할 수 있는 권한을 갖게 됩니다(그런 다음 이 단일 이미지가 모든 빌드에 사용됩니다). 느린 빌드 프로세스는 더 빠른 프로세스가 현재 단계의 빌드 결과를 저장하고 다음 빌드로 이동하는 것을 결코 차단하지 않습니다.

→ 문서.

향상된 Dockerfile 빌더 성능

현재 Dockerfile에서 빌드된 이미지의 단계 파이프라인은 다음과 같은 한 단계로 구성됩니다. dockerfile. 서명을 계산할 때 파일의 체크섬이 계산됩니다. context, 조립 중에 사용됩니다. 이 개선 이전에는 werf는 모든 파일을 재귀적으로 탐색하고 각 파일의 컨텍스트와 모드를 합산하여 체크섬을 얻었습니다. v1.1부터 werf는 Git 저장소에 저장된 계산된 체크섬을 사용할 수 있습니다.

알고리즘은 다음을 기반으로 합니다. 자식 ls-트리. 알고리즘은 다음의 기록을 고려합니다. .dockerignore 필요한 경우에만 파일 트리를 재귀적으로 탐색합니다. 따라서 우리는 파일 시스템 읽기와 크기에 대한 알고리즘의 의존성을 분리했습니다. context 중요하지 않습니다.

또한 알고리즘은 추적되지 않은 파일을 확인하고 필요한 경우 체크섬에서 해당 파일을 고려합니다.

파일을 가져올 때 성능이 향상되었습니다.

werf v1.1 버전은 다음과 같은 경우에 rsync 서버를 사용합니다. 아티팩트 및 이미지에서 파일 가져오기. 이전에는 호스트 시스템에서 디렉터리 마운트를 사용하여 두 단계로 가져오기가 수행되었습니다.

macOS에서의 가져오기 성능은 더 이상 Docker 볼륨에 의해 제한되지 않으며 Linux 및 Windows와 동일한 시간 내에 가져오기가 완료됩니다.

콘텐츠 기반 태그 지정

Werf v1.1은 소위 이미지 콘텐츠별 태그 지정을 지원합니다. 콘텐츠 기반 태그 지정. 결과 Docker 이미지의 태그는 이러한 이미지의 내용에 따라 달라집니다.

명령을 실행할 때 werf publish --tags-by-stages-signature 또는 werf ci-env --tagging-strategy=stages-signature 이른바 '사진'을 공개했다. 무대 서명 영상. 각 이미지에는 이 이미지 단계의 고유한 서명이 태그로 지정됩니다. 이는 각 단계의 일반 서명과 동일한 규칙에 따라 개별적으로 계산되지만 이미지의 일반적인 식별자입니다.

이미지 단계의 서명은 다음에 따라 달라집니다.

1. 이 이미지의 내용;
2. 이 콘텐츠로 이어진 Git 변경 내역입니다.

Git 저장소에는 항상 이미지 파일의 내용을 변경하지 않는 더미 커밋이 있습니다. 예를 들어 주석만 있는 커밋, 병합 커밋, Git에서 이미지로 가져오지 않을 파일을 변경하는 커밋 등이 있습니다.

콘텐츠 기반 태깅을 사용하면 이미지의 콘텐츠가 변경되지 않은 경우에도 이미지 이름 변경으로 인해 Kubernetes에서 애플리케이션 Pod가 불필요하게 다시 시작되는 문제가 해결됩니다. 그건 그렇고, 이것이 하나의 애플리케이션의 많은 마이크로서비스를 단일 Git 저장소에 저장하는 것을 방지하는 이유 중 하나입니다.

또한 콘텐츠 기반 태깅은 Git 브랜치에 태그를 지정하는 것보다 더 안정적인 태깅 방법입니다. 결과 이미지의 콘텐츠는 동일한 브랜치의 여러 커밋을 조합하기 위해 CI 시스템에서 파이프라인이 실행되는 순서에 의존하지 않기 때문입니다.

중요한 일이야: 지금부터 스테이지 시그니처 -가요 유일하게 권장되는 태그 전략. 명령에서 기본적으로 사용됩니다. werf ci-env (다른 태그 지정 체계를 명시적으로 지정하지 않는 한)

→ 문서. 이 기능에 대해서는 별도의 간행물도 제공될 예정입니다. 업데이트됨 (3월 XNUMX일): 자세한 내용이 담긴 기사 출판사 :.

로깅 수준

이제 사용자는 출력을 제어하고, 로깅 수준을 설정하고, 디버깅 정보로 작업할 수 있습니다. 옵션이 추가되었습니다 --log-quiet, --log-verbose, --log-debug.

기본적으로 출력에는 최소한의 정보가 포함됩니다.

자세한 출력을 사용하는 경우(--log-verbose) werf가 어떻게 작동하는지 볼 수 있습니다:

상세 출력(--log-debug)에는 werf 디버깅 정보 외에도 사용된 라이브러리의 로그도 포함되어 있습니다. 예를 들어 Docker Registry와의 상호 작용이 어떻게 발생하는지 확인하고 상당한 시간이 소요되는 장소도 기록할 수 있습니다.

추가 계획

경고! 아래에 설명된 옵션이 표시되어 있습니다. v1.1 이 버전에서 사용할 수 있게 될 예정이며, 그 중 대부분은 가까운 시일 내에 제공될 예정입니다. 업데이트는 자동 업데이트를 통해 제공됩니다. 멀티워프를 사용할 때. 이러한 기능은 v1.1 기능의 안정적인 부분에 영향을 주지 않으며 해당 기능의 모양은 기존 구성에서 수동 사용자 개입이 필요하지 않습니다.

다양한 Docker 레지스트리 구현에 대한 전체 지원(신규)

• 버전: v1.1
• 날짜: XNUMX월
• 발행물

목표는 사용자가 werf를 사용할 때 제한 없이 사용자 정의 구현을 사용하는 것입니다.

현재 우리는 완전한 지원을 보장할 다음과 같은 솔루션 세트를 식별했습니다.

• 기본값(라이브러리/레지스트리)*,
• AWS ECR
• 하늘빛*,
• 도커 허브
• GCR*,
• GitHub 패키지
• GitLab 레지스트리*,
• 항구*,
• 부두.

현재 werf에서 완벽하게 지원되는 솔루션에는 별표가 표시되어 있습니다. 다른 사람들에게는 지원이 있지만 제한이 있습니다.

두 가지 주요 문제를 식별할 수 있습니다.

• 일부 솔루션은 Docker Registry API를 사용한 태그 제거를 지원하지 않으므로 사용자가 werf의 자동 정리를 사용할 수 없습니다. 이는 AWS ECR, Docker Hub 및 GitHub 패키지에 해당됩니다.
• 일부 솔루션은 소위 중첩된 리포지토리(Docker Hub, GitHub 패키지 및 Quay)를 지원하지 않거나 지원하지만 사용자가 UI 또는 API(AWS ECR)를 사용하여 수동으로 생성해야 합니다.

우리는 솔루션의 기본 API를 사용하여 이러한 문제와 기타 문제를 해결할 것입니다. 이 작업에는 Werf 작업의 전체 주기를 각각에 대한 테스트로 다루는 것도 포함됩니다.

분산 이미지 빌드(↑)

• 버전: v1.2 v1.1 (이 기능 구현의 우선순위가 높아졌습니다.)
• 날짜: XNUMX월~XNUMX월
• 발행물

현재 werf v1.0 및 v1.1은 이미지 빌드 및 게시 작업과 Kubernetes에 애플리케이션 배포 작업을 위해 하나의 전용 호스트에서만 사용할 수 있습니다.

Werf의 분산 작업 가능성을 열려면 Kubernetes에서 애플리케이션의 빌드 및 배포가 여러 임의의 호스트에서 시작되고 이러한 호스트가 빌드(임시 실행기) 간에 상태를 저장하지 않는 경우 werf는 다음을 사용하는 기능을 구현해야 합니다. Docker Registry를 스테이지 저장소로 사용합니다.

이전에는 werf 프로젝트가 아직 dapp으로 불렸을 때 그런 기회가 있었습니다. 그러나 werf에서 이 기능을 구현할 때 고려해야 할 여러 가지 문제에 직면했습니다.

주의. 이 기능을 사용하려면 수집기가 Kubernetes Pod 내에서 작동할 필요가 없습니다. 이렇게 하려면 로컬 Docker 서버에 대한 종속성을 제거해야 합니다(Kubernetes 포드에서는 프로세스 자체가 컨테이너에서 실행되고 werf는 지원하지 않으며 앞으로도 지원하지 않기 때문에 로컬 Docker 서버에 액세스할 수 없습니다). 네트워크를 통해 Docker 서버와 작업). Kubernetes 실행에 대한 지원은 별도로 구현됩니다.

GitHub Actions 공식 지원(신규)

• 버전: v1.1
• 날짜: XNUMX월
• 발행물

werf 문서 포함(섹션 참고 и 안내) 및 werf 작업을 위한 공식 GitHub Action도 있습니다.

또한, werf는 임시 실행기에서 작동할 수 있습니다.

CI 시스템과 사용자의 상호 작용 메커니즘은 풀 요청에 레이블을 배치하여 애플리케이션을 구축/롤아웃하기 위한 특정 작업을 시작하는 것을 기반으로 합니다.

werf를 사용한 애플리케이션의 로컬 개발 및 배포(↓)

• 버전: v1.1
• 날짜: XNUMX월~XNUMX월 XNUMX월
• 발행물

주요 목표는 복잡한 작업 없이 즉시 애플리케이션을 로컬 및 프로덕션 환경에 배포하기 위한 단일 통합 구성을 달성하는 것입니다.

werf에는 또한 애플리케이션 코드를 편집하고 디버깅을 위해 실행 중인 애플리케이션으로부터 즉시 피드백을 받는 것이 편리한 작동 모드가 필요합니다.

새로운 청소 알고리즘(NEW)

• 버전: v1.1
• 날짜: XNUMX월
• 발행물

현재 버전의 werf v1.1 절차에서 cleanup 콘텐츠 기반 태그 지정 체계에 대한 이미지 정리에 대한 규정은 없습니다. 이러한 이미지는 누적됩니다.

또한 werf의 현재 버전(v1.0 및 v1.1)은 태그 지정 체계(Git 브랜치, Git 태그 또는 Git 커밋)에 따라 게시된 이미지에 대해 서로 다른 정리 정책을 사용합니다.

모든 태그 구성표에 대해 통합된 Git의 커밋 기록을 기반으로 이미지를 정리하는 새로운 알고리즘이 개발되었습니다.

• 각 git HEAD(브랜치 및 태그)에 대해 가장 최근 N1 커밋과 연결된 N2 이미지만 유지하세요.
• 각 git HEAD(브랜치 및 태그)에 대한 최신 N1 커밋과 관련된 N2 단계 이미지만 저장하세요.
• Kubernetes 클러스터 리소스에 사용되는 모든 이미지를 저장합니다(구성 파일 및 네임스페이스의 모든 kube 컨텍스트가 스캔됩니다. 특수 옵션을 사용하여 이 동작을 제한할 수 있습니다).
• Helm 릴리스에 저장된 리소스 구성 매니페스트에 사용되는 모든 이미지를 저장합니다.
• 이미지가 git의 HEAD와 연결되어 있지 않고(예: 해당 HEAD 자체가 삭제되었기 때문에) Kubernetes 클러스터 및 Helm 릴리스의 매니페스트에서 사용되지 않는 경우 이미지를 삭제할 수 있습니다.

병렬 이미지 구축(↓)

• 버전: v1.1
• 날짜: XNUMX월~XNUMX월 XNUMX월*

werf의 현재 버전은 다음에 설명된 이미지와 아티팩트를 수집합니다. werf.yaml, 순차적으로. 이미지와 아티팩트의 독립적인 단계를 조립하는 프로세스를 병렬화하고 편리하고 유익한 출력을 제공하는 것이 필요합니다.

* 참고: 분산 어셈블리 구현에 대한 우선순위가 높아져 더 많은 수평적 확장 기능이 추가되고 GitHub Actions와 함께 werf를 사용하므로 마감일이 변경되었습니다. 병렬 조립은 다음 최적화 단계로, 하나의 프로젝트를 조립할 때 수직 확장성을 제공합니다.

헬름 3으로 전환 (↓)

• 버전: v1.2
• 날짜: XNUMX월~XNUMX월 XNUMX월*

새로운 코드베이스로의 마이그레이션 포함 헬름 3 기존 설치를 마이그레이션하는 입증되고 편리한 방법입니다.

* 참고: Helm 3의 모든 주요 기능(3방향 병합 및 경운기 없음)이 이미 Werf에 구현되어 있으므로 Helm 3으로 전환해도 Werf에 중요한 기능이 추가되지 않습니다. 게다가 werf는 추가 기능 표시된 것 외에도. 그러나 이러한 전환은 우리 계획에 남아 있으며 시행될 것입니다.

Kubernetes 구성을 설명하는 JSONnet(↓)

• 버전: v1.2
• 날짜: XNUMX월~XNUMX월 XNUMX월~XNUMX월

Werf는 Jsonnet 형식의 Kubernetes에 대한 구성 설명을 지원합니다. 동시에 werf는 Helm과의 호환성을 유지하며 설명 형식을 선택할 수 있습니다.

그 이유는 Go 템플릿이 많은 사람들에 따르면 진입 장벽이 높고, 이러한 템플릿의 코드에 대한 이해성도 떨어지기 때문입니다.

다른 Kubernetes 구성 설명 시스템(예: Kustomize)을 도입할 가능성도 고려 중입니다.

Kubernetes 내부에서 작업하기(↓)

• 버전: v1.2
• 날짜: XNUMX월~XNUMX월 XNUMX월~XNUMX월

목표: Kubernetes의 실행기를 사용하여 이미지가 빌드되고 애플리케이션이 제공되는지 확인합니다. 저것들. Kubernetes 포드에서 직접 새 이미지를 구축, 게시, 정리 및 배포할 수 있습니다.

이 기능을 구현하려면 먼저 분산 이미지를 구축할 수 있어야 합니다. (위의 내용 참조).

또한 Docker 서버가 없는 빌더 작동 모드(예: Kaniko와 같은 빌드 또는 사용자 공간에서 빌드)에 대한 지원이 필요합니다.

Werf는 Dockerfile뿐만 아니라 증분 재구축 및 Ansible을 갖춘 Stapel 빌더를 사용하여 Kubernetes 기반 구축을 지원합니다.

개방형 개발을 향한 한 걸음

우리는 우리 커뮤니티를 사랑합니다(GitHub의, 텔레그램) 그리고 우리는 점점 더 많은 사람들이 werf를 개선하는 데 도움을 주고, 우리가 나아가는 방향을 이해하고, 개발에 참여하기를 바랍니다.

최근에 전환하기로 결정되었습니다. GitHub 프로젝트 보드 우리 팀의 작업 과정을 공개하기 위해. 이제 다음 영역의 현재 작업뿐만 아니라 즉각적인 계획도 볼 수 있습니다.

• 문서 및 사이트;
• 지원;
• 버그와 나쁜 UX;
• 1.1.

다음과 같은 문제에 대해 많은 작업이 수행되었습니다.

• 관련 없는 내용을 제거했습니다.
• 기존 항목은 충분한 수의 세부 정보와 세부 정보를 포함하여 단일 형식으로 제공됩니다.
• 아이디어와 제안이 포함된 새로운 이슈가 추가되었습니다.

버전 v1.1을 활성화하는 방법

버전은 현재 다음에서 사용할 수 있습니다. 채널 1.1개 (채널에서 안정된 и 바위처럼 단단한 안정화가 이루어지면 릴리스가 나타날 것입니다. ea 그 자체로는 이미 사용하기에 충분히 안정적이기 때문입니다. 채널을 통과했어요 알파 и 베타). 활성화됨 멀티웨어를 통해 다음과 같은 방법으로:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

결론

Stapel 및 Dockerfile 빌더를 위한 새로운 스테이지 스토리지 아키텍처 및 빌더 최적화는 Werf에서 분산 및 병렬 빌드를 구현할 수 있는 가능성을 열어줍니다. 이러한 기능은 곧 동일한 v1.1 릴리스에 나타날 예정이며 자동 업데이트 메커니즘을 통해 자동으로 사용할 수 있게 됩니다(사용자의 경우). 다인종).

이번 릴리스에는 이미지 콘텐츠를 기반으로 한 태그 지정 전략이 추가되었습니다. 콘텐츠 기반 태그 지정, 이는 기본 전략이 되었습니다. 기본 명령 로그도 재작업되었습니다. werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

다음으로 중요한 단계는 분산 어셈블리를 추가하는 것입니다. 분산 빌드는 werf에 더 많은 가치를 추가하기 때문에 v1.0부터 병렬 빌드보다 더 높은 우선순위가 되었습니다. 즉, 빌더의 수직적 확장과 다양한 CI/CD 시스템의 임시 빌더에 대한 지원은 물론 GitHub Actions에 대한 공식 지원 기능도 제공됩니다. . 따라서 병렬 어셈블리의 구현 기한이 변경되었습니다. 그러나 우리는 가능한 한 빨리 두 가지 가능성을 모두 구현하기 위해 노력하고 있습니다.

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

PS

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

• «werf 1.0 stable 소개: GitOps는 그것과 어떤 관련이 있으며, 상태 및 계획은 무엇입니까?»
• «werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)";
• werf의 혁신에 관한 일련의 참고 사항:
  • «werf로 3방향 병합: Helm을 "스테로이드"로 사용하여 Kubernetes에 배포";
  • «Werf를 사용하여 복잡한 Helm 차트 출시";
  • «werf에서 단일 저장소 및 다중 저장소에 대한 지원 및 Docker 레지스트리와 관련이 있는 작업";
  • «이제 일반 Dockerfile을 사용하여 werf에서 Docker 이미지를 빌드할 수 있습니다.".

출처 : habr.com