[OSSCA] Challengers 2주차 Azure Bicep

2022 오픈소스 컨트리뷰션 아카데미 "NHN Toast Power Platform Connector" 프로젝트에 참여하면서 Challengers 기간 동안 배운 내용을 기록하였습니다.
멘토님이 직접 강의하신 Bicep으로 애저 리소스 프로비저닝하기를 추가로 공부하면서 기록하였습니다.

✅ 애저 리소스 프로비저닝

Provisioning
사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

Cloud에 Application을 배포하기 위해 서버(Virtual machine, Docker machine, Azure funtion etc...)가 필요하고 서버가 돌아가기 위해 필요한 것은 Azure Cloud 안의 모든 인스턴스가 돌아가야 한다

서버가 돌아가려면 필요한 리소스(인스턴스)

• 컴퓨터, CPU, 램, 네트워크, 네트워크 인터페이스 카드, IP 주소, 가상 머신, 스토리지 계정, 웹앱, 데이터베이스 등등
• 이때, 무료인 리소스가 있고 유료(CPU, 램, 보안, 방화벽 등등)인 리소스도 있으므로 나한테 가장 맞는 서버, 네트워크를 선택하고 그에 따라 적절히 용량을 구매하는 것이 리소스를 잘 활용할 수 있는 방법이다.

이때 Azure Cloud의 모든 인스턴스를 Resource라고 한다. 그리고 Cloud에 Resource를 생성하는 것을 Provisioning이라고 한다.

Provisioning의 여러 가지 방법

• Azure 포탈 : 마우스 클릭해서!
• Azure CLI, Azure Power Shell : Shell prompt 안에서 command를 이용
• Azure API : Azure SDK를 이용해서 API를 직접 호출하는 방식
• ARM template : 리소스 그룹, 구독, 관리 그룹 또는 테넌트에 배포할 하나 이상의 리소스를 정의하는 템플릿 파일. 템플릿을 사용하여 일관되고 반복 가능한 방식으로 리소스를 배포할 수 있다. ARM 템플릿 파일에는 JSON 및 Bicep의 두 가지 유형이 있다

Azure resource management

이때 Provisioning의 핵심은 바로 Azure Resource Manager(ARM)이다.

• Azure에서 리소스를 정의하고 배포하고 관리하는 데 사용되는 서비스다. (즉 리소스 정의 문서라고 생각하자!)
• Resource Manager를 사용하여 Azure 구독에서 리소스를 만들고, 업데이트하고, 삭제할 수 있다.
• Azure Portal을 비롯한 다양한 도구를 사용하여 Resource Manager와 상호 작용할 수 있다.
• 또한 Resource Manager는 배포 후 리소스를 관리하는 데 도움이 되는 액세스 제어, 감사 및 태그 지정과 같은 일련의 다른 기능도 제공한다.
• ARM이 관리하는 가장 논리적인 단위는 Azure Resource Group이다. 모든 Azure Resource는 반드시 하나의 Azure Resource Group 안에 속해있어야 한다.

명령형 방식 vs 선언형 방식

ARM은 크게 명령형과 선언형 2가지 방식으로 Provisioning을 한다.

명령형

위의 사진은
리소스 그룹을 명령어로 생성하고 rscgrp 변수에 저장 -> 저장소 account를 명령어로 생성함
이때 rscgrp는 리소스 그룹의 실행상태를 저장한 변수값!

• 개별 리소스 별로 명령어 실행(내가 저장소 account를 만들고 싶으면 저장소 account 생성 명령어를 쓰면 된다
• 개별 리소스마다 실행 결과를 어딘가에 저장해야 함, 즉 리소스 실행 상태를 알아야 한다.
• 리소스를 만들고 그 리소스의 결과를 가지고 다른 리소스를 만들게 되는 경우가 발생한다. 다양한 리소스를 활용하기 위해서는 개별 리소스에 대한 상태를 저장해야 한다(메모리, 물리적인 파일 등등)
• EX) Azure CLI, Azure Power Shell, Azure SDK
  
  
  
  

선언형

ARM template부분의 사진임!
varibales : 변수 선언
resource : 변수를 참조하긴 하지만 ARM template 안에서 리소스가 만들어지진 않음! ARM template 자체를 실행시킨 후에야 리소스가 생성!

• 전체 리소스를 한번에 정의! 개별 리소스마다 정의할 수 있으나 내가 원하는 리소스를 정의(선언)하면 된다.
• 해당 리소스가 어떤 형식으로 만들어지는지 혹은 실행 상태가 중요하진 않다. 그냥 만들어지기만 하면 된다.
• 상태를 저장하는데 관심 없음~~~
• EX) ARM template

✅ Bicep은 무엇인가요?

ARM Template의 문제점

선언형 방식의 대표주자가 바로 ARM 템플릿인데...
구조(Json 객체로 이뤄짐)가 복잡해서 사용하기 힘들었다고 한다... 진입장벽과 러닝 커브가 높다는 것!! 이는 유지보수하기에 어렵다는 의미를 갖는다.

따라서 ARM 템플릿의 러닝 커브를 낮춰보자! -> 👐ARM 템플릿의 DSL을 만들어보자!👐 -> 굳이 개발자가 작성해야 하는 부분과 굳이 안 해도 되는 부분이 있는데 굳이 안 해도 되는 부분을 빼서 추상화 시켜보자! -> Bicep 탄생!

Bicep

Bicep은 선언적으로 Azure 리소스를 배포하는 데 사용되는 Resource Manager 템플릿 언어이다. Bicep은 DSL(Domain-Specific Language)로, 특정 시나리오 또는 ‘도메인’을 위해 설계되었다.

• ARM 템플릿은 JSon 객체인데 Json 객체는 정해진 스키마가 있다. 즉, 어떤 데이터는 어느 부분으로 가야 한다는 정해진 영역이 있다. 그래서 규격대로 작성해야 함. 반면에 Bicep은 정해진 규격이 없어 자유도가 높다!!
  
  
  
• Bicep 파일을 컴파일하면 자동으로 ARM 템플릿이 생성되는데 컴파일시 문법 오류를 체크해준다!
• 크로스 플랫폼 지원(Window, Mac, Linux 모든 운영체제에서 사용 가능)

✅ 실습

Bicep 설치 및 ARM template 생성

먼저 Visual Studio code에 가서 bicep extesion 설치 후

az bicep upgrade

az bicep version 
// 22.07.19 기준 0.8.9 

az login
// Microsoft Azure 계정으로 로그인
// Azure 구독해야 로그인이 된다

위의 코드를 차례대로 진행한다.
로그인이 아주 잘 되었군!

그리고 루드 티렉토리 아래에 infra라는 폴더를 생성하고 main.bicep 파일을 만든다.

az bicep build -f main.bicep

위의 코드처럼 빌드시켜 ARM Template를 생성한다! main.json이 생성된 것을 볼 수 있다.

→ bicep 파일이랑 json 파일 한번 비교해보면 bicep이 엄청 간단하다는 것을 알 수 있다!
→ 현재 bicep에는 아무런 코드가 없다(그래서 "resources" key의 value 부분이 null이징! )

Bicep의 핵심

외쳐... Bicep의 핵심..!!! 리소스 Provisioning할 때 필요한 요소이다! 이때 Resource는 무조건!!! 필수로!! 적어줘야 한다! 나머지는 빠져도 상관없음

❗ Parameter ❗

❗ Variable ❗

❗ Resource❗

❗ Output ❗

Define resources with Bicep and ARM templates

위 링크 가서 원하는 리소스의 Template format을 복사해서 bicep에 붙여넣기 하면 된다!!

Parameter

파라미터 정의는 다음과 같다!

param name string // 필수로 외부에서 값을 넘겨줘야 함
param env string = 'dev' // 외부에서 값을 입력받아도 됨, 따로 입력이 없다면 default 값은 dev다.

이때 default값을 따로 지정해주지 않으면 반드시 다음과 같이 외부에서 값을 넘겨줘야 한다!

az deployment group create -n oca -g rg-oca-krc -f main.bicep -p name=oca

Terminal에 위의 코드를 실행시키면 bicep으로 리소스 그룹을 생성할 수 있는데(Provisioning), 이때 name은 파라미터로 사용자가 필수로 값을 건내야 한다.

이때 사용자로부터 입력을 받을 때 선택지 중에서만 입력값을 받아야 한다면? @allowed를 활용한다!

@allowed([
  'Standard_LRS'
  'Standard_GRS'
])
param sku string = 'Standard_LRS'

위의 코드의 경우 sku는 사용자의 입력을 받을 경우 'Standard_LRS', 'Standard_GRS' 이 두 가지 값만 받아들일 수 있다 라고 한정한다. 이때 아무값이 들어오지 않으면 'Standard_LRS'로 정의한다.

Var

var rg = 'rg-${name}-${env}' // 파라미터를 받아서 리소스 그룹 이름으로 설정

위의 코드를 통해 파라미터를 전달받을 것을 이용해 리소스 그룹 이름 변수를 설정해 놓았다!

추가 활용 예시는 다음과 같다!

var metadata = {
	longName: '{0}-${name}-${locationCode}' // {0} 부분은 placeholder
    shortName: '{0}${name}${locationCode}'
}

resource st 'Microsoft.Storage/storageAccounts@2021-02-01' = {
     name : format(metadata.shortName, 'st') // placeholder는 'st'다!  

빌드(az bicep build -f main.bicep)하고 실행시켜 보면!! ARM 파일에 다음과 같이 생성된 것을 볼 수 있다!!

ARM 파일은 무조건 파라미터 변수 순서로 작성해야 하는데 bicep은 자유도가 높아서 아무렇게 작성해도 가능하다. 계속 바이셉에서 작성하고 빌드(az bicep build -f main.bicep) 해주면 된다!

Resources

• < resource identifier > : resource가 가리키는 객체 이름
• < namespace > : 리소스가 속한 namespace
• < type > : namespace 밑에 어떤 resource인지 resource type을 적어준다
• @< api version > : 내가 리소스를 provisioning 하기 위한 api 버전이 있음!
• { } 안에 리소스 정의!

보면 같은 이름의 namespace/type이 있는데 @api version이 날짜별로 다른 것을 확인할 수 있다! 우리는 가장 최신 날짜의 api를 사용하면 된다!

resource identifier에 빨간 줄 혹은 노란 줄이 생기면 드래그 하고 마우스 커서를 가져가면 어떤 properties가 필요한지 뜬다!! 빨간 줄 or 노란 줄이 뜨면 안 된다!! 또한 Define resources with Bicep and ARM templates를 보면서 필요한 properties를 채우면 된다!

bicep 내용을 어떻게 썼는지 보고 싶다면 nhn-toast-notification-service-custom-connector
여기를 참고!!

Output

output id string = st.id // 리소스(여기서는 storage 리소스!)의 id값을 받음
output name string = st.name  // 리소스의 name 값을 받음

빌드 및 배포

bicep으로 빌드(컴파일)하고 배포 하는 코드는 다음과 같다!!!! az deployment group 참고!!

az bicep build -f main.bicep
az deployment group create -n oca -g rg-oca-krc -f main.bicep -p name=oca

-n 옵션 : 배포하는 이름
-g 옵션 : 리소스 그룹 이름

bicep을 provisioning하면 이런 아웃풋이 나오고

Azure Portal에서도 확인 가능하다!

참고로 웹브라우저 상에서도 리소스를 만들어볼 수 있다고 한다~~