이 모든 것은 windows vm을 회사의 cloud 환경에 띄우기 위해 시작되었다.
이것을 하기 위해 cloud-init이 무엇인지 알게 되었고, 구글링하고 구글링하고 또 구글링하고…
구글링했던 지난 날이 아까워서라도 남겨놔야겠다.
cloud-init
cloud-init은 vm을 datasource를 기반으로 초기화하기 위해 vm 내부에서 동작하는 프로그램이다.
애석하게도 linux 계열의 guest OS만 지원하고, windows를 guest OS로 사용한다면 cloudbase-init을 설치해야 한다.
큰 뼈대는 cloud-init이나 cloudbase-init이나 동일하므로 cloud-init을 기준으로 설명하겠다.
(실제로도 cloudbase-init의 설명을 읽다보면 cloud-init을 기준으로 다른 점만 기술되어있는 느낌이다.)
datasource
datasource란 metadata와 userdata, 그리고 vendordata를 포함한 instance의 data를 의미한다.
metadata는 intstance 관리를 위해 cloud platform가 설정하는 정보로, instance id나 hostname, ssh-key 등을 설정할 수 있다.
userdata는 말그대로 사용자가 설정하는 데이터이고, user와 group, write_files, bootcmd/runcmd 등을 설정할 수 있다.
vendordata는 cloud platform이 정하는 userdata 급의 data로, 그 항목은 userdata와 동일하다. 이 때 이를 사용하고 말고는 사용자가 결정한다.
datasource의 종류
이 datasource를 얻어오는 방법은 크게 두 가지인데, local로 얻어오는 방법과 network로 얻어오는 방법이다.
local로 얻어오는 방법은 datasource를 iso파일로 생성하여 instance에 삽입한 것을 읽어오는 것이고,
cloud-init에서 분류하는 datasource 종류 중 NoCloud(cloud platform을 사용하지 않는 경우를 의미하며 cloud-config format 사용), Config Drive(Openstack format 사용), Alt Cloud(RHEvm, vShpere) 등이 있다.
network로 얻어오는 방법은 cloud platform이 제공하는 metadata service를 통해 얻어오는 방법이며,
Openstack, EC2, GCE, Azure, Aliyun 등 cloud platform의 종류별로 cloud-init이 구분하고 있다.
cloud-init 동작 과정
cloud-init은 각 모듈이 systemd의 service로 등록되어 instance의 booting 과정 중에 실행된다.
모듈별 동작은 크게 의미 없으니 다음 그림처럼 굵직하게만 살펴보겠다.
local datasource 탐색 & network configuration 결정
cloud-init이 실행되면 가장 우선적으로 local datasource를 탐색하고, 어떤 network configuration을 사용할 지 결정한다.
network configuration을 ‘결정’한다고 표현하는 것은, cloud-init은 netplan(ubuntu 18.04 기준)과 같은 네트워크 서비스에 설정을 집어넣는 역할까지만 하기 때문이다.
실제 network configure는 guest os의 네트워크 서비스가 해준다.
만약 local datasource가 존재하지 않는다면 fallback 로직을 타게 되는데, cloud-init에서는 이를 dhcp로 규정하고 있다.
사용자가 원하지 않는다면 cloud-init의 network configuration을 disable할 수도 있다.
이렇게 cloud-init이 결정한 network configuration을 바탕으로 guest os의 네트워크 서비스가 세팅을 해준 뒤에 cloud-init는 다음 작업을 수행한다.
network datasource 검색
local datasource가 있었다면 static이던 dhcp던 네트워크가 설정된 후 이 과정은 패스할 것이고,
local datasource가 없었다면 dhcp로 네트워크가 설정된 후 이 과정을 진행할 것이다.
cloud-init의 소스에는 datasource 종류별로 어떤 metadata service를 사용할 지 하드코딩되어있다.
(하드코딩이라도 표현해도 될지는 잘 모르겠다. 무튼 요지는 cloud-init이 지원하는 platform의 metadata service만 사용 가능하다는 점이다.)
이 부분은 잠시 뒤 metadata service에서 자세히 다뤄보겠다.
instance 초기화 진행
이제 얻어온 datasource를 바탕으로 instance를 초기화한다.
이와 같은 과정을 거쳐 cloud-init은 vm을 personalize한다.
이제 cloud-init을 설명하면서 여러 차례 언급되었던 metadata service에 대해 알아보자.
metadata service
metadata service는 instance를 관리하는 데에 필요한 정보를 검색하는 서비스이다.
cloud-init이 이 서비스를 instance를 초기화할 때 사용하는 대표적인 예일 뿐, 사용자도 해당 서비스를 사용하여 instance의 metadata를 조회할 수 있다.
metadata service 사용 방법
이 서비스는 rest api로 제공되는데, cloud platform별로 사용 방법이 다르다.
openstack의 경우 metadata를 파일로 한 번에 리턴해주지만, 대부분의 플랫폼은 metadata 항목마다 request를 보내어 그 값을 리턴받는다.
사용 방법은 각 공홈에 나와있는데, 대표적으로 ec2의 metadata service 사용방법을 읽어보면 감이 올 것이다.
여기에서 내가 궁금했던 것이 두 가지 있는데, 첫 번째는 openstack와 ec2의 metadata service는 왜 169.254.169.254를 사용하는가?였다.
이것은 GCE와 Aliyun은 저 ip를 사용하지 않는다는 것을 몰랐을 때 생긴 궁금증이라, 저 ip에 꽂혀서 삽질했던 지난 날을 생각하면… (부들부들)
그리고 두 번째는 이 http request에는 instance에 대한 아무런 정보도 없는데 metadata service가 이 instance specific한 어떻게 돌려주는가?였다.
우선 두 번째 의문부터 풀어보도록 하자.
openstack의 metadata service 동작 과정
instance를 특정짓는 과정을 알아보기 위해서는 metadata service가 어떤 방식으로 돌아가는 지 알 필요가 있다.
모든 플랫폼을 다 살펴볼 순 없으므로 openstack을 기준으로 조사를 했다.
(작성중…)