Kubernetes 앱에 대한 Azure 컨테이너 기술 자산 준비
이 문서에서는 Azure Marketplace에서 Kubernetes 애플리케이션에 대한 컨테이너 제품을 만드는 데 도움이 되는 기술 리소스 및 권장 사항을 제공합니다.
Kubernetes 앱 기반 컨테이너 제품에 필요한 기술 자산의 포괄적인 예제는 Kubernetes에 대한 Azure Marketplace 컨테이너 제품 샘플을 참조하세요.
기본 기술 지식
이러한 자산을 디자인, 빌드 및 테스트하려면 시간이 걸리며 Azure 플랫폼과 제품을 빌드하는 데 사용되는 기술에 대한 기술 지식이 필요합니다.
엔지니어링 팀은 솔루션 도메인 외에도 다음과 같은 Microsoft 기술에 대한 지식을 갖습니다.
- Azure 서비스에 대한 기본적 이해
- Azure 애플리케이션을 디자인하고 설계하는 방법
- Azure Resource Manager에 대한 실무 지식
- JSON에 대한 실무 지식
- Helm에 대한 실무 지식
- createUiDefinition에 대한 실무 지식
- ARM(Azure Resource Manager) 템플릿에 대한 실무 지식
필수 조건
애플리케이션은 Helm 차트 기반이어야 합니다.
Helm 차트에는 보관 파일이 포함되어
.tgz서는 안 됩니다. 모든 파일의 압축을 풉야 합니다.차트가 여러 개 있는 경우 다른 Helm 차트를 기본 helm 차트 외에 하위 차트로 포함할 수 있습니다.
모든 이미지 참조 및 다이제스트 세부 정보가 차트에 포함되어야 합니다. 런타임에 다른 차트 또는 이미지를 다운로드할 수 없습니다.
활성 게시 테넌트가 있거나 게시 테넌트 및 파트너 센터 계정에 대한 액세스 권한이 있어야 합니다.
위의 활성 게시 테넌트에 속하는 ACR(Azure Container Registry)을 만들었어야 합니다. CNAB(클라우드 네이티브 애플리케이션 번들)를 업로드합니다. 자세한 내용은 Azure Container Registry 만들기를 참조 하세요.
최신 버전의 Azure CLI를 설치합니다.
애플리케이션을 Linux 환경에 배포할 수 있어야 합니다.
이미지는 취약성이 없어야 합니다. 취약성 검사 요구 사항을 지정하는 지침은 컨테이너 인증 문제 해결을 참조하세요. 취약성 검사에 대한 자세한 내용은 Microsoft Defender 취약성 관리 사용하여 Azure에 대한 취약성 평가를 참조하세요.
패키징 도구를 수동으로 실행하는 경우 Docker를 로컬 컴퓨터에 설치해야 합니다. 자세한 내용은 Windows 또는 Linux용 Docker 설명서의 WSL 2 백 엔드 섹션을 참조하세요. Linux/Windows AMD64 컴퓨터에서만 지원됩니다.
제한 사항
- 컨테이너 Marketplace는 Linux 플랫폼 기반 AMD64 이미지만 지원합니다.
- Container Marketplace 제품은 관리되는 AKS 및 Arc 지원 Kubernetes에 대한 배포를 지원합니다. 단일 제품은 하나의 클러스터 유형(관리되는 AKS 또는 Arc 지원 Kubernetes)만 대상으로 지정할 수 있습니다.
- Arc 지원 Kubernetes 클러스터에 대한 제품은 미리 정의된 청구 모델만 지원합니다. 청구 모델에 대한 자세한 내용은 Azure Container 제품 계획을 참조하세요.
- 단일 컨테이너는 지원되지 않습니다.
- 연결된 Azure Resource Manager 템플릿은 지원되지 않습니다.
게시 개요
Azure Marketplace Kubernetes 앱 기반 컨테이너 제품을 게시하기 위한 첫 번째 단계는 애플리케이션을 CNAB(Cloud Native Application Bundle)로 패키징하는 것입니다. 애플리케이션의 아티팩트로 구성된 CNAB는 먼저 프라이빗 ACR(Azure Container Registry)에 게시되고 나중에 Microsoft 소유의 공용 ACR로 푸시되며 파트너 센터에서 참조하는 단일 아티팩트로 사용됩니다.
여기에서 취약성 검사를 수행하여 이미지의 보안을 보장합니다. 마지막으로 Kubernetes 애플리케이션은 AKS(Azure Kubernetes Service) 클러스터의 확장 유형으로 등록됩니다.
제품이 게시되면 애플리케이션은 AKS 기능에 대한 클러스터 확장을 활용하여 AKS 클러스터 내에서 애플리케이션 수명 주기를 관리합니다.
Azure Container Registry에 대한 액세스 권한 부여
게시 프로세스의 일환으로 Microsoft는 CNAB를 ACR에서 Microsoft 소유의 Azure Marketplace 특정 ACR로 깊이 복사합니다. 이미지는 모든 사용자가 액세스할 수 있는 공용 레지스트리에 업로드됩니다. 이 단계를 수행하려면 레지스트리에 대한 Microsoft 액세스 권한이 있어야 합니다. ACR은 파트너 센터 계정에 연결된 동일한 Microsoft Entra 테넌트에 있어야 합니다.
Microsoft에는 이 프로세스를 처리하는 자사 애플리케이션이 id 32597670-3e15-4def-8851-614ff48c1efa있습니다. 시작하려면 애플리케이션을 기반으로 서비스 주체를 만듭니다.
참고 항목
계정에 서비스 주체를 만들 수 있는 권한이 없는 경우 az ad sp create에서 "권한이 부족하여 작업을 완료할 수 없음"이라는 오류 메시지를 반환합니다. Microsoft Entra 관리자에게 문의하여 서비스 주체를 만드세요.
az login
애플리케이션에 대한 서비스 주체가 이미 있는지 확인합니다.
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
이전 명령이 결과를 반환하지 않는 경우 새 서비스 주체를 만듭니다.
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
다음 단계에서 사용할 서비스 주체의 ID를 기록해 둡니다.
다음으로, 레지스트리의 전체 ID를 가져옵니다.
az acr show --name <registry-name> --query "id" --output tsv
출력은 다음과 유사해야 합니다.
...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
다음으로, 이전에 얻은 값을 사용하여 레지스트리에서 끌어올 수 있는 권한을 서비스 주체에게 부여하는 역할 할당을 만듭니다.
Azure 역할을 할당하려면 다음이 있어야 합니다.
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
마지막으로, Azure Container Registry를 만드는 데 사용된 것과 동일한 구독에 Microsoft.PartnerCenterIngestion 리소스 공급자를 등록합니다.
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
등록을 모니터링하고 완료되었는지 확인한 후 계속합니다.
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
패키지 형식 요구 사항에 맞게 아티팩트 수집
각 CNAB는 다음 아티팩트로 구성됩니다.
- Helm 차트
- CreateUiDefinition
- ARM 템플릿
- 매니페스트 파일
Helm 차트 업데이트
Helm 차트가 다음 규칙을 준수하는지 확인합니다.
모든 이미지 이름 및 참조는 매개 변수화되고
values.yaml에서 global.azure.images 참조로 표시됩니다. 이러한 이미지를 가리키도록 Helm 차트 템플릿 파일을deployment.yaml업데이트합니다. 이렇게 하면 Azure Marketplace의 ACR 이미지를 참조하도록 이미지 블록을 업데이트할 수 있습니다.
차트가 여러 개 있는 경우 다른 Helm 차트를 기본 helm 차트 외에 하위 차트로 포함할 수 있습니다. 모든 종속 Helm 차트 이미지 참조는 업데이트가 필요하며 주 차트
values.yaml에 포함된 이미지를 가리킵니다.이미지를 참조할 때 태그 또는 다이제스트를 활용할 수 있습니다. 그러나 이미지는 내부적으로 Microsoft 소유의 ACR(Azure Container Registry)을 가리키도록 태그가 다시 지정된다는 점에 유의해야 합니다. 태그를 업데이트할 때 새 버전의 CNAB를 Azure Marketplace에 제출해야 합니다. 이렇게 하면 변경 내용이 고객 배포에 반영될 수 있습니다.
사용 가능한 청구 모델
사용 가능한 모든 청구 모델은 Azure Kubernetes 애플리케이션에 대한 라이선스 옵션을 참조하세요.
청구 모델에 따라 업데이트 수행
사용 가능한 청구 모델을 검토 한 후 사용 사례에 적합한 청구 모델을 선택하고 다음 단계를 완료합니다.
코어당, Pod당, 노드당 청구 모델에 식별자를 추가하려면 다음 단계를 완료합니다.
워크로드 yaml 파일의 Pod 사양에 청구 식별자 레이블
azure-extensions-usage-release-identifier을 추가합니다.워크로드가 배포 또는 복제본 세트, 상태 저장 세트 또는 디먼셋 사양으로 지정된 경우 .spec.template.metadata.labels 아래에 이 레이블을 추가합니다.
워크로드가 Pod 사양으로 직접 지정된 경우 .metadata.labels 아래에 이 레이블을 추가합니다.
perCore 청구 모델의 경우 컨테이너 리소스 매니페스트에 필드를 포함하여
resources:requestsCPU 요청을 지정합니다. 이 단계는 perCore 청구 모델에만 필요합니다.
배포 시 클러스터 확장 기능은 청구 식별자 값을 확장 인스턴스 이름으로 바꿉니다.
Azure Voting 앱을 배포하도록 구성된 예제는 다음을 참조하세요.
사용자 지정 미터 청구 모델의 경우 Helm 템플릿의 values.yaml 파일에 아래에 나열된 필드를 추가합니다.
- global.azure.identity 아래에 clientId를 추가해야 합니다.
- planId 키는 global.azure.marketplace 아래에 추가해야 합니다. planId
- resourceId는 global.azure.extension.resrouceId 아래에 추가되어야 합니다.
배포 시 클러스터 확장 기능은 이러한 필드를 적절한 값으로 바꿉니다. 예제는 Azure Vote Custom 미터 기반 앱을 참조 하세요.
Helm 차트 유효성 검사
Helm 차트가 유효한지 확인하려면 로컬 클러스터에 설치할 수 있는지 테스트합니다. helm install --generate-name --dry-run --debug를 사용하여 특정 템플릿 생성 오류를 감지할 수도 있습니다.
createUiDefinition 만들기 및 테스트
createUiDefinition은 애플리케이션을 배포할 때 Azure Portal의 사용자 인터페이스 요소를 정의하는 JSON 파일입니다. 자세한 내용은 다음을 참조하세요.
또는 새 클러스터 또는 기존 클러스터 선택에 대한 입력 데이터를 요청하고 애플리케이션에 매개 변수를 전달하는 UI 정의의 예를 참조하세요.
애플리케이션의 createUiDefinition.json 파일을 만든 후에는 사용자 환경을 테스트해야 합니다. 테스트를 간소화하려면 파일 내용을 샌드박스 환경에 복사합니다. 샌드박스는 현재 전체 화면 포털 환경에서 사용자 인터페이스를 제공합니다. 샌드박스는 사용자 인터페이스 미리 보기에 권장되는 방법입니다.
ARM(Azure Resource Manager) 템플릿 만들기
ARM 템플릿은 배포할 Azure 리소스를 정의합니다. 기본적으로 Azure Marketplace 애플리케이션에 대한 클러스터 확장 리소스를 배포합니다. 필요에 따라 AKS 클러스터를 배포하도록 선택할 수 있습니다.
현재는 다음 리소스 종류만 허용됩니다.
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
예를 들어 이전에 연결된 샘플 UI 정의의 결과를 가져와 애플리케이션에 매개 변수를 전달하도록 설계된 이 샘플 ARM 템플릿 을 참조하세요.
사용자 매개 변수 흐름
만들고 패키징하는 아티팩트 전체에서 사용자 매개 변수가 흐르는 방식을 이해하는 것이 중요합니다. Azure Voting App 예제에서는 createUiDefinition.json 파일을 통해 UI를 만들 때 매개 변수가 처음에 정의됩니다.
매개 변수는 섹션을 통해 내보냅니다.outputs
여기에서 값은 Azure Resource Manager 템플릿으로 전달되고 배포 중에 Helm 차트로 전파됩니다.
마지막으로 값은 표시된 대로 Helm 차트 values.yaml 로 전달됩니다.
참고 항목
이 예제 extensionResourceName 에서는 매개 변수화되어 클러스터 확장 리소스에 전달됩니다. 마찬가지로 부 버전에 대해 자동 업그레이드를 사용하도록 설정하는 등 다른 확장 속성을 매개 변수화할 수 있습니다. 클러스터 확장 속성에 대한 자세한 내용은 선택적 매개 변수를 참조 하세요.
매니페스트 파일 만들기
패키지 매니페스트는 패키지 및 해당 콘텐츠를 설명하고 패키징 도구에 종속 아티팩트 위치를 알려 주는 yaml 파일입니다.
매니페스트에 사용되는 필드는 다음과 같습니다.
| 속성 | 데이터 유형 | 설명 |
|---|---|---|
| applicationName | 문자열 | 애플리케이션의 이름입니다. |
| publisher | 문자열 | 게시자의 이름 |
| description | 문자열 | 패키지에 대한 간단한 설명 |
| version | 형식의 #.#.# 문자열 |
애플리케이션 패키지 버전을 설명하는 버전 문자열은 내부 이진 파일의 버전과 일치하거나 일치하지 않을 수 있습니다. |
| helmChart | 문자열 | 이 manifest.yaml을 기준으로 Helm 차트를 찾을 수 있는 로컬 디렉터리 |
| clusterARMTemplate | 문자열 | 제한 사항 필드의 요구 사항을 충족하는 AKS 클러스터를 설명하는 ARM 템플릿을 찾을 수 있는 로컬 경로 |
| uiDefinition | 문자열 | Azure Portal 환경 만들기를 설명하는 JSON 파일을 찾을 수 있는 로컬 경로 |
| registryServer | 문자열 | 최종 CNAB 번들을 푸시해야 하는 ACR |
| extensionRegistrationParameters | 컬렉션 | 확장 등록 매개 변수의 사양입니다. 최소한 defaultScope를 매개 변수로 포함합니다. |
| defaultScope | 문자열 | 확장 설치의 기본 범위입니다. 허용되는 값은 cluster 또는 namespace입니다. cluster 범위를 설정하면 클러스터당 하나의 확장 인스턴스만 허용됩니다. namespace 범위를 선택하면 네임스페이스당 하나의 인스턴스만 허용됩니다. Kubernetes 클러스터에는 여러 네임스페이스가 있을 수 있으므로 확장 인스턴스가 여러 개 있을 수 있습니다. |
| namespace | 문자열 | (선택 사항) 확장이 설치되는 네임스페이스를 지정합니다. 이 속성은 defaultScope가 cluster로 설정된 경우에 필요합니다. 네임스페이스 명명 제한 사항은 네임스페이스 및 DNS를 참조하세요. |
| supportedClusterTypes | 컬렉션 | (선택 사항) 애플리케이션에서 지원하는 클러스터 유형을 지정합니다. 허용되는 형식은 "managedClusters", "connectedClusters"입니다. "managedClusters"는 AKS(Azure Kubernetes Service) 클러스터를 나타냅니다. "connectedClusters"는 Azure Arc 지원 Kubernetes 클러스터를 나타냅니다. supportedClusterTypes가 제공되지 않으면 기본적으로 'managedClusters'의 모든 배포가 지원됩니다. supportedClusterTypes가 제공되고 지정된 최상위 클러스터 형식이 제공되지 않으면 해당 클러스터 형식에 대한 모든 배포 및 Kubernetes 버전이 지원되지 않는 것으로 처리됩니다. 각 클러스터 유형에 대해 다음 속성을 사용하여 하나 이상의 배포 목록을 지정합니다. -분포 - distributionSupported - unsupportedVersions |
| distribution | List | 클러스터 유형에 해당하는 배포 배열입니다. 특정 배포의 이름을 제공합니다. 모든 배포가 지원됨을 나타내려면 값을 ["All"]으로 설정합니다. |
| distributionSupported | Boolean | 지정된 배포가 지원되는지 여부를 나타내는 부울 값입니다. false이면 UnsupportedVersions를 제공하면 오류가 발생합니다. |
| unsupportedVersions | List | 지원되지 않는 지정된 배포판의 버전 목록입니다. 지원되는 연산자: - "=" 지정된 버전은 지원되지 않습니다. 예: "=1.2.12" - ">" 지정된 버전보다 큰 모든 버전은 지원되지 않습니다. 예: ">1.1.13" - "<" 지정된 버전보다 작은 모든 버전은 지원되지 않습니다. 예: "<1.3.14" - "..." 범위의 모든 버전은 지원되지 않습니다. 예를 들어 "1.1.2...1.1.15"(오른쪽 값 포함 및 왼쪽 값 제외) |
투표 앱에 대해 구성된 샘플은 다음 매니페스트 파일 예제를 참조하세요.
애플리케이션 구조화
createUiDefinition, ARM 템플릿 및 매니페스트 파일은 애플리케이션의 Helm 차트 옆에 배치합니다.
올바르게 구조화된 디렉터리의 예제는 Azure Vote 샘플을 참조하세요.
Azure Arc 지원 Kubernetes 클러스터를 지원하는 투표 애플리케이션의 샘플은 ConnectedCluster 전용 샘플을 참조하세요.
애플리케이션 의 유효성을 검사하기 위해 Azure Arc 지원 Kubernetes 클러스터를 설정하는 방법에 대한 자세한 내용은 빠른 시작: 기존 Kubernetes 클러스터를 Azure Arc에 연결합니다.
컨테이너 패키징 도구 사용
필요한 아티팩트가 모두 추가되면 패키징 도구를 container-package-app 실행하여 아티팩트의 유효성을 검사하고, 패키지를 빌드하고, Azure Container Registry에 패키지를 업로드합니다.
CNAB는 새로운 형식이며 학습 곡선이 있으므로 패키징 도구를 성공적으로 실행하는 데 필요한 도구 및 부트스트랩 환경을 위한 container-package-app Docker 이미지를 만들었습니다.
패키징 도구를 사용하는 두 가지 옵션이 있습니다. 수동으로 사용하거나 배포 파이프라인에 통합할 수 있습니다.
패키징 도구를 수동으로 실행
패키징 도구의 최신 이미지는 mcr.microsoft.com/container-package-app:latest에서 끌어올 수 있습니다.
다음 Docker 명령은 최신 패키징 도구 이미지를 끌어오고 디렉터리도 탑재합니다.
패키지할 내용이 포함된 디렉터리라고 가정 ~\<path-to-content> 하면 다음 docker 명령이 컨테이너에 /data 탑재됩니다~/<path-to-content>. ~/<path-to-content>는 사용자 고유의 앱 위치로 바꿔야 합니다.
docker pull mcr.microsoft.com/container-package-app:latest
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest
container-package-app 컨테이너 셸에서 다음 명령을 실행합니다. <registry-name>을 ACR의 이름으로 바꿔야 합니다.
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
ACR을 인증하려면 두 가지 옵션이 있습니다. 한 가지 옵션은 앞에서 설명한 대로 사용하는 az login 것이며, 두 번째 옵션은 docker를 실행하여 사용하는 docker login 'yourACRname'.azurecr.io것입니다. 사용자 이름 및 암호를 입력하고(사용자 이름은 ACR 이름이어야 하고 암호는 Azure Portal에서 제공된 생성된 키임) 실행합니다.
docker login <yourACRname.azurecr.io>
다음으로, 아티팩트 반복을 실행하고 cpa verify 하나씩 유효성을 검사하고 오류를 해결합니다. CNAB를 패키지하고 Azure Container Registry에 업로드할 준비가 되면 실행 cpa buildbundle 합니다. 이 cpa buildbundle 명령은 확인 프로세스를 실행하고, 패키지를 빌드하고, Azure Container Registry에 패키지를 업로드합니다.
cpa verify
cpa buildbundle
참고 항목
기존 태그를 덮어쓰려는 경우에만 cpa buildbundle --force를 사용합니다. Azure Marketplace 제품에 이 CNAB를 이미 연결한 경우 대신 매니페스트 파일의 버전을 증가합니다.
Azure Pipeline에 통합
Azure Pipeline에 통합 container-package-app 하는 방법의 예제는 Azure Pipeline 예제를 참조하세요.