이제 일반 Dockerfile을 사용하여 werf에서 Docker 이미지를 빌드할 수 있습니다.

안하는 것보다 늦게하는 것이 낫다. 또는 애플리케이션 이미지를 구축하는 데 일반 Dockerfile을 지원하지 않음으로써 심각한 실수를 저지를 뻔한 방법도 있습니다.

우리는에 대해 이야기 할 것입니다 워프 — 모든 CI/CD 시스템과 통합되고 전체 애플리케이션 수명주기에 대한 관리를 제공하는 GitOps 유틸리티로 다음을 수행할 수 있습니다.

• 이미지를 수집하고 게시하며,
• Kubernetes에 애플리케이션을 배포하고,
• 특별 정책을 사용하여 사용하지 않는 이미지를 삭제합니다.

이 프로젝트의 철학은 DevOps 엔지니어가 애플리케이션을 제어할 수 있도록 낮은 수준의 도구를 단일 통합 시스템으로 수집하는 것입니다. 가능하다면 기존 유틸리티(예: Helm 및 Docker)를 사용해야 합니다. 문제에 대한 해결책이 없다면 이에 필요한 모든 것을 만들고 지원할 수 있습니다.

배경: 나만의 이미지 수집기

이는 werf의 이미지 수집기에서 발생한 일입니다. 일반적인 Dockerfile로는 충분하지 않았습니다. 프로젝트의 이력을 잠깐 살펴보면 이 문제는 werf의 첫 번째 버전에서 이미 나타났습니다(그 이후에도 여전히). dapp으로 알려진).

Docker 이미지에 애플리케이션을 구축하기 위한 도구를 만드는 동안 우리는 Dockerfile이 몇 가지 매우 특정한 작업에 적합하지 않다는 것을 금방 깨달았습니다.

1. 다음 표준 체계에 따라 일반적인 소규모 웹 애플리케이션을 구축해야 합니다.
   • 시스템 전체 애플리케이션 종속성을 설치하고,
   • 애플리케이션 종속성 라이브러리 번들을 설치하고,
   • 자산을 수집하고,
   • 가장 중요한 것은 이미지의 코드를 빠르고 효율적으로 업데이트하는 것입니다.
2. 프로젝트 파일이 변경되면 빌더는 변경된 파일에 패치를 적용하여 신속하게 새 레이어를 생성해야 합니다.
3. 특정 파일이 변경된 경우 해당 종속 단계를 다시 빌드해야 합니다.

오늘날 우리 수집가에게는 다른 많은 가능성이 있지만 이것이 초기 욕구이자 충동이었습니다.

일반적으로 우리는 두 번 생각하지 않고 우리가 사용하는 프로그래밍 언어로 무장했습니다. (아래 참조) 구현을 시작했습니다. 자신의 DSL! 목표에 따라 조립 프로세스를 단계별로 설명하고 파일에 대한 이러한 단계의 종속성을 결정하기 위한 것입니다. 그리고 이를 보완한 자신의 수집가, 이는 DSL을 최종 목표인 조립된 이미지로 바꾸었습니다. 처음에 DSL은 Ruby에 있었지만 Golang으로 전환 — 수집기 구성이 YAML 파일에 설명되기 시작했습니다.

Ruby의 dapp에 대한 이전 구성

YAML의 werf에 대한 현재 구성

수집기의 메커니즘도 시간이 지남에 따라 변경되었습니다. 처음에는 구성에서 즉석에서 임시 Dockerfile을 생성한 다음 임시 컨테이너에서 어셈블리 지침을 실행하고 커밋하기 시작했습니다.

NB: 현재 자체 구성(YAML)으로 작동하고 Stapel 수집기라고 불리는 수집기는 이미 상당히 강력한 도구로 개발되었습니다. 자세한 설명은 별도의 기사가 필요하며 기본 세부 사항은 다음에서 찾을 수 있습니다. 선적 서류 비치.

문제의 인식

그러나 우리는 한 가지 실수를 저질렀다는 사실을 즉각적으로 깨닫지는 못했습니다. 표준 Dockerfile을 통해 이미지 빌드 동일한 엔드 투 엔드 애플리케이션 관리 인프라에 통합합니다(예: 이미지 수집, 배포 및 정리). Kubernetes에 배포하기 위한 도구를 만들고 Dockerfile 지원을 구현하지 않는 것이 어떻게 가능합니까? 대부분의 프로젝트에서 이미지를 설명하는 표준 방법은 무엇입니까?..

우리는 이 질문에 답하는 대신 해결책을 제시합니다. Dockerfile(또는 Dockerfile 세트)이 이미 있고 werf를 사용하고 싶다면 어떻게 해야 합니까?

NB: 그런데 왜 werf를 사용하고 싶나요? 주요 기능은 다음과 같이 요약됩니다.

• 이미지 정리를 포함한 전체 애플리케이션 관리 주기;
• 단일 구성에서 한 번에 여러 이미지의 어셈블리를 관리하는 기능
• Helm 호환 차트의 배포 프로세스가 개선되었습니다.

더 완전한 목록은 다음에서 찾을 수 있습니다. 스트래니체 프로텍터.

따라서 이전에 구성에서 Dockerfile을 다시 작성하겠다고 제안했다면 이제는 "Werf가 Dockerfile을 빌드하도록 하세요!"라고 기쁘게 말할 것입니다.

사용 방법은?

이 기능의 전체 구현은 릴리스에 나타났습니다. werf v1.0.3-beta.1. 일반적인 원칙은 간단합니다. 사용자는 werf 구성에서 기존 Dockerfile의 경로를 지정한 다음 명령을 실행합니다. werf build...그리고 그게 전부입니다. werf가 이미지를 조립할 것입니다. 추상적인 예를 살펴보겠습니다.

다음을 발표하자 Dockerfile 프로젝트 루트에서:

FROM ubuntu:18.04
RUN echo Building ...

그리고 우리는 발표할 것이다 werf.yaml이것을 사용하는 Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

모두! 왼쪽 달리다 werf build:

또한 다음을 선언할 수 있습니다. werf.yaml 한 번에 여러 Dockerfile에서 여러 이미지를 빌드하려면 다음을 수행하세요.

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

마지막으로 다음과 같은 추가 빌드 매개변수 전달도 지원합니다. --build-arg и --add-host - werf 구성을 통해. Dockerfile 이미지 구성에 대한 전체 설명은 다음에서 확인할 수 있습니다. 설명서 페이지.

어떻게 작동합니까?

빌드 프로세스 중에 Docker에서 로컬 레이어의 표준 캐시가 작동합니다. 그러나 중요한 것은 werf도 Dockerfile 구성을 인프라에 통합합니다.. 이것은 무엇을 의미 하는가?

1. Dockerfile에서 빌드된 각 이미지는 dockerfile (werf의 어떤 단계에 대해 자세히 알아볼 수 있습니다. 여기에).
2. 무대용 dockerfile werf는 Dockerfile 구성의 내용에 따라 서명을 계산합니다. Dockerfile 구성이 변경되면 단계 서명이 변경됩니다. dockerfile Werf는 새로운 Dockerfile 구성을 사용하여 이 단계의 재구축을 시작합니다. 서명이 변경되지 않으면 werf는 캐시에서 이미지를 가져옵니다. (werf에서 서명 사용에 대한 자세한 내용은 이 보고서).
3. 다음으로 수집된 이미지는 다음 명령을 사용하여 게시할 수 있습니다. werf publish (또는 werf build-and-publish) 이를 Kubernetes 배포에 사용합니다. Docker 레지스트리에 게시된 이미지는 표준 werf 정리 도구를 사용하여 정리됩니다. 이전 이미지(N일 이상), 존재하지 않는 Git 분기와 연결된 이미지 및 기타 정책은 자동으로 정리됩니다.

여기에 설명된 사항에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.

• 출판 과정;
• Kubernetes 배포 프로세스와 통합;
• 청소 과정.

주의 사항

1. ADD에서는 외부 URL을 지원하지 않습니다.

현재 지시문에서 외부 URL을 사용하는 것은 지원되지 않습니다. ADD. Werf는 지정된 URL의 리소스가 변경되면 재구축을 시작하지 않습니다. 곧 이 기능을 추가할 계획입니다.

2. 이미지에 .git을 추가할 수 없습니다.

일반적으로 디렉토리 추가 .git 이미지에서 - 악의적인 나쁜 습관이며 그 이유는 다음과 같습니다.

1. 면 .git 최종 이미지에 남아 있으면 원칙에 위배됩니다. 12팩터 앱: 최종 이미지는 단일 커밋에 연결되어야 하므로 불가능해야 합니다. git checkout 임의 커밋.
2. .git 이미지 크기가 증가합니다(대형 파일이 한 번 추가된 후 삭제되었기 때문에 저장소가 커질 수 있음). 특정 커밋과 관련된 작업 트리의 크기는 Git의 작업 기록에 의존하지 않습니다. 이 경우 추가 및 후속 제거 .git 최종 이미지에서는 작동하지 않습니다. 이미지는 여전히 추가 레이어를 획득합니다. 이것이 Docker가 작동하는 방식입니다.
3. Docker는 동일한 커밋이 빌드되더라도 다른 작업 트리에서 불필요한 재구축을 시작할 수 있습니다. 예를 들어 GitLab은 다음 위치에 별도의 복제된 디렉터리를 생성합니다. /home/gitlab-runner/builds/HASH/[0-N]/yourproject 병렬 조립이 활성화된 경우. 추가 재조립은 디렉토리가 .git 동일한 커밋이 빌드되더라도 동일한 리포지토리의 복제된 버전에 따라 다릅니다.

마지막 요점은 werf를 사용할 때에도 영향을 미칩니다. Werf에서는 일부 명령을 실행할 때 빌드된 캐시가 있어야 합니다(예: werf deploy). 이러한 명령이 실행되면 werf는 다음에 지정된 이미지에 대한 스테이지 서명을 계산합니다. werf.yaml, 어셈블리 캐시에 있어야 합니다. 그렇지 않으면 명령이 계속 작동할 수 없습니다. 무대 시그니처가 내용에 따라 달라지는 경우 .git, 그러면 관련 없는 파일의 변경에 불안정한 캐시를 얻게 되며 werf는 이러한 실수를 용서할 수 없습니다(자세한 내용은 다음을 참조하세요). 선적 서류 비치).

일반적으로, 특정 필수 파일만 추가 지시사항을 통해 ADD 어쨌든 서면의 효율성과 신뢰성이 향상됩니다. Dockerfile, 또한 이를 위해 수집된 캐시의 안정성을 향상시킵니다. Dockerfile, Git의 관련없는 변경 사항.

합계

특정 요구 사항에 맞는 자체 빌더를 작성하는 초기 경로는 어렵고 정직하며 간단했습니다. 표준 Dockerfile 위에 목발을 사용하는 대신 사용자 정의 구문을 사용하여 솔루션을 작성했습니다. 그리고 여기에는 장점이 있습니다. Stapel 수집가는 작업에 완벽하게 대처합니다.

그러나 자체 빌더를 작성하는 과정에서 기존 Dockerfile에 대한 지원을 놓쳤습니다. 이 결함은 이제 수정되었으며 앞으로 분산 어셈블리 및 Kubernetes를 사용한 어셈블리(즉, kaniko에서 수행되는 것처럼 Kubernetes 내부 러너에서 어셈블리)를 위한 맞춤형 Stapel 빌더와 함께 Dockerfile 지원을 개발할 계획입니다.

따라서 갑자기 두 개의 Dockerfile이 주변에 놓여 있다면... 시도하다 워프!

PS 주제에 관한 문서 목록

• 빠른 시작을 위한 가이드;
• dockerfile 빌더 구성;
• werf의 스테이지 장치;
• 이미지 게시 프로세스;
• Kubernetes 배포 프로세스와 통합;
• 청소 과정;
• Dockerfile의 대안인 Stapel 빌더.

우리 블로그에서도 읽어보세요: “werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)".

출처 : habr.com