컨테이너 이미지의 "스마트" 청소 문제와 werf의 솔루션

이 기사에서는 Kubernetes에 제공되는 클라우드 네이티브 애플리케이션을 위한 최신 CI/CD 파이프라인의 현실에서 컨테이너 레지스트리(Docker Registry 및 그 유사 항목)에 축적된 이미지를 정리하는 문제에 대해 설명합니다. 이미지의 관련성과 그에 따른 청소 자동화, 공간 절약 및 팀 요구 사항 충족의 어려움에 대한 주요 기준이 제공됩니다. 마지막으로 특정 오픈 소스 프로젝트의 예를 사용하여 이러한 어려움을 어떻게 극복할 수 있는지 알려 드리겠습니다.

소개

컨테이너 레지스트리의 이미지 수가 급격히 증가하여 더 많은 스토리지 공간을 차지하므로 비용이 크게 증가할 수 있습니다. 레지스트리에서 차지하는 공간의 허용 가능한 증가를 제어, 제한 또는 유지하려면 다음이 허용됩니다.

1. 이미지에는 고정된 수의 태그를 사용합니다.
2. 어떤 방식으로든 이미지를 정리하세요.

첫 번째 제한은 소규모 팀의 경우 허용되는 경우도 있습니다. 개발자가 충분한 영구 태그를 보유한 경우(latest, main, test, boris 등), 레지스트리 크기가 부풀어 오르지 않으며 오랫동안 청소에 대해 전혀 생각할 필요가 없습니다. 결국 관련없는 이미지는 모두 지워지고 청소할 작업이 남지 않습니다 (모든 작업은 일반 가비지 수집기가 수행함).

그러나 이 접근 방식은 개발을 크게 제한하며 최신 CI/CD 프로젝트에는 거의 적용되지 않습니다. 개발의 필수적인 부분은 오토메이션를 사용하면 새로운 기능을 훨씬 빠르게 테스트, 배포 및 사용자에게 제공할 수 있습니다. 예를 들어 모든 프로젝트에서는 커밋할 때마다 CI 파이프라인이 자동으로 생성됩니다. 여기에서 이미지는 디버깅 및 나머지 검사를 위해 다양한 Kubernetes 회로로 조립, 테스트, 롤아웃되며 모든 것이 정상이면 변경 사항이 최종 사용자에게 전달됩니다. 그리고 이것은 더 이상 로켓 과학이 아니라 많은 사람들에게 일상적인 사건입니다. 이 기사를 읽고 있기 때문에 아마도 당신에게 가장 가능성이 높습니다.

버그 수정과 새로운 기능 개발은 병렬로 수행되고 릴리스는 하루에 여러 번 수행될 수 있으므로 개발 프로세스에는 상당한 수의 커밋이 수반된다는 것이 분명합니다. 레지스트리에 많은 수의 이미지가 있습니다.. 결과적으로 레지스트리를 효과적으로 정리하는 문제가 발생합니다. 관련없는 이미지를 제거합니다.

하지만 이미지가 관련성이 있는지 어떻게 판단할 수 있을까요?

이미지의 관련성에 대한 기준

대부분의 경우 주요 기준은 다음과 같습니다.

1. 첫 번째(가장 분명하고 가장 중요한) 이미지는 다음과 같습니다. 현재 Kubernetes에서 사용되는. 이러한 이미지를 제거하면 상당한 생산 중단 시간 비용이 발생하거나(예: 복제에 이미지가 필요할 수 있음) 루프에 대한 팀 디버깅 노력이 무효화될 수 있습니다. (이 때문에 우리는 특별한 프로메테우스 수출업자, Kubernetes 클러스터에 이러한 이미지가 없음을 추적합니다.)

2. 두 번째(덜 명확하지만 매우 중요하며 다시 착취와 관련됨) - 이미지 심각한 문제 발견 시 롤백 필요 현재 버전에서는. 예를 들어 Helm의 경우 저장된 버전의 릴리스에 사용되는 이미지입니다. (그런데 Helm에서는 기본적으로 수정본이 256개로 제한되어 있지만 실제로 저장해야 할 사람은 거의 없습니다. 그런 버전이 많나요?..) 결국 우리는 특히 나중에 사용할 수 있도록 버전을 저장합니다. 필요한 경우 "롤백"합니다.

3. 세 번째 - 개발자 요구: 현재 작업과 관련된 모든 이미지입니다. 예를 들어, PR을 고려하고 있다면 마지막 커밋, 예를 들어 이전 커밋에 해당하는 이미지를 남겨 두는 것이 합리적입니다. 이렇게 하면 개발자가 신속하게 모든 작업으로 돌아가서 최신 변경 사항을 적용할 수 있습니다.

4. 넷째 - 이미지 우리 애플리케이션의 버전에 해당, 즉. 최종 제품은 v1.0.0, 20.04.01/XNUMX/XNUMX, sierra 등입니다.

주의: 여기에 정의된 기준은 다양한 회사의 수십 개 개발팀과 상호 작용한 경험을 바탕으로 공식화되었습니다. 그러나 물론 개발 프로세스의 세부 사항과 사용되는 인프라(예: Kubernetes를 사용하지 않음)에 따라 이러한 기준이 다를 수 있습니다.

자격 및 기존 솔루션

일반적으로 컨테이너 레지스트리가 포함된 인기 있는 서비스는 자체 이미지 정리 정책을 제공합니다. 해당 서비스에서는 레지스트리에서 태그가 제거되는 조건을 정의할 수 있습니다. 그러나 이러한 조건은 이름, 생성 시간, 태그 수*와 같은 매개변수에 의해 제한됩니다.

* 특정 컨테이너 레지스트리 구현에 따라 다릅니다. 우리는 2020년 XNUMX월 현재 Azure CR, Docker Hub, ECR, GCR, GitHub 패키지, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io 솔루션의 가능성을 고려했습니다.

이 매개변수 세트는 네 번째 기준, 즉 버전에 해당하는 이미지를 선택하기에 충분합니다. 그러나 다른 모든 기준에 대해서는 기대치와 재정적 능력에 따라 일종의 절충안(더 엄격하거나 반대로 더 관대한 정책)을 선택해야 합니다.

예를 들어, 개발자의 요구 사항과 관련된 세 번째 기준은 팀 내의 프로세스(이미지의 특정 이름 지정, 특별 허용 목록 및 내부 계약 유지 관리)를 구성하여 해결할 수 있습니다. 그러나 궁극적으로는 자동화가 필요합니다. 그리고 기성 솔루션의 기능이 충분하지 않다면 스스로 뭔가를 해야 합니다.

처음 두 기준의 상황은 유사합니다. 외부 시스템(애플리케이션이 배포되는 시스템(우리의 경우 Kubernetes))에서 데이터를 수신하지 않으면 만족할 수 없습니다.

Git의 워크플로 그림

Git에서 다음과 같은 작업을 하고 있다고 가정해 보겠습니다.

다이어그램에 머리가 있는 아이콘은 현재 모든 사용자(최종 사용자, 테스터, 관리자 등)를 위해 Kubernetes에 배포되어 있거나 개발자가 디버깅 및 유사한 목적으로 사용하는 컨테이너 이미지를 나타냅니다.

정리 정책에서 이미지 보존(삭제 불가)만 허용하는 경우 어떻게 되나요? 주어진 태그 이름으로?

분명히 그러한 시나리오는 누구도 행복하게 만들지 않을 것입니다.

정책에서 이미지를 삭제할 수 없도록 허용하면 어떻게 되나요? 주어진 시간 간격/마지막 커밋 수에 따라?

결과는 훨씬 좋아졌지만 여전히 이상적이지는 않습니다. 결국 버그를 디버깅하기 위해 레지스트리에 이미지가 필요한(또는 K8에 배포된) 개발자가 여전히 있습니다...

현재 시장 상황을 요약하자면, 컨테이너 레지스트리에서 사용할 수 있는 기능은 청소 시 충분한 유연성을 제공하지 않으며, 그 주된 이유는 다음과 같습니다. 외부 세계와 교류할 방법이 없다. 이러한 유연성이 필요한 팀은 Docker Registry API(또는 해당 구현의 기본 API)를 사용하여 "외부에서" 이미지 삭제를 독립적으로 구현해야 하는 것으로 나타났습니다.

그러나 우리는 서로 다른 레지스트리를 사용하여 여러 팀의 이미지 정리를 자동화하는 범용 솔루션을 찾고 있었습니다...

보편적인 이미지 정리를 향한 우리의 길

이러한 필요는 어디에서 오는가? 사실 우리는 별도의 개발자 그룹이 아니라 다수의 개발자를 동시에 지원하여 CI/CD 문제를 종합적으로 해결하는 데 도움을 주는 팀입니다. 이를 위한 주요 기술 도구는 오픈 소스 유틸리티입니다. 워프. 그 특징은 단일 기능을 수행하지 않고 조립부터 배포까지 모든 단계에서 지속적인 전달 프로세스를 수반한다는 것입니다.

이미지를 레지스트리*에 게시하는 것은(빌드 직후) 이러한 유틸리티의 확실한 기능입니다. 그리고 이미지는 저장을 위해 배치되므로 저장 공간이 무제한이 아닌 경우 후속 청소에 대한 책임은 귀하에게 있습니다. 지정된 모든 기준을 충족하면서 어떻게 성공했는지에 대해 더 자세히 논의할 것입니다.

* 레지스트리 자체는 다를 수 있지만(Docker Registry, GitLab Container Registry, Harbor 등) 사용자는 동일한 문제에 직면합니다. 우리의 경우 보편적인 솔루션은 레지스트리 구현에 의존하지 않습니다. 레지스트리 외부에서 실행되며 모든 사람에게 동일한 동작을 제공합니다.

Werf를 예제 구현으로 사용하고 있지만 사용된 접근 방식이 유사한 어려움에 직면한 다른 팀에도 유용할 수 있기를 바랍니다.

그래서 우리는 바빠졌어 외부 컨테이너 레지스트리에 이미 내장된 기능 대신 이미지 정리 메커니즘을 구현합니다. 첫 번째 단계는 Docker Registry API를 사용하여 태그 수와 태그 생성 시간(위에서 언급)에 대한 동일한 기본 정책을 만드는 것이었습니다. 추가됨 배포된 인프라에 사용되는 이미지를 기반으로 하는 허용 목록, 즉. 쿠버네티스. 후자의 경우 Kubernetes API를 사용하여 배포된 모든 리소스를 반복하고 값 목록을 얻는 것으로 충분했습니다. image.

이 사소한 해결책은 가장 중요한 문제(기준 1)를 해결했지만, 이는 청소 메커니즘을 개선하기 위한 여정의 시작일 뿐이었습니다. 다음이자 훨씬 더 흥미로운 단계는 결정이었습니다. 게시된 이미지를 Git 기록과 연결.

태그 지정 방식

우선, 우리는 최종 이미지가 정리에 필요한 정보를 저장해야 하는 접근 방식을 선택하고 태그 지정 방식에 따라 프로세스를 구축했습니다. 이미지를 게시할 때 사용자가 특정 태그 지정 옵션(git-branch, git-commit 또는 git-tag) 해당 값을 사용했습니다. CI 시스템에서는 이러한 값이 환경 변수에 따라 자동으로 설정되었습니다. 사실은 최종 이미지는 특정 Git 기본 요소와 연결되었습니다., 청소에 필요한 데이터를 라벨에 저장합니다.

이 접근 방식을 통해 Git을 단일 정보 소스로 사용할 수 있는 일련의 정책이 탄생했습니다.

• Git에서 브랜치/태그를 삭제하면 레지스트리의 관련 이미지가 자동으로 삭제되었습니다.
• Git 태그 및 커밋과 연결된 이미지 수는 선택한 스키마에 사용된 태그 수와 연결된 커밋이 생성된 시간에 따라 제어될 수 있습니다.

전반적으로 결과 구현은 우리의 요구 사항을 만족시켰지만 곧 새로운 과제가 우리를 기다리고 있었습니다. 사실 Git 기본 요소를 기반으로 한 태그 지정 체계를 사용하는 동안 여러 가지 단점에 직면했습니다. (그 설명은 이 기사의 범위를 벗어나므로 모든 사람이 세부 사항을 숙지할 수 있습니다. 여기에.) 따라서 태그 지정에 대한 보다 효율적인 접근 방식(콘텐츠 기반 태그 지정)으로 전환하기로 결정한 후 이미지 정리 구현을 재고해야 했습니다.

새로운 알고리즘

왜? 콘텐츠 기반 태그 지정을 사용하면 각 태그가 Git의 여러 커밋을 충족할 수 있습니다. 이미지를 정리할 때 더 이상 가정할 수 없습니다. 만 새 태그가 레지스트리에 추가된 커밋에서.

새로운 정리 알고리즘의 경우 태그 지정 방식에서 벗어나 빌드하기로 결정되었습니다. 메타 이미지 프로세스, 각각은 다음을 저장합니다.

• 게시가 수행된 커밋(컨테이너 레지스트리에서 이미지가 추가, 변경 또는 동일하게 유지되었는지 여부는 중요하지 않음)
• 그리고 조립된 이미지에 해당하는 내부 식별자입니다.

즉, 제공되었다. 게시된 태그를 Git의 커밋과 연결.

최종 구성 및 일반 알고리즘

이제 정리를 구성할 때 사용자는 현재 이미지를 선택하는 정책에 액세스할 수 있습니다. 이러한 각 정책은 다음과 같이 정의됩니다.

• 많은 참조, 즉 스캔 중에 사용되는 Git 태그 또는 Git 분기.
• 그리고 세트의 각 참조에 대해 검색된 이미지의 한계.

설명을 위해 기본 정책 구성은 다음과 같습니다.

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

이 구성에는 다음 규칙을 준수하는 세 가지 정책이 포함되어 있습니다.

1. 최근 10개의 Git 태그에 대한 이미지를 저장합니다(태그 생성 날짜 기준).
2. 지난 주에 활동이 있는 스레드는 2개 이하로, 지난 주에 게시된 이미지는 10개 이하로 저장하세요.
3. 지점용 이미지 10개 저장 main, staging и production.

최종 알고리즘은 다음 단계로 요약됩니다.

• 컨테이너 레지스트리에서 매니페스트를 검색합니다.
• Kubernetes에서 사용되는 이미지는 제외됩니다. 우리는 이미 K8s API를 폴링하여 사전 선택했습니다.
• Git 기록을 스캔하고 지정된 정책에 따라 이미지를 제외합니다.
• 남은 이미지를 제거하는 중입니다.

그림으로 돌아가면, werf에서는 다음과 같은 일이 발생합니다.

그러나 werf를 사용하지 않더라도 하나의 구현 또는 다른 구현에서(이미지 태깅에 대해 선호하는 접근 방식에 따라) 고급 이미지 정리에 대한 유사한 접근 방식을 다른 시스템/유틸리티에 적용할 수 있습니다. 이를 위해서는 발생하는 문제를 기억하고 스택에서 솔루션을 최대한 원활하게 통합할 수 있는 기회를 찾는 것으로 충분합니다. 우리가 여행한 길이 귀하가 새로운 세부 사항과 생각으로 귀하의 특정 사례를 보는 데 도움이 되기를 바랍니다.

결론

• 조만간 대부분의 팀은 레지스트리 오버플로 문제에 직면하게 됩니다.
• 솔루션을 검색할 때 먼저 이미지의 관련성에 대한 기준을 결정해야 합니다.
• 널리 사용되는 컨테이너 레지스트리 서비스에서 제공하는 도구를 사용하면 "외부 세계", 즉 Kubernetes에 사용되는 이미지와 팀 워크플로의 특성을 고려하지 않는 매우 간단한 정리를 구성할 수 있습니다.
• 유연하고 효율적인 알고리즘은 CI/CD 프로세스에 대한 이해가 있어야 하며 Docker 이미지 데이터로만 작동하는 것이 아닙니다.

PS

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

• «Werf 수집기의 콘텐츠 기반 태깅: 왜 그리고 어떻게 작동합니까?";
• «werf로 3방향 병합: Helm을 "스테로이드"로 사용하여 Kubernetes에 배포";
• «werf에서 단일 저장소 및 다중 저장소에 대한 지원 및 Docker 레지스트리와 관련이 있는 작업";
• «werf 1.1 릴리스: 현재 빌더 개선 사항 및 향후 계획".

출처 : habr.com