CI/CD의 저장소 임피던스 불일치 해결
배포 이미지와 설명자를 정렬하는 것은 어려울 수 있지만 프로세스를 간소화하기 위한 몇 가지 전략은 다음과 같습니다.
소프트웨어 아키텍처의 임피던스 불일치는 두 구성 요소 간에 개념적, 기술적 어려움이 있을 때 발생합니다. 이는 실제로 전기 공학에서 차용한 용어로, 회로가 작동하려면 전기 입력과 출력의 임피던스가 일치해야 합니다.
소프트웨어 개발에서는 이미지 저장소에 저장된 이미지와 SCM에 저장된 해당 배포 설명자 사이에 임피던스 불일치가 존재합니다. SCM에 저장된 배포 설명자가 실제로 문제의 이미지에 대한 것인지 어떻게 알 수 있습니까? 두 저장소는 동일한 방식으로 보유하는 데이터를 추적하지 않으므로 이미지(이미지 저장소에 개별적으로 저장된 불변 바이너리)를 특정 배포 설명자(Git에서 일련의 변경 사항으로 저장된 텍스트 파일)와 일치시키는 것은 불가능합니다. 똑바로.
참고: 이 문서에서는 최소한 다음 개념에 어느 정도 익숙하다고 가정합니다.
- 소스 제어 관리(SCM) 시스템 및 분기
- Docker/OCI 호환 이미지 및 컨테이너
- Kubernetes와 같은 COP(컨테이너 오케스트레이션 플랫폼)
- 지속적 통합/지속적 전달(CI/CD)
- 소프트웨어 개발 수명주기(SDLC) 환경
임피던스 불일치: SCM 및 이미지 저장소
이것이 어디에서 문제가 되는지 완전히 이해하려면 특정 프로젝트에서 일반적으로 사용되는 기본 SDLC(Software Development LifeCycle) 환경 세트를 고려하십시오. 예를 들어 개발, 테스트, 프로덕션(또는 릴리스) 환경이 있습니다.
개발 환경은 임피던스 불일치로 인해 어려움을 겪지 않습니다. 현재 CI/CD 사용을 포함하는 모범 사례에 따르면 개발 브랜치에 대한 최신 커밋은 개발 환경에 배포된 내용을 반영해야 합니다. 따라서 일반적이고 성공적인 CI/CD 개발 워크플로우를 살펴보면 다음과 같습니다.
- SCM의 개발 지점에 커밋이 이루어집니다.
- 커밋은 이미지 빌드를 트리거합니다.
- 새롭고 고유한 이미지가 이미지 저장소에 푸시되고 dev에 있는 것으로 태그가 지정됩니다.
- 이미지는 SCM에서 가져온 최신 배포 설명자를 사용하여 COP(컨테이너 오케스트레이션 플랫폼)의 개발 환경에 배포됩니다.
즉, 최신 이미지는 항상 개발 환경의 최신 배포 설명자와 일치합니다. 이전 빌드로 롤백하는 것도 문제가 되지 않습니다. 이는 SCM도 롤백함을 의미하기 때문입니다.
하지만 결국에는 보다 공식적인 테스트가 필요한 지점까지 개발이 진행되므로 암시적으로 SCM의 특정 커밋과 관련된 이미지가 테스트 환경으로 승격됩니다. 다시 말하지만, 성공적인 빌드를 가정하면 개발에서 승격된 이미지가 개발 브랜치의 최신 이미지를 반영해야 하기 때문에 이는 큰 문제가 되지 않습니다.
- 개발에 대한 최신 배포가 승격 승인되고 승격 프로세스가 시작됩니다.
- 테스트 중인 것으로 태그된 최신 개발 이미지
- SCM에서 가져온 최신 배포 설명자를 사용하여 이미지를 가져와 테스트 환경에 배포합니다.
지금까지는 너무 좋았죠? 하지만 다음 시나리오 중 하나에서는 어떻게 되나요?
시나리오 A. 이미지는 UAT(사용자 승인 테스트) 또는 프로덕션 환경과 같은 다음 다운스트림 환경으로 승격됩니다.
시나리오 B. 테스트 환경에서 심각한 버그가 발견되어 이미지를 알려진 양호한 이미지로 롤백해야 합니다.
두 시나리오 모두 개발이 중지된 것이 아닙니다. 즉, 개발 분기에 대한 하나 이상의 커밋이 발생했을 수 있으며, 이는 최신 배포 설명자가 변경되었을 가능성이 있고 최신 이미지가 이전 이미지와 동일하지 않을 수 있음을 의미합니다. 이전에 테스트에 배포되었습니다. 배포 설명자에 대한 변경 사항은 이전 버전의 이미지에 적용되거나 적용되지 않을 수 있지만 확실히 신뢰할 수는 없습니다. 변경된 경우 배포하려는 이미지를 사용하여 지금까지 테스트해 온 배포 설명자와 동일한 배포 설명자가 아닙니다.
이것이 문제의 핵심입니다. 배포되는 이미지가 이미지 저장소의 최신 이미지가 아닌 경우 SCM의 어떤 배포 설명자가 배포되는 이미지에 구체적으로 적용되는지 어떻게 식별합니까? 짧은 대답은 할 수 없다는 것입니다. 두 저장소에 임피던스 불일치가 있습니다. 더 긴 답변은 가능하지만 이를 위해 노력해야 한다는 것입니다. 이에 대해서는 이 기사의 나머지 부분에서 다루겠습니다. 다음 사항이 반드시 이 문제에 대한 유일한 해결책은 아니지만 프로덕션에 투입되어 현재 1년 넘게 프로덕션에 구축 및 배포된 수십 개의 프로젝트에서 작동하는 것으로 입증되었습니다.
바이너리 및 배포 설명자
소스 코드 빌드에서 생성되는 일반적인 아티팩트는 Docker 또는 OCI 호환 이미지이며 해당 이미지는 일반적으로 Kubernetes와 같은 COP(컨테이너 오케스트레이션 플랫폼)에 배포됩니다. COP에 배포하려면 이미지를 배포하고 컨테이너로 실행하는 방법을 정의하는 배포 설명자(예: Kubernetes 배포 또는 CronJobs)가 필요합니다. 이는 이미지와 임피던스 불일치가 나타나는 배포 설명자 간의 근본적인 차이 때문입니다. 이 논의에서는 이미지를 이미지 저장소에 저장된 변경할 수 없는 바이너리로 생각하세요. 소스 코드를 변경해도 이미지는 변경되지 않고 고유한 새 이미지로 대체됩니다.
이와 대조적으로 배포 설명자는 텍스트 파일이므로 소스 코드로 간주되고 변경 가능합니다. 모범 사례를 따르면 배포 설명자가 SCM에 저장되고 모든 변경 사항이 먼저 SCM에 커밋되어 적절하게 추적됩니다.
임피던스 불일치 해결
제안된 솔루션의 첫 번째 부분은 이미지 저장소의 이미지를 배포 설명자를 보유하는 SCM의 소스 커밋과 일치시키는 방법이 존재하는지 확인하는 것입니다. 가장 간단한 해결책은 소스 커밋 해시로 이미지에 태그를 지정하는 것입니다. 이렇게 하면 서로 다른 버전의 이미지가 분리되어 쉽게 식별될 수 있으며 이미지가 COP에 올바르게 배포될 수 있도록 올바른 배포 설명자를 찾는 데 충분한 정보를 제공합니다.
위의 시나리오를 다시 검토해 보세요.
시나리오 A. 한 다운스트림 환경에서 다음 환경으로 이미지 승격: 이미지가 테스트에서 UAT로 승격되면 이미지 태그는 SCM의 어느 소스 커밋에서 배포 설명자를 가져올지 알려줍니다.
시나리오 B. 다운스트림 환경에서 이미지를 롤백해야 하는 경우: 롤백하기로 선택한 이미지는 SCM의 어떤 소스 커밋에서 올바른 배포 설명자를 가져올지 알려줍니다.
각 경우에 승격된 모든 이미지는 원래 배포에 사용된 정확한 배포 설명자를 찾을 수 있으므로 특정 이미지가 테스트에 배포된 이후 얼마나 많은 개발 브랜치 커밋 및 빌드가 발생했는지는 중요하지 않습니다.
그러나 이것이 임피던스 불일치에 대한 완전한 해결책은 아닙니다. 두 가지 추가 시나리오를 고려하십시오.
시나리오 C. 부하 테스트 환경에서는 특정 빌드가 어떻게 수행되는지 확인하기 위해 다양한 배포 설명자를 여러 번 시도합니다.
시나리오 D. 이미지가 다운스트림 환경으로 승격되었으며 해당 환경의 배포 설명자에 오류가 있습니다.
이러한 각 시나리오에서는 배포 설명자를 변경해야 하지만 현재 우리가 가지고 있는 것은 소스 커밋 해시뿐입니다. 모범 사례에서는 모든 소스 코드 변경 사항을 먼저 SCM에 다시 커밋해야 한다는 점을 기억하세요. 해당 해시의 커밋은 그 자체로는 변경할 수 없으므로 초기 소스 커밋 해시를 추적하는 것보다 더 나은 솔루션이 분명히 필요합니다.
여기서 해결 방법은 원래 소스 커밋 해시에서 생성된 새 분기입니다. 이를 배포 분기라고 합니다. 이미지가 다운스트림 테스트 또는 릴리스 환경으로 승격될 때마다 이전 SDLC 환경 배포 분기의 헤드에서 새 배포 분기를 생성해야 합니다.
이를 통해 동일한 이미지를 각 SDLC 환경 내에서 다르게 반복적으로 배포할 수 있으며 각 후속 환경에서 해당 이미지에 대해 검색되거나 적용된 변경 사항을 선택할 수도 있습니다.
참고: Helm Charts와 같은 값 공유를 가능하게 하는 도구를 사용하거나 디렉터리 전체에서 수동으로 잘라내어 붙여넣는 방법을 통해 한 환경의 배포 설명자에 적용된 변경 사항을 다음 환경에 적용하는 방법은 이 문서의 범위를 벗어납니다. .
따라서 이미지가 하나의 SDLC 환경에서 다음 환경으로 승격되면 다음이 수행됩니다.
배포 분기가 생성됩니다.
- 이미지가 개발 환경에서 승격되는 경우 이미지를 빌드한 소스 커밋 해시에서 분기가 생성됩니다.
- 그렇지 않으면 현재 배포 분기의 헤드에서 배포 분기가 생성됩니다
그림 1: 배포 분기
- 개발 지점
- 단일 커밋이 있는 첫 번째 다운스트림 환경의 배포 분기
- 단일 커밋이 있는 두 번째 다운스트림 환경의 배포 분기
배포 분기를 솔루션으로 사용하여 위의 시나리오 C와 D를 다시 살펴봅니다.
시나리오 C. 다운스트림 SDLC 환경에 배포된 이미지의 배포 설명자 변경
시나리오 D. 특정 SDLC 환경에 대한 배포 설명자 오류 수정
각 시나리오의 워크플로는 다음과 같습니다.
- SLDC 환경 및 이미지에 대한 배포 분기에 대한 배포 설명자 변경 사항을 커밋합니다.
- 배포 분기 헤드의 배포 설명자를 사용하여 이미지를 SLDC 환경에 재배포합니다.
따라서 배포 분기는 고유한 빌드를 나타내는 변경 불가능한 단일 이미지를 저장하는 이미지 저장소와 하나 이상의 다운스트림 SDLC 환경에 대한 변경 가능한 배포 설명자를 저장하는 SCM 저장소 간의 임피던스 불일치를 완전히 해결합니다.
실제 고려 사항
이는 실행 가능한 솔루션처럼 보이지만 개발자와 운영 리소스 모두에게 다음과 같은 몇 가지 새로운 실용적인 질문을 제시합니다.
A. 배포 분기 관리를 가장 용이하게 하기 위해 배포 설명자를 소스로 어디에 보관해야 합니까? 즉, 이미지를 구축한 소스와 동일하거나 다른 SCM 저장소에 보관해야 합니까?
지금까지 우리는 배포 설명자가 어느 저장소에 있어야 하는지에 대해 언급하지 않았습니다. 너무 자세히 설명하지 않고 모든 SDLC 환경에 대한 배포 설명자를 이미지 소스와 동일한 SCM 저장소에 넣는 것이 좋습니다. 배포 분기가 생성되면 이미지의 소스가 배포되는 컨테이너에서 실제로 실행 중인 항목을 쉽게 찾을 수 있는 참조 역할을 합니다.
위에서 언급한 것처럼 이미지는 태그를 통해 원본 소스 커밋과 연결됩니다. 별도의 저장소에 있는 특정 커밋에서 소스에 대한 참조를 찾는 것은 모든 것을 단일 저장소에 보관함으로써 불필요한 도구를 사용하더라도 개발자에게 어려움을 더할 것입니다.
B. 배포 지점에서 이미지를 빌드한 소스 코드를 수정해야 합니까?
짧은 대답: 절대로.
추가 답변: 아니요. 이미지는 배포 분기에서 빌드하면 안 되기 때문입니다. 개발 지점에서 구축되었습니다. 배포 분기에서 이미지를 정의하는 소스를 변경하면 배포 중인 이미지를 빌드한 기록이 삭제되며 실제로 이미지 기능이 수정되지 않습니다. 이는 서로 다른 버전의 두 배포 분기를 비교할 때도 문제가 될 수 있습니다. 두 기능 간의 기능 차이로 인해 거짓 긍정이 발생할 수 있습니다(배포 분기를 사용하면 작지만 추가적인 이점이 있음).
C. 왜 이미지 태그인가? 이미지 라벨을 사용할 수 없나요?
태그는 저장소에 저장된 이미지를 쉽게 읽고 검색할 수 있습니다. 이미지 그룹에 대해 특정 값이 있는 레이블을 읽고 검색하려면 각 이미지에 대한 매니페스트를 가져와야 하므로 복잡성이 추가되고 성능이 저하됩니다. 또한 기록을 기록하고 다른 버전을 찾으려면 이미지에 다른 버전에 대한 태그를 지정하는 것이 여전히 필요하므로 소스 커밋 해시를 사용하는 것이 고유성을 보장하는 동시에 즉시 유용한 정보를 포함하는 가장 쉬운 솔루션입니다.
D. 배포 분기를 생성하는 가장 실용적인 방법은 무엇입니까?
DevOps의 처음 세 가지 규칙은 자동화, 자동화, 자동화입니다.
모범 사례를 균일하게 적용하기 위해 리소스에 의존하는 것은 기껏해야 실패할 수 있으므로 이미지 승격, 롤백 등을 위한 CI/CD 파이프라인을 구현할 때 자동화된 배포 분기를 스크립트에 통합하세요.
E. 배포 분기의 명명 규칙에 대한 제안 사항이 있습니까?
<배포-분기 식별자>-<env>-<src-commit -해시>
- deployment-branch-identifier: 모든 배포 분기가 이를 배포 분기로 식별하는 데 사용하는 고유 문자열입니다. 예를 들어 '배포' 또는 '배포'
- env: 배포 분기가 속한 SDLC 환경입니다. 예를 들어 테스트, 스테이징 및 프로덕션 환경에 대해 각각 'qa', 'stg' 또는 'prod'
- src-commit-hash: 배포 중인 이미지를 빌드한 원본 코드를 보유하는 소스 코드 커밋 해시입니다. 이를 통해 개발자는 이미지를 생성한 원래 커밋을 쉽게 찾을 수 있습니다. 지점 이름이 고유한지 확인하면서
예를 들어 QA로 승격된 배포 지점의 경우 deployment-qa-asdf78s 또는 deployment-stg-asdf78s 각각 STG 환경.
F. 환경에서 실행 중인 이미지 버전을 어떻게 알 수 있습니까?
우리의 제안은 최신 배포 분기 커밋 해시와 소스 커밋 해시를 사용하여 모든 배포 리소스에 레이블을 지정하는 것입니다. 이 두 가지 고유 식별자를 통해 개발자와 운영 담당자는 배포된 모든 항목과 위치를 찾을 수 있습니다. 또한 롤백 또는 롤포워드 작업 등 다양한 버전의 배포에서 해당 선택기를 사용하여 리소스를 정리하는 것도 간단합니다.
G. 배포 분기의 변경 사항을 개발 분기로 다시 병합하는 것이 언제 적절한가요?
무엇이 의미가 있는지는 전적으로 개발팀에 달려 있습니다.
예를 들어, 단지 무엇이 애플리케이션을 손상시키는지 확인하기 위해 로드 테스트 목적으로 변경하는 경우 이러한 변경 사항은 개발 분기에 다시 병합하는 것이 가장 좋은 방법이 아닐 수 있습니다. 반면, 다운스트림 환경에서 오류를 찾아 수정하거나 배포를 조정하는 경우 배포 분기 변경 사항을 개발 분기에 다시 병합하는 것이 합리적입니다.
H. 먼저 테스트할 배포 분기의 실제 사례가 있습니까?
el-CICD는 프로덕션 배포 관리를 포함하여 모든 SDLC 다운스트림 환경에 걸쳐 100개가 넘는 프로젝트의 프로덕션에서 1년 반 동안 이 전략을 성공적으로 사용해 왔습니다. OKD, Red Hat OpenShift 랩 클러스터 또는 Red Hat CodeReady Containers에 액세스할 수 있는 경우 최신 el-CICD 버전을 다운로드하고 튜토리얼을 실행하여 배포 분기가 생성되고 사용되는 방법과 시기를 확인할 수 있습니다.
마무리
위의 실제 예제를 사용하면 개발 프로세스에서 임피던스 불일치와 관련된 문제를 더 잘 이해하는 데 도움이 될 것입니다. 이미지와 배포 설명자 간의 정렬을 유지하는 것은 배포를 성공적으로 관리하는 데 중요한 부분입니다.