해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 35 - Azure for DevSecOps Operators
인프라 (서버, 네트워크, 스토리지 등)를 클라우드 플랫폼 웹 콘솔에서 설정하는 방식 대신, 코드를 작성하여 관리하는 방식이다.
주요 장점:
재현성: 동일한 코드로 언제든 동일한 환경을 만들 수 있음.
버전 관리: Git 등을 통해 인프라 변경 이력을 추적하고 관리할 수 있음.
자동화: CI/CD 파이프라인 (Azure DevOps, GitHub Actions 등)과 통합하여 배포를 자동화 가능
Bicep은 Azure 리소스를 선언적으로 배포하기 위해 Microsoft가 만든 도메인 특화 언어(DSL, Domain-Specific Language)이다.

특징 1. 선언적 구문: "무엇을 만들겠다"라고 정의하면, Azure가 어떻게 만들지 알아서 처리
특징 2. 간결함: 복잡한 JSON 형식의 ARM 템플릿보다 훨씬 간결하고 가독성이 높음
특징 3. 강력한 도구 지원: VS Code 확장 프로그램을 통해 뛰어난 자동 완성, 구문 강조, 오류 탐지 기능을 제공
Terraform (테라폼): Bicep과 함께 언급된 가장 인기 있는 IaC 도구로, Multi-Cloud(Azure, AWS, GCP 등)를 지원하는 것이 큰 장점인 Iac 도구
Terraform AzAPI Provider: Azure에 새로운 기능이 출시되었을 때, 공식 Terraform 공급자 (azurerm) 가 업데이트되기 전에 해당 기능을 바로 사용할 수 있게 해주는 특별한 공급자
VS Code 확장 프로그램: Bicep 또는 Terraform 코드를 쉽게 작성하도록 도와주는 도구
배포 전략:
로컬 CLI 배포 : 개발/테스트 단계에서 사용하는 방식
CI/CD 파이프라인 (프로덕션) : Azure DevOps, GitHub Actions 등을 통해 코드를 푸시하면 자동으로 배포가 실행되는 방식
정적 코드 분석 (Static Code Analysis): IaC 코드를 배포하기 전에 보안 취약점이나 설정 오류가 있는지 자동으로 검사하는 도구
배포를 시작하기 전에, 프레젠테이션에서 언급된 다음 도구들이 설치되어 있어야 한다.
PowerShell 7
Azure CLI: az 명령어를 통해 Azure를 관리하는 명령줄 도구 (Bicep 설치도 이를 통해 수행)
Visual Studio Code: main.bicep 파일을 작성하고 편집할 코드 에디터
kubectl: 배포된 쿠버네티스 클러스터에 명령을 내리기 위한 도구
main.bicep 파일
// main.bicep
param clusterName string = 'myAKsCluster'
@description('The location of the Managed Cluster resource.')
param location string = resourceGroup().location
@description('Optional DNS prefix to use with hosted Kubernetes API server type.')
param dnsPrefix string
@description('Disk size (in GB) to provision for each of the agent pool nodes. This value ranges from 0 to 1023. Specifying 0 will apply the default disk size for that agentPoolSize.')
@minValue(0)
@maxValue(1023)
param osDiskSizeGB int = 0
@description('The number of nodes for the Cluster.')
@minValue(1)
@maxValue(50)
param agentCount int = 3
@description('The size of the Virtual Machine.')
param agentVmSize string = 'Standard_D2_s_v3'
@description('User name for the Linux Virtual Machines.')
param linuxAdminUsername string
@description('Configure all linux machines with the SSH RSA public key string. Your key should include three parts, for example \'ssh-rsa ...Key... user@host\'.')
@secure()
param sshRSAPublicKey string
resource aks 'Microsoft.ContainerService/managedClusters@2021-02-01-preview' = {
name: clusterName
location: location
identity: {
type: 'SystemAssigned'
}
properties: {
dnsPrefix: dnsPrefix
agentPoolProfiles: [
{
name: 'agentpool'
osDiskSizeGB: osDiskSizeGB
count: agentCount
vmSize: agentVmSize
osType: 'Linux'
mode: 'System'
}
]
linuxProfile: {
adminUsername: linuxAdminUsername
ssh: {
publicKeys: [
{
keyData: sshRSAPublicKey
}
]
}
}
}
}
output controlPlaneFQDN string = aks.properties.fqdn
가장 먼저 로컬 터미널 환경 (PowerShell)에서 Azure 계정으로 인증을 수행해야 한다.
# Azure 로그인 창을 띄워 인증을 수행
az login
로그인이 성공하면 터미널에 구독(Subscription) 정보가 JSON 형식으로 출력된다.
이후, AKS 클러스터와 관련된 모든 리소스(VM, 디스크, 네트워크 등)를 담을 논리적인 컨테이너(폴더)를 만든다.
# 'myResourceGroup'이라는 이름으로 'eastus' 리전에 리소스 그룹을 생성 명령어
az group create --name myResourceGroup --location eastus
해당 명령어를 실행 후, provisioningState가 Succeeded로 표시되면 성공이다.
AKS 클러스터를 구성하는 리눅스 VM (Worker Node)에 접속할 때 필요한 SSH 키를 Azure 내에 생성하고 저장해야 한다.
# 2단계에서 만든 리소스 그룹 내에 'mySSHKey'라는 이름으로 SSH 키를 생성
az sshkey create --name mySSHKey --resource-group myResourceGroup
해당 명령을 실행하면 터미널에 publicKey 값이 출력된다.
이때, 이 값(예: "ssh-rsa AAAA...")을 반드시 복사하여 메모장 같은 곳에 임시로 저장해 두어야 하고, 해당 키는 4단계에서 Bicep 배포의 핵심 파라미터로 사용된다.
준비된 main.bicep 파일과 파라미터 (3단계의 SSH 키) 를 사용하여 실제 AKS 클러스터 배포를 시작한다.
# 'myResourceGroup'에 'main.bicep' 파일을 기반으로 배포를 생성
az deployment group create --resource-group myResourceGroup `
--template-file main.bicep `
--parameters dnsPrefix=myAKsCluster `
linuxAdminUsername=Netrunner `
sshRSAPublicKey="[3단계에서 복사한 SSH 공개 키 전체를 여기에 붙여넣기]"
--resource-group: 2단계에서 만든 리소스 그룹을 대상으로 지정
--template-file: main.bicep 파일을 지정
--parameters: Bicep 파일 내 param으로 선언된 변수들의 값을 전달
dnsPrefix: 클러스터의 고유 DNS 이름
linuxAdminUsername: 리눅스 노드의 관리자 계정 이름
sshRSAPublicKey: 3단계에서 복사한 publicKey 값
AKS 클러스터 배포가 완료되면, 로컬 PC의 kubectl이 해당 배포 클러스터와 통신할 수 있도록 자격 증명 (인증서, 주소 등)을 가져와야 한다.
# 'myResourceGroup'에 있는 'myAKsCluster'의 자격 증명을 가져오는 명령어
az aks get-credentials --resource-group myResourceGroup --name myAKsCluster
해당 명령은 C:\Users\사용자명\.kube\config 파일에 myAKsCluster의 접속 정보를 자동으로 merge해 준다.
마지막으로, kubectl 명령을 통해 클러스터가 정상적으로 응답하는지 최종 확인하면 된다.
# 클러스터를 구성하는 노드들의 목록 조회
kubectl get nodes
터미널에 main.bicep에서 agentCount: 3으로 설정한 대로 3개의 노드가 Ready 상태로 표시되면 성공이다.
추가적으로, 버전 정보(예: v1.27.7)도 함께 확인할 수 있다.

추가적으로, Azure Portal에 접속하여 myResourceGroup에 myAKsCluster 리소스가 실제로 생성되었는지, '노드 풀' 설정에 3개의 노드가 정상적으로 실행 중인지 시각적으로 확인하며 실습을 마무리한다.
해당 실습은 VM 3대와 Premium SSD, Public IP 등을 사용하므로 Azure 크레딧이 없는 경우 비용이 발생한다.
실습이 끝나면, 생성된 모든 리소스를 한 번에 삭제하여 추가 과금을 방지해야 하며, 2단계에서 만들었던 리소스 그룹을 통째로 삭제하면 된다.
# 'myResourceGroup'과 내부의 모든 리소스 (AKS, VM, 디스크 등) 가 영구 삭제
az group delete --name myResourceGroup --yes --no-wait