Azure에서 컨테이너 배포

이 장과 1장에서 컨테이너에 대해 설명했습니다. 컨테이너는 이식성을 포함하여 클라우드 네이티브 애플리케이션에 많은 이점을 제공하는 것을 보았습니다. Azure 클라우드에서 스테이징 및 프로덕션 환경에서 동일한 컨테이너화된 서비스를 배포할 수 있습니다. Azure는 이러한 컨테이너화된 워크로드를 호스팅하기 위한 몇 가지 옵션을 제공합니다.

• AKS(Azure Kubernetes Services)
• ACI(Azure Container Instance)
• 컨테이너용 Azure Web Apps

Azure Container Registry (애저 컨테이너 레지스트리)

마이크로 서비스를 컨테이너화할 때 먼저 컨테이너 "이미지"를 빌드합니다. 이미지는 서비스 코드, 종속성 및 런타임의 이진 표현입니다. Docker API의 명령을 사용하여 Docker Build 이미지를 수동으로 만들 수 있지만 자동화된 빌드 프로세스의 일부로 이미지를 만드는 것이 더 좋습니다.

컨테이너 이미지가 만들어지면 컨테이너 레지스트리에 저장됩니다. 컨테이너 이미지를 빌드, 저장 및 관리할 수 있습니다. 공용 및 프라이빗을 모두 사용할 수 있는 많은 레지스트리가 있습니다. ACR(Azure Container Registry)은 Azure 클라우드에서 완전히 관리되는 컨테이너 레지스트리 서비스입니다. Azure 네트워크 내에 이미지를 유지하여 Azure 컨테이너 호스트에 배포하는 시간을 줄입니다. 다른 Azure 리소스에 사용하는 것과 동일한 보안 및 ID 절차를 사용하여 보안을 설정할 수도 있습니다.

Azure Portal, Azure CLI 또는 PowerShell 도구를 사용하여 Azure Container Registry를 만듭니다. Azure에서 레지스트리를 만드는 것은 간단합니다. Azure 구독, 리소스 그룹 및 고유한 이름이 필요합니다. 그림 3-10에서는 레지스트리를 만들기 위한 기본 옵션을 보여 하며, 이 옵션은 에서 registryname.azurecr.io호스트됩니다.

그림 3-10. 컨테이너 레지스트리 만들기

레지스트리를 만든 후에는 레지스트리를 사용하려면 인증해야 합니다. 일반적으로 Azure CLI 명령을 사용하여 레지스트리에 로그인합니다.

az acr login --name *registryname*

인증되면 docker 명령을 사용하여 컨테이너 이미지를 푸시할 수 있습니다. 그러나 이렇게 하려면 먼저 ACR 로그인 서버의 정규화된 이름(URL)으로 이미지에 태그를 지정해야 합니다. registryname.azurecr.io 형식이 있습니다.

docker tag mycontainer myregistry.azurecr.io/mycontainer:v1

이미지에 태그를 지정한 후 명령을 사용하여 docker push 이미지를 ACR 인스턴스로 푸시합니다.

docker push myregistry.azurecr.io/mycontainer:v1

레지스트리에 이미지를 푸시한 후에는 다음 명령을 사용하여 로컬 Docker 환경에서 이미지를 제거하는 것이 좋습니다.

docker rmi myregistry.azurecr.io/mycontainer:v1

모범 사례로 이미지를 컨테이너 레지스트리에 수동으로 푸시해서는 안 됩니다. 대신 GitHub 또는 Azure DevOps와 같은 도구에 정의된 빌드 파이프라인을 사용합니다. Cloud-Native DevOps 챕터에서 자세히 알아보세요.

ACR 작업

ACR 작업은 Azure Container Registry에서 사용할 수 있는 기능 집합입니다. Azure 클라우드에서 컨테이너 이미지를 빌드하고 관리하여 내부 루프 개발 주기를 확장합니다. 개발 머신에서 로컬로 docker builddocker push 호출하는 대신 클라우드의 ACR 작업에서 자동으로 처리됩니다.

다음 AZ CLI 명령은 컨테이너 이미지를 빌드하고 ACR에 푸시합니다.

# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic

# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1  --registry myContainerRegistry008 --file Dockerfile .

이전 명령 블록에서 볼 수 있듯이 개발 머신에 Docker Desktop을 설치할 필요가 없습니다. 또한 소스 코드와 기본 이미지 업데이트 모두에서 컨테이너 이미지를 다시 빌드하도록 ACR 작업 트리거를 구성할 수 있습니다.

Azure Kubernetes Service

이 장에서는 AKS(Azure Kubernetes Service)에 대해 설명했습니다. 컨테이너화된 클라우드 네이티브 애플리케이션을 관리하는 사실상 컨테이너 오케스트레이터임을 확인했습니다.

ACR과 같은 레지스트리에 이미지를 배포한 후에는 AKS를 자동으로 끌어와 배포하도록 구성할 수 있습니다. CI/CD 파이프라인을 사용하면 업데이트를 신속하게 배포할 때 발생하는 위험을 최소화하도록 카나리아 릴리스 전략을 구성할 수 있습니다. 앱의 새 버전은 처음 프로덕션에서 구성되며 트래픽이 라우팅되지 않습니다. 그런 다음, 시스템은 소수의 사용자를 새로 배포된 버전으로 라우팅합니다. 팀은 새 버전에 대한 신뢰를 얻으므로 더 많은 인스턴스를 배포하고 이전 버전을 사용 중지할 수 있습니다. AKS는 이러한 배포 스타일을 쉽게 지원합니다.

Azure의 대부분의 리소스와 마찬가지로 포털, 명령줄 또는 Helm 또는 Terraform과 같은 자동화 도구를 사용하여 Azure Kubernetes Service 클러스터를 만들 수 있습니다. 새 클러스터를 시작하려면 다음 정보를 제공해야 합니다.

• Azure 구독
• 리소스 그룹
• Kubernetes 클러스터 이름
• 지역
• Kubernetes 버전
• DNS 이름 접두사
• 노드 크기
• 노드 수

이 정보는 시작하기에 충분합니다. Azure Portal에서 만드는 프로세스의 일부로 클러스터의 다음 기능에 대한 옵션을 구성할 수도 있습니다.

• 규모
• 인증
• 네트워킹
• 모니터링
• 태그들

이 빠른 시작에서는 Azure Portal을 사용하여 AKS 클러스터를 배포하는 단계를 안내합니다.

Kubernetes와 연결하는 Azure Bridge

클라우드 네이티브 애플리케이션은 크고 복잡해질 수 있으므로 상당한 컴퓨팅 리소스를 실행해야 합니다. 이러한 시나리오에서는 전체 애플리케이션을 개발 머신(특히 랩톱)에서 호스트할 수 없습니다. Azure Bridge to Kubernetes 는 단점을 해결합니다. 이를 통해 개발자는 AKS 개발 클러스터에서 전체 애플리케이션을 호스팅하는 동안 로컬 버전의 서비스를 사용할 수 있습니다.

준비가 되면 개발자는 종속성을 복제하지 않고 AKS 클러스터의 전체 애플리케이션에 대해 실행하는 동안 변경 내용을 로컬로 테스트합니다. 내부적으로 브리지는 로컬 컴퓨터의 코드를 AKS의 서비스와 병합합니다. 개발자는 Visual Studio 또는 Visual Studio Code를 사용하여 Kubernetes에서 직접 코드를 신속하게 반복하고 디버그할 수 있습니다.

Microsoft 제품 관리의 전 부사장인 Gabe Monroy는 다음과 같이 잘 설명합니다.

각각 자체 구성 및 지원 서비스를 사용하는 수십 개의 구성 요소로 구성된 복잡한 마이크로 서비스 애플리케이션에서 버그를 수정하려고 하는 신입 직원이라고 상상해 보세요. 시작하려면 IDE 설정, 도구 체인 빌드, 컨테이너화된 서비스 종속성, 로컬 Kubernetes 환경, 지원 서비스 모의 등 프로덕션을 모방할 수 있도록 로컬 개발 환경을 구성해야 합니다. 개발 환경 설정과 관련된 모든 시간을 통해 첫 번째 버그를 수정하는 데 며칠이 걸릴 수 있습니다. 또는 Bridge to Kubernetes 및 AKS만 사용할 수 있습니다.