개요

cloud init은 클라우드 환경에서 인스턴스를 초기화할 때 사용하는 툴이다.
Ubuntu를 만든 Canonical에서 개발을 주도하고 있으며, 현재 대다수의 클라우드 회사들이 이 툴을 기반으로 인스턴스 초기화를 진행하고 있다.

어떤 인스턴스를 런칭한다고 생각해보자.
그러면 먼저 idc의 물리 자원을 가상화 도구를 이용해서 자원을 분리해낼 것이다.
이제 이 자원에 기본적인 os 세팅이나, 호스트네임, 네트워크 설정 등의 요소를 수행해야 한다.
여기에 사용자가 유저데이터를 넣었다면 이것도 반영을 해주어야할 것이다.
이렇게 물리적 자원이 프로비저닝된 이후에 실제로 자원을 사용자에게 건네주기 전까지 필요한 모든 설정을 할 수 있게 도와주는 것이 바로 cloud init이다.

부팅 프로세스

인스턴스를 세팅하는 데에는 크게 5가지의 단계를 거친다.^[1]

• Detect
  • 먼저 외부의 툴이 프로비저닝된 물리 자원을 탐지하고 cloud init을 발동시킨다.
• Local
  • 인스턴스가 초기화될 설정 파일들을 불러오는 짧은 단계로, 이를 위한 초기 네트워크 설정이 잠시 이뤄질 수 있다.
  • 이 단계에서 가져오는 데이터는 크게 3 가지로 나뉜다.
    • meta data - 인스턴스 플랫폼, 호스트네임 등의 정보
    • vendor data - 클라우드에서 세팅하는 각종 설정 정보
    • user data - 엔드 유저가 설정한 각종 설정 정보(우리가 아는 그 흔한 유저데이터 맞다)
• Network
  • 인스턴스가 본격적으로 세팅이 일어나는 단계로, 네트워크와 디스크 마운팅 등의 작업이 일어난다.
  • 여기에 boothook 등을 통해 유저의 커스텀 설정을 이 단계에서 실행하는 게 가능하다고 한다.
• Config
  • 이것도 세팅을 하는 단계이지만, 여기는 네트워크나 디스크와 다르게 서로 다른 설정들 간에 영향을 주지 않는 세팅들만 반영된다.
• Final
  • 최종 스테이지로, 보통 사용자가 할 법한 각종 설정이 일어난다.
  • 일반적인 유저 데이터는 여기에서 실행된다.

본격적으로 각종 커스텀 설정이 들어가기 시작하는 것은 Network 단계부터로, 이때부터는 다운받아진 cloud.cfg라는 파일의 정보를 통해 세팅이 진행된다.

/etc/cloud/cloud.cfg 파일을 보면, 어떤 모듈들이 간 단계에서 진행됐는지 알 수 있다.
참고로 실행 로그는 /var/log에 떡하니 있다.

유저 데이터 설정

그럼 어떤 식으로 데이터를 설정해서 넣어야 실행이 되는가?

aws에서 EC2를 세팅할 때 많이 봤던 이 유저 데이터처럼 적어도 된다.
이러한 설정은 final 스테이지에서 cc_scripts모듈이 실행해줄 것이다.

하지만 설정을 하는데에는 실상 훨씬 더 많은 방법이 있으며, 유저데이터에 실제로 이런 방식을 통해 데이터를 넣어도 설정에 문제만 없다면 해당 설정을 제대로 반영해서 진행된다.
내 EKS 노드 그룹의 런치 템플릿을 보면 MIME이란 양식을 가장 큰 바운더리 삼아 각종 설정이 들어가는 것을 확인할 수 있다.

구체적으로 이와 같은 양식들이 존재하며, 이들을 적용하기 위해서는 앞단에 #을 다는 것으로 명시할 수 있다.^[2]
단순히 #을 다는 것만으로 세팅하는 게 불안하면 MIME 형식을 쓰면 되는 건데, 자세한 건 아래에서 다루겠다.

cloud config

#cloud-config
password: password
chpasswd:
  expire: False

yaml 형식으로 된 cloud init만의 설정 양식이다.

user data script

#!/bin/sh
echo "Hello World" > /var/tmp/output.txt

우리가 흔히 사용하는 스크립트 방식이다.
왜 유저데이터에 항상 셔뱅을 붙여야만 했던가?
그 이유는 바로 여기에 있다.
유저데이터를 읽을 때 해당 스크립트의 양식을 인식하기 위한 헤더로 사용되기 때문이다.

MIME

Content-Type: multipart/mixed; boundary="===============2389165605550749110=="
MIME-Version: 1.0
Number-Attachments: 2

--===============2389165605550749110==
Content-Type: text/cloud-boothook; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="part-001"

#!/bin/sh
echo "this is from a boothook." > /var/tmp/boothook.txt

--===============2389165605550749110==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="part-002"

bootcmd:
- echo "this is from a cloud-config." > /var/tmp/bootcmd.txt
--===============2389165605550749110==--

각종 양식을 상위에서 아우르는 형식이다.
MIME은 본디 http에서 지원하는 형식 중 하나로 다양한 형식을 한꺼번에 아우를 수 있는 타입이다.
content type에 사용하고자할 형식을 명시하면서 각각을 구분지을 구분자도 명시해준다.
이후에는 위와 같이 각각을 구분자 앞에 --를 붙여서 나눠 작성하면 된다.
최종적으로 MIME을 닫을 때는 끝에도 --을 붙여주어야 한다.

관련 문서

참고

내가 어쩌다 이것까지 파게 됐을까?
나도 하고 싶지 않았다..
EKS의 노드 그룹을 세팅할 때, 특히 아마존2023에서 세팅할 때 ssh 설정과 추가적인 커스텀 런치 템플릿 설정은 양립될 수 없도록 돼있다(최소한 테라폼에선 그렇다).
그래서 결국 ssh도 가능하게 데이터를 전달하기 위해서, 런치 템플릿 유저 데이터 부분에 이렇게 cloud init 양식을 쓰는 방법을 써야 한다..