이 문서는 자동화된 지속적 통합 (CI) 파이프라인을 구축하여 멀티 아키텍처 컨테이너 이미지를 Google Cloud에 구축하는 방법을 보여주는 시리즈 중 첫 번째 부분입니다. 이 문서에서 설명하는 개념은 모든 클라우드 환경에 적용됩니다.
시리즈는 이 문서와 함께 제공되는 가이드로 구성됩니다. 이 문서에서는 컨테이너 이미지를 빌드하기 위한 파이프라인의 구조를 설명하고 상위 수준의 단계를 간략하게 설명합니다. 이 가이드에서는 예시 파이프라인을 빌드하는 과정을 안내합니다.
이 시리즈는 컨테이너 이미지를 빌드하기 위해 복잡한 파이프라인을 단순화 및 간소화하거나 이러한 파이프라인을 확장하여 다중 아키텍처 이미지를 빌드하려는 IT 전문가를 대상으로 합니다. 여기서는 사용자가 클라우드 기술과 컨테이너를 잘 알고 있다고 가정합니다.
CI 파이프라인을 구현하면 아티팩트 빌드 절차가 간소화됩니다. 특정 아키텍처를 위한 컨테이너 이미지를 빌드하기 위해 전용 도구 및 하드웨어를 유지관리할 필요가 없습니다. 예를 들어 현재 파이프라인이 x86_64 아키텍처에서 실행되고 해당 아키텍처에 대한 컨테이너 이미지만 생성하는 경우 ARM 계열 등 다른 아키텍처에 대한 컨테이너 이미지를 생성하려면 추가 도구 및 하드웨어를 유지관리해야 할 수 있습니다.
사물 인터넷(IoT) 도메인에는 보통 다중 아키텍처 빌드가 필요합니다. 서로 다른 하드웨어 및 OS 소프트웨어 스택에 많은 기기가 있으면 특정 기기의 소프트웨어 애플리케이션을 빌드, 테스트, 관리하는 프로세스가 매우 어려워집니다. 다중 아키텍처 빌드 프로세스를 사용하면 IoT 애플리케이션 관리를 간소화할 수 있습니다.
다중 아키텍처 컨테이너 이미지 빌드의 과제
대부분의 구현에서 컨테이너 이미지는 아키텍처에 따라 달라집니다. 예를 들어 x86_64 아키텍처에 대한 컨테이너 이미지를 빌드하는 경우 ARM 제품군의 아키텍처에서 실행할 수 없습니다.
이러한 제한을 여러 가지 방법으로 해결할 수 있습니다.
- 컨테이너 이미지가 필요한 대상 아키텍처에 컨테이너 이미지를 빌드합니다.
- 전용 도구와 하드웨어 제품군을 유지관리합니다. 컨테이너 이미지를 빌드해야 하는 각 아키텍처에 대해 하나 이상의 기기가 필요합니다.
- 멀티 아키텍처 컨테이너 이미지를 빌드합니다.
어떤 전략이 가장 좋은지는 다음과 같은 다양한 요소에 따라 다릅니다.
- 파이프라인 복잡성
- 자동화 요구사항
- 컨테이너 이미지 빌드를 위한 환경을 설계, 구현, 유지관리할 수 있는 리소스
예를 들어 런타임 환경에 전원 공급장치에 대한 액세스가 제한된 경우 런타임 환경과 별도의 환경에서 컨테이너 이미지를 빌드해야 할 수 있습니다.
다음 다이어그램은 실행 가능한 전략을 선택하는 데 필요한 결정 사항을 보여줍니다.
대상 아키텍처에 컨테이너 이미지를 빌드합니다.
한 가지 전략은 다음 다이어그램에서 보여지는 것처럼 컨테이너 자체를 지원하는 런타임 환경에서 직접 필요한 각 컨테이너 이미지를 빌드하는 것입니다.
빌드마다 다음을 수행하세요.
- 런타임 환경의 각 기기에 있는 소스 코드 저장소에서 컨테이너 이미지의 소스 코드를 다운로드합니다.
- 런타임 환경에서 컨테이너 이미지를 빌드합니다.
- 런타임 환경의 각 기기에 로컬인 컨테이너 이미지 저장소에 컨테이너 이미지를 저장합니다.
이 전략의 이점은 런타임 환경에 필요한 것 외에 하드웨어를 프로비저닝하고 유지할 필요가 없다는 것입니다. 이 전략에는 단점도 있습니다. 먼저 런타임 환경의 모든 하드웨어 인스턴스에서 빌드 프로세스를 반복해야 하므로 리소스가 낭비됩니다. 예를 들어 기기가 지속적인 전원 공급 장치에 액세스할 수 없는 런타임 환경에 컨테이너식 워크로드를 배포하면 새 버전의 워크로드를 배포할 때마다 이러한 기기에서 빌드 작업을 실행하여 시간과 노력을 낭비할 수 있습니다. 또한 런타임 환경에서 컨테이너 이미지를 빌드하기 위해 각 컨테이너 이미지의 소스 코드에 액세스하는 도구를 유지해야 합니다.
전용 도구 및 하드웨어 제품군 유지관리
두 번째 전략은 컨테이너 이미지를 빌드하는 작업 전용으로 하드웨어 제품군을 유지하는 것입니다. 다음 다이어그램은 이 전략의 아키텍처를 보여줍니다.
각 빌드에 대해 다음을 수행합니다.
- 컨테이너 이미지를 빌드하는 데 필요한 하드웨어 아키텍처와 리소스가 있는 제품군의 기기에 컨테이너 이미지의 소스 코드를 다운로드합니다.
- 컨테이너 이미지를 빌드합니다.
- 컨테이너 이미지를 중앙 집중식 컨테이너 이미지 저장소에 저장합니다.
- 해당 이미지의 새 인스턴스를 배포해야 하는 경우 런타임 환경의 각 기기에 컨테이너 이미지를 다운로드합니다.
이 전략에서는 컨테이너 이미지를 빌드해야 하는 각 하드웨어 아키텍처의 인스턴스를 하나 이상 프로비저닝합니다. 중대한 프로덕션 환경에서는 동시 빌드 작업이 여러 개인 경우 환경의 내결함성을 높이고 빌드 시간을 단축할 수 있는 인스턴스가 두 개 이상 있을 수 있습니다.
이 전략에는 몇 가지 장점이 있습니다. 먼저 각 빌드 작업을 한 번만 실행하고 Container Registry와 같은 중앙 집중식 컨테이너 이미지 저장소에 결과 컨테이너 이미지를 저장할 수 있습니다. 또한 런타임 환경에서 사용하는 하드웨어와 매우 유사한 빌드 제품군의 기기에서 테스트 제품군을 실행할 수 있습니다. 이 전략의 주요 단점은 컨테이너 이미지를 빌드하는 태스크를 실행하기 위한 전용 인프라와 도구를 프로비저닝하고 유지해야 한다는 것입니다. 일반적으로 각 빌드 태스크는 설계상 많은 리소스 또는 시간을 소비하지 않기 때문에 이 인프라는 대체로 유휴 상태로 유지됩니다.
멀티 아키텍처 컨테이너 이미지 빌드
이 세 번째 전략에서는 다음 다이어그램과 같이 범용 파이프라인을 사용하여 다중 아키텍처 컨테이너 이미지를 빌드합니다.
각 빌드에 대해 다음을 수행합니다.
- 컨테이너 이미지의 소스 코드를 다운로드합니다.
- 컨테이너 이미지를 빌드합니다.
- 컨테이너 이미지를 중앙 집중식 컨테이너 이미지 저장소에 저장합니다.
- 해당 이미지의 새 인스턴스를 배포해야 하는 경우 런타임 환경의 각 기기에 컨테이너 이미지를 다운로드합니다.
이 전략의 주된 장점은 전용 하드웨어 또는 도구를 프로비저닝하고 유지관리할 필요가 없다는 것입니다. 예를 들어 기존의 지속적 통합/지속적 배포(CI/CD) 파이프라인과 도구를 사용하여 다중 아키텍처 컨테이너 이미지를 빌드할 수 있습니다. 또한 ARM 계열의 경우와 같은 에너지 효율적인 아키텍처와 비교할 때 x86_64 등의 범용 하드웨어 아키텍처의 성능을 향상시킬 수 있습니다.
이 전략은 DevOps 원칙을 채택하는 광범위한 이니셔티브에 포함될 수도 있습니다. 예를 들어 특수 하드웨어를 위한 CI/CD 파이프라인을 구현할 수 있습니다.
다중 아키텍처 컨테이너 이미지 빌드를 위한 파이프라인 구현
이 섹션에서는 세 번째 전략(다중 아키텍처 컨테이너 이미지 빌드)을 따르는 CI/CD 파이프라인의 참조 구현을 설명합니다.
참조 구현에는 다음과 같은 구성요소가 있습니다.
- 컨테이너 이미지의 소스 코드를 관리하는 소스 코드 저장소입니다. 예를 들어 Cloud Source Repositories 또는 GitLab 저장소를 사용할 수 있습니다.
- Cloud Build와 같은 컨테이너 이미지를 빌드하기 위한 CI/CD 런타임 환경
- Docker와 같이 다중 아키텍처 컨테이너 이미지를 지원하는 컨테이너 및 컨테이너 이미지를 관리하는 플랫폼
- Container Registry와 같은 컨테이너 이미지 레지스트리. 이미지가 필요한 노드와 가까운 위치에 컨테이너 이미지를 저장하려면 Docker Registry와 같은 컨테이너 이미지 레지스트리를 현재 환경에서 직접 실행하면 됩니다.
이 참조 아키텍처는 Moby BuildKit 및 QEMU를 사용하여 멀티 아키텍처 Docker 컨테이너 이미지를 빌드합니다. 이 경우 Moby BuildKit은 QEMU 하드웨어 에뮬레이션을 통해 사용 가능한 아키텍처를 자동으로 감지하고 Linux 커널 기능의 binfmt_misc에 등록된 적절한 바이너리를 자동으로 로드합니다.
다음 다이어그램은 이 참조 아키텍처에서 지원하는 각 다중 아키텍처 컨테이너 이미지 빌드를 담당하는 기술 스택을 보여줍니다.
이 참조 아키텍처는 Docker 이미지 매니페스트를 사용하므로 각 대상 하드웨어 아키텍처에 컨테이너 이미지 태그를 제공할 필요가 없으며 여러 아키텍처에 같은 태그를 사용할 수 있습니다. 예를 들어 멀티 아키텍처 컨테이너 이미지의 1.0.0 버전을 빌드하는 경우 각 하드웨어 아키텍처에 고유한 태그(예: 1.0.0-x86_64 또는 1.0.0_ARMv7)가 필요하지 않습니다. 빌드하는 모든 하드웨어 아키텍처에 동일한 1.0.0 태그를 사용하고 Docker 이미지 매니페스트를 사용하여 각 컨테이너 이미지를 올바르게 식별합니다.
다음 예시는 컨테이너 이미지의 특정 버전이 지원하는 아키텍처에 대한 정보를 찾을 수 있는 공식 Alpine Linux 이미지의 이미지 매니페스트를 보여줍니다.
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:ddba4d27a7ffc3f86dd6c2f92041af252a1f23a8e742c90e6e1297bfa1bc0c45",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:401f030aa35e86bafd31c6cc292b01659cbde72d77e8c24737bd63283837f02c",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:2c26a655f6e38294e859edac46230210bbed3591d6ff57060b8671cda09756d4",
"platform": {
"architecture": "arm64",
"os": "linux"
}
}
]
}
컨테이너 이미지 빌드를 위한 자동화된 파이프라인을 설계할 경우 각 컨테이너 이미지의 요구사항을 검증하는 포괄적인 테스트 모음을 포함하는 것이 좋습니다. 예를 들어 빌드 파이프라인의 작업 중 하나로 Chef InSpec, Serverspec, RSpec과 같은 도구를 사용하여 컨테이너 이미지와 비교하여 규정 준수 테스트 모음을 실행할 수 있습니다.
컨테이너 이미지 빌드를 위한 파이프라인 최적화
컨테이너 이미지를 빌드하기 위해 파이프라인을 검사하고 통합한 후 파이프라인을 최적화합니다. Google Cloud로 마이그레이션: 환경 최적화에서는 환경 최적화에 대한 지침을 제공합니다. 현재 상태와 비교하여 환경을 보다 효율적으로 만들기 위해 채택할 수 있는 최적화 프레임워크를 설명합니다. 최적화 프레임워크를 따르면 환경 상태를 수정하는 여러 반복 과정을 거칩니다.
각 최적화 반복의 첫 번째 활동 중 하나는 해당 반복의 요구사항과 목표를 설정하는 것입니다. 예를 들어 배포 프로세스를 현대화하여 수동 배포 프로세스에서 완전히 자동화된 컨테이너식 프로세스로 이전해야 할 수 있습니다. 배포 프로세스 현대화에 대한 자세한 내용은 Google Cloud로 마이그레이션: 수동 배포에서 자동화된 컨테이너식 배포로 마이그레이션을 참조하세요.
다음 단계
- 함께 제공되는 IoT 기기의 다중 아키텍처 컨테이너 이미지 빌드 가이드를 참조하세요.
- DevOps에 대한 리소스를 읽어보세요.
- Kubernetes 및 지속적 소프트웨어 전송의 문제를 읽어보세요.
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기