Azure Container Registry 작업을 사용하여 컨테이너 이미지 빌드 및 유지 관리 자동화
컨테이너는 인프라 및 운영 요구 사항에서 애플리케이션 및 개발자 종속성을 격리하여 새 수준의 가상화를 제공합니다. 컨테이너 수명 주기 동안 이 애플리케이션 가상화를 관리하고 패치할 수단이 필요합니다.
Azure Container Registry 작업은 다음과 같은 기능 모음입니다.
- Linux, Windows, ARM과 같은 플랫폼에 대한 클라우드 기반 컨테이너 이미지 빌드를 제공합니다.
- 주문형 컨테이너 이미지 빌드를 사용하여 애플리케이션 개발 주기의 초기 부분을 클라우드로 확장합니다.
- 소스 코드 업데이트, 컨테이너의 기본 이미지 업데이트 또는 타이머에 의해 트리거되는 자동화된 빌드를 사용하도록 설정합니다.
예를 들어 기본 이미지 업데이트에 대한 트리거를 사용하여 Docker 컨테이너에 대한 OS 및 프레임워크 패치를 자동화할 수 있습니다. 이러한 트리거는 변경할 수 없는 컨테이너의 원칙을 준수하면서 보안 환경을 유지 관리하는 데 도움이 될 수 있습니다.
Important
Azure Container Registry 작업 실행은 Azure 체험 크레딧에서 일시적으로 일시 중지됩니다. 이 일시 중지는 기존 작업 실행에 영향을 줄 수 있습니다. 문제가 발생하면 Google 팀에 지원 사례를 제출하여 추가 지침을 제공합니다.
Warning
명령줄이나 URI의 일부로 제공된 모든 정보는 ACR(Azure Container Registry) 진단 추적의 일부로 기록될 수 있습니다. 여기에는 자격 증명, GitHub 개인용 액세스 토큰 및 기타 보안 정보와 같은 중요한 데이터가 포함됩니다. 잠재적인 보안 위험을 방지하려면 주의를 기울이세요. 진단 로깅의 대상이 되는 명령줄이나 URI에 중요한 세부 정보를 포함하지 않는 것이 중요합니다.
작업 시나리오
Azure Container Registry 작업은 컨테이너 이미지와 기타 아티팩트 빌드 및 유지 관리를 위한 여러 시나리오를 지원합니다. 이 문서에서는 빠른 작업, 자동으로 트리거된 작업, 다단계 작업에 대해 설명합니다.
각 작업에는 연결된 소스 코드 컨텍스트가 있으며, 이는 컨테이너 이미지 또는 기타 아티팩트를 빌드하는 데 사용되는 소스 파일의 위치입니다. 예제 컨텍스트에는 Git 리포지토리 및 로컬 파일 시스템이 포함됩니다.
작업은 또한 run 변수를 활용할 수 있으므로 작업 정의를 재사용하고 이미지 및 아티팩트용 태그를 표준화할 수 있습니다.
빠른 작업
내부 루프 개발 주기는 소스 제어를 커밋하기 전에 애플리케이션 코드를 작성하고, 빌드하고, 테스트하는 반복적인 프로세스입니다. 이는 컨테이너 수명 주기 관리의 시작입니다.
Azure Container Registry 작업의 빠른 작업 기능은 컨테이너 이미지 빌드를 Azure로 오프로드하여 통합 개발 환경을 제공할 수 있습니다. 로컬 Docker 엔진을 설치하지 않고도 Azure에서 요청 시 단일 컨테이너 이미지를 빌드하고 컨테이너 레지스트리로 푸시할 수 있습니다. 클라우드의 docker build, docker push를 생각하면 됩니다. 빠른 작업을 사용하면 코드를 커밋하기 전에 자동화된 빌드 정의를 확인하고 잠재적인 문제점을 발견할 수 있습니다.
Azure CLI의 az acr build 명령은 친숙한 docker build 형식을 사용하여 컨텍스트를 사용합니다. 그런 다음, 명령은 컨텍스트를 Azure Container Registry로 보내고(기본적으로) 완료 시 빌드된 이미지를 레지스트리에 푸시합니다.
Azure Container Registry 작업은 컨테이너 수명 주기 기본 형식으로 설계되었습니다. 예를 들어 Azure Container Registry 작업을 CI/CD(연속 통합 및 지속적인 업데이트) 솔루션에 통합할 수 있습니다. 서비스 주체로 az login을 실행하는 경우 CI/CD 솔루션은 az acr build 명령을 실행하여 이미지 빌드를 시작할 수 있습니다.
빠른 작업을 사용하는 방법을 알아보려면 Azure Container Registry 작업을 사용하여 컨테이너 이미지를 빌드하고 배포하기 위한 빠른 시작 및 자습서를 참조하세요.
팁
Dockerfile을 사용하지 않고 소스 코드에서 직접 이미지를 빌드하고 푸시하려는 경우 Azure Container Registry에서 az acr pack build 명령(미리 보기)을 제공합니다. 이 도구는 Cloud Native Buildpacks를 사용하여 애플리케이션 소스 코드에서 이미지를 빌드하고 푸시합니다.
자동으로 트리거된 작업
하나 이상의 트리거를 사용하도록 설정하여 이미지를 빌드합니다.
소스 코드 업데이트에 대한 작업 트리거
GitHub의 퍼블릭 또는 프라이빗 Git 리포지토리나 Azure DevOps로 코드를 커밋하거나, 끌어오기 요청을 수행하거나 업데이트할 때 컨테이너 이미지 빌드 또는 다단계 작업을 트리거할 수 있습니다. 예를 들어 Git 리포지토리를 지정하고 선택적으로 분기 및 Dockerfile을 지정하여 az acr task create Azure CLI 명령을 통한 빌드 작업을 구성합니다. 팀이 리포지토리에서 코드를 업데이트하면 Azure Container Registry 작업에서 만든 웹후크가 리포지토리에 정의된 컨테이너 이미지의 빌드를 트리거합니다.
Azure Container Registry 작업은 Git 리포지토리를 작업의 컨텍스트로 설정할 때 다음 트리거를 지원합니다.
| 트리거 | 기본값으로 사용 설정됨 |
|---|---|
| Commit | 예 |
| 끌어오기 요청 | 아니요 |
참고 항목
현재 Azure Container Registry 작업은 GitHub Enterprise 리포지토리에서 커밋 또는 끌어오기 요청 트리거를 지원하지 않습니다.
소스 코드 커밋에서 빌드를 트리거하는 방법을 알아보려면 Azure Container Registry 작업을 사용하여 컨테이너 이미지 빌드 자동화를 참조하세요.
개인용 액세스 토큰
소스 코드 업데이트 트리거를 구성하려면 작업에 개인용 액세스 토큰을 제공하여 퍼블릭 또는 프라이빗 GitHub 또는 Azure DevOps 리포지토리에 웹후크를 설정해야 합니다. 개인용 액세스 토큰에 필요한 범위는 다음과 같습니다.
| 리포지토리 유형 | GitHub | Azure DevOps |
|---|---|---|
| 공용 리포지토리 | repo:status public_repo |
코드(읽기) |
| 프라이빗 리포지토리 | 리포지토리(모든 권한) | 코드(읽기) |
개인용 액세스 토큰을 만들려면 GitHub 또는 Azure DevOps 설명서를 참조하세요.
OS 및 프레임워크 패치 자동화
컨테이너 빌드 워크플로를 향상시키기 위한 Azure Container Registry 작업의 기능은 기본 이미지에 대한 업데이트를 검색하는 기능에서 비롯됩니다. 기본 이미지는 대부분의 컨테이너 이미지의 기능입니다. 하나 이상의 애플리케이션 이미지를 기반으로 하는 부모 이미지입니다. 일반적으로 기본 이미지에는 운영 체제 및 애플리케이션 프레임워크가 포함되어 있습니다.
애플리케이션 이미지를 빌드할 때 기본 이미지에 대한 종속성을 추적하도록 Azure Container Registry 작업을 설정할 수 있습니다. 업데이트된 기본 이미지가 레지스트리에 푸시되는 경우 또는 Docker Hub와 같은 퍼블릭 리포지토리에서 기본 이미지가 업데이트되는 경우 Azure Container Registry 작업은 이에 따라 모든 애플리케이션 이미지를 자동으로 빌드할 수 있습니다. 이 자동 검색 및 다시 빌드를 통해 Azure Container Registry 작업은 업데이트된 기본 이미지를 참조하는 모든 애플리케이션 이미지를 수동으로 추적하고 업데이트하는 데 일반적으로 필요한 시간과 노력을 절약할 수 있습니다.
자세한 내용은 Azure Container Registry 작업에 대한 기본 이미지 업데이트 정보 및 자습서: Azure Container Registry에서 기본 이미지가 업데이트될 때 컨테이너 이미지 빌드 자동화를 참조하세요.
작업 예약
작업을 만들거나 업데이트할 때 하나 이상의 타이머 트리거를 설정하여 작업을 예약할 수 있습니다. 작업 예약은 정의된 일정에 따라 컨테이너 작업을 실행하거나 레지스트리에 정기적으로 푸시되는 이미지에 대한 유지 관리 작업 또는 테스트를 실행하는 데 유용합니다. 자세한 내용은 정의된 일정에 따라 Azure Container Registry 작업 실행을 참조하세요.
다단계 작업
여러 컨테이너를 기반으로 하는 다단계 워크플로를 사용하여 Azure Container Registry 작업의 단일 이미지 빌드 및 푸시 기능을 확장합니다.
다중 단계 작업은 클라우드에서 컨테이너 이미지를 빌드, 테스트 및 패치하기 위한 단계 기반 작업 정의 및 실행을 지원합니다. YAML 파일에 정의된 작업 단계는 컨테이너 이미지 또는 다른 아티팩트에 대한 개별 빌드 및 푸시 작업을 지정합니다. 해당 실행 환경으로 컨테이너를 사용하여 각 단계로 하나 이상의 컨테이너 실행을 정의할 수도 있습니다.
예를 들어 다음 단계를 자동화하는 다단계 작업을 만들 수 있습니다.
- 웹 애플리케이션 이미지를 빌드합니다.
- 웹 애플리케이션 컨테이너를 실행합니다.
- 웹 애플리케이션 테스트 이미지를 빌드합니다.
- 실행 중인 애플리케이션 컨테이너에 대해 테스트를 수행하는 웹 애플리케이션 테스트 컨테이너를 실행합니다.
- 테스트에 통과하는 경우 Helm 차트 보관 패키지를 빌드합니다.
- 새 Helm 차트 보관 패키지를 사용하여
helm upgrade를 수행합니다.
다단계 작업을 사용하면 단계 간 종속성 지원을 통해 이미지 빌드, 실행, 테스트를 보다 복잡한 단계로 분할할 수 있습니다. Azure Container Registry 작업의 다단계 작업을 사용하면 이미지 빌드, 테스트, OS 및 프레임워크 패치를 위한 워크플로를 보다 세부적으로 제어할 수 있습니다.
Azure Container Registry 작업에서 다단계 빌드, 테스트, 패치 작업을 실행하는 방법에 대해 자세히 알아봅니다.
컨텍스트 위치
다음 표에서는 Azure Container Registry 작업에 지원되는 컨텍스트 위치의 예를 보여 줍니다.
| 컨텍스트 위치 | 설명 | 예시 |
|---|---|---|
| 로컬 파일 시스템 | 로컬 파일 시스템의 디렉터리 내에 있는 파일. | /home/user/projects/myapp |
| GitHub 주 분기 | 퍼블릭 또는 프라이빗 GitHub 리포지토리의 주(또는 다른 기본) 분기 내에 있는 파일입니다. | https://github.com/gituser/myapp-repo.git |
| GitHub 분기 | 퍼블릭 또는 프라이빗 GitHub 리포지토리의 특정 분기입니다. | https://github.com/gituser/myapp-repo.git#mybranch |
| GitHub 하위 폴더 | 퍼블릭 또는 프라이빗 GitHub 리포지토리의 하위 폴더에 있는 파일입니다. 예제에서는 분기 및 하위 폴더 사양의 조합을 보여 줍니다. | https://github.com/gituser/myapp-repo.git#mybranch:myfolder |
| GitHub 커밋 | 퍼블릭 또는 프라이빗 GitHub 리포지토리의 특정 커밋입니다. 예제에서는 커밋 해시(SHA) 및 하위 폴더 사양의 조합을 보여 줍니다. | https://github.com/gituser/myapp-repo.git#git-commit-hash:myfolder |
| Azure DevOps 하위 폴더 | 퍼블릭 또는 프라이빗 Azure 리포지토리의 하위 폴더에 있는 파일입니다. 예제에서는 분기와 하위 폴더 사양의 조합을 보여 줍니다. | https://dev.azure.com/user/myproject/_git/myapp-repo#mybranch:myfolder |
| 원격 Tarball | 원격 웹 서버의 압축된 아카이브에 있는 파일. | http://remoteserver/myapp.tar.gz |
| 컨테이너 레지스트리의 아티팩트 | 컨테이너 레지스트리 리포지토리의 OCI 아티팩트 파일입니다. | oci://myregistry.azurecr.io/myartifact:mytag |
참고 항목
소스 코드 업데이트에 의해 트리거된 작업의 컨텍스트로 Git 리포지토리를 사용하는 경우 개인 액세스 토큰을 제공해야 합니다.
이미지 플랫폼
기본적으로 Azure Container Registry 작업은 Linux OS 및 AMD64 아키텍처에 대한 이미지를 빌드합니다. 다른 아키텍처용으로 Windows 이미지 또는 Linux 이미지를 빌드하려면 --platform 태그를 지정합니다. OS를 지정하고 필요에 따라 OS/아키텍처 형식(예: --platform Linux/arm)으로 지원되는 아키텍처를 지정합니다. ARM 아키텍처의 경우 필요에 따라 OS/아키텍처/변형 형식(예: --platform Linux/arm64/v8)으로 변형을 지정합니다.
| OS | 아키텍처 |
|---|---|
| Linux | AMD64 ARM ARM64 386 |
| Windows | AMD64 |
작업 출력
태스크가 실행될 때마다 로그 출력이 생성되며, 이를 검사하여 작업 단계가 성공적으로 실행되었는지 여부를 확인할 수 있습니다. 작업을 수동으로 트리거하는 경우 작업 실행에 대한 로그 출력이 콘솔로 스트리밍되며 나중에 검색할 수 있도록 저장됩니다. 예를 들어 소스 코드 커밋 또는 기본 이미지 업데이트 시 작업이 자동으로 트리거되면 작업 로그만 저장됩니다. Azure Portal에서 실행 로그를 보거나 az acr task logs 명령을 사용합니다.
관련 콘텐츠
클라우드에서 컨테이너 이미지 빌드 및 유지 관리를 자동화할 준비가 되면 자습서: Azure Container Registry 작업을 사용하여 클라우드에서 컨테이너 이미지 빌드 및 배포를 참조하세요.
필요에 따라 Visual Studio Code용 Docker 확장 및 Azure 계정 확장에 대해 알아봅니다. 이러한 확장을 사용하여 Visual Studio Code 내에서 컨테이너 레지스트리에서 이미지를 가져오거나, 이미지를 컨테이너 레지스트리로 푸시하거나, Azure Container Registry 작업을 실행할 수 있습니다.