90DaysOfDevOps (Day 35)

고태규·2025년 11월 1일
0

DevOps

목록 보기
34/50
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.


Day 35 - Azure for DevSecOps Operators


1. IaC 와 Azure Bicep


1-1. IaC (Infrastructure as Code)

인프라 (서버, 네트워크, 스토리지 등)를 클라우드 플랫폼 웹 콘솔에서 설정하는 방식 대신, 코드를 작성하여 관리하는 방식이다.

  • 주요 장점:

    • 재현성: 동일한 코드로 언제든 동일한 환경을 만들 수 있음.

    • 버전 관리: Git 등을 통해 인프라 변경 이력을 추적하고 관리할 수 있음.

    • 자동화: CI/CD 파이프라인 (Azure DevOps, GitHub Actions 등)과 통합하여 배포를 자동화 가능

1-2. Azure Bicep

Bicep은 Azure 리소스를 선언적으로 배포하기 위해 Microsoft가 만든 도메인 특화 언어(DSL, Domain-Specific Language)이다.

  • 특징 1. 선언적 구문: "무엇을 만들겠다"라고 정의하면, Azure가 어떻게 만들지 알아서 처리

  • 특징 2. 간결함: 복잡한 JSON 형식의 ARM 템플릿보다 훨씬 간결하고 가독성이 높음

  • 특징 3. 강력한 도구 지원: VS Code 확장 프로그램을 통해 뛰어난 자동 완성, 구문 강조, 오류 탐지 기능을 제공


1-3. 추가적인 용어

  • 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 코드를 배포하기 전에 보안 취약점이나 설정 오류가 있는지 자동으로 검사하는 도구



2. Azure Bicep을 활용한 AKS 클러스터 배포


2-0단계: 실습 환경 준비

배포를 시작하기 전에, 프레젠테이션에서 언급된 다음 도구들이 설치되어 있어야 한다.

  • 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

2-1단계: Azure 로그인

가장 먼저 로컬 터미널 환경 (PowerShell)에서 Azure 계정으로 인증을 수행해야 한다.

# Azure 로그인 창을 띄워 인증을 수행
az login

로그인이 성공하면 터미널에 구독(Subscription) 정보가 JSON 형식으로 출력된다.

2-2단계: 리소스 그룹(Resource Group) 생성

이후, AKS 클러스터와 관련된 모든 리소스(VM, 디스크, 네트워크 등)를 담을 논리적인 컨테이너(폴더)를 만든다.

# 'myResourceGroup'이라는 이름으로 'eastus' 리전에 리소스 그룹을 생성 명령어
az group create --name myResourceGroup --location eastus

해당 명령어를 실행 후, provisioningState가 Succeeded로 표시되면 성공이다.

2-3단계: AKS 노드 접속용 SSH 키 생성

AKS 클러스터를 구성하는 리눅스 VM (Worker Node)에 접속할 때 필요한 SSH 키를 Azure 내에 생성하고 저장해야 한다.

# 2단계에서 만든 리소스 그룹 내에 'mySSHKey'라는 이름으로 SSH 키를 생성
az sshkey create --name mySSHKey --resource-group myResourceGroup

해당 명령을 실행하면 터미널에 publicKey 값이 출력된다.

이때, 이 값(예: "ssh-rsa AAAA...")을 반드시 복사하여 메모장 같은 곳에 임시로 저장해 두어야 하고, 해당 키는 4단계에서 Bicep 배포의 핵심 파라미터로 사용된다.

2-4단계: Bicep 템플릿 배포 실행 (AKS 클러스터 생성)

준비된 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 값

2-5단계: kubectl 자격 증명 획득 (Kubeconfig 설정)

AKS 클러스터 배포가 완료되면, 로컬 PC의 kubectl이 해당 배포 클러스터와 통신할 수 있도록 자격 증명 (인증서, 주소 등)을 가져와야 한다.

# 'myResourceGroup'에 있는 'myAKsCluster'의 자격 증명을 가져오는 명령어
az aks get-credentials --resource-group myResourceGroup --name myAKsCluster

해당 명령은 C:\Users\사용자명\.kube\config 파일에 myAKsCluster의 접속 정보를 자동으로 merge해 준다.

2-6단계: 클러스터 연결 테스트

마지막으로, kubectl 명령을 통해 클러스터가 정상적으로 응답하는지 최종 확인하면 된다.

# 클러스터를 구성하는 노드들의 목록 조회
kubectl get nodes

터미널에 main.bicep에서 agentCount: 3으로 설정한 대로 3개의 노드가 Ready 상태로 표시되면 성공이다.

추가적으로, 버전 정보(예: v1.27.7)도 함께 확인할 수 있다.

2-7단계: Azure Portal에서 시각적 확인 (검증)

추가적으로, Azure Portal에 접속하여 myResourceGroup에 myAKsCluster 리소스가 실제로 생성되었는지, '노드 풀' 설정에 3개의 노드가 정상적으로 실행 중인지 시각적으로 확인하며 실습을 마무리한다.

2-8단계: 삭제단계

해당 실습은 VM 3대와 Premium SSD, Public IP 등을 사용하므로 Azure 크레딧이 없는 경우 비용이 발생한다.

실습이 끝나면, 생성된 모든 리소스를 한 번에 삭제하여 추가 과금을 방지해야 하며, 2단계에서 만들었던 리소스 그룹을 통째로 삭제하면 된다.

# 'myResourceGroup'과 내부의 모든 리소스 (AKS, VM, 디스크 등) 가 영구 삭제
az group delete --name myResourceGroup --yes --no-wait


0개의 댓글