Judaeng
Terraform Up & Running (2) - 왜 테라폼인가? 본문
책을 통해 테라폼의 기본 개념, 정의 등을 공부하고 설치에서 운영까지 알아보자.
모르는 단어나 어려운 개념들은 링크를 달아서 알아보도록 하겠습니다.🤗
소프트웨어의 전달(Software Delivery)은 사용자가 제작된 코드를 원활히 사용할 수 있게 하는 데 필요한 모든 작업 단계를 포함한다.
예를 들어, 상용 환경 서버에 코드를 적용한다거나, 장애와 순간적인 대규모 트래픽을 수용할 수 있도록 코드를 탄력적으로 구성하거나, 외부 공격에 보호받을 수 있도록 보안 사항을 추가하는 작업 등이 포함된다.
데브옵스
코드형 인프라란 무엇인가?
코드형 인프라의 장점
테라폼의 동작 방식
테라폼이 다른 코드형 인프라 도구와 다른 점은 무엇인가?
데브옵스
불과 몇 년 전까지도 소프트웨어를 구성하기 위해서는 많은 물리 장비들을 직접 관리하고, 운영해야 했다.
데이터 센터에 서버 랙과 물리 서버들을 위치시키며, 네트워크 연결 작업, 항온 항습부터 전력 이중화까지 여러 물리적인 작업을 고려해야 했다.
일반적으로는 서버 운영을 책임지는 운영조직(Ops)이 이와 같은 작업을 담당하고, 구성된 서버에 올라가는 소프트웨어를 개발하고 기능을 개선하는 일은 개발조직(Dev)에서 담당한다.
이와 같은 구조에서 서비스를 할 때는 개발팀이 애플리케이션을 개발하고 배포할 수 있도록 구성(Build)하고, '보이지 않는 벽'을 통해 역할과 책임을 함께 운영 조직으로 넘긴다고 한다.
그 후 운영 조직이 직접 애플리케이션의 배포와 동작 방법을 파악하여 서비스를 수행하게 된다고 한다.
사실 이러한 절차는 서버를 위치시키고 케이블을 구성하는 물리적 작업이 동반되므로 팀 간에 역할 분리가 불가피했다고 한다.
운영 조직 안에서도 물리적인 작업 이외에 소프트웨어 설치와 동작을 위한 의존성이 있는 패키지 설치 등 코드 스크립트 작업도 존재하지만, 대부분은 물리적인 작업처럼 담당자가 수동으로 수행하였다.
이러한 절차는 꽤 오랫동안 변화되지 않았고 서비스 규모가 급속도로 커지는 상황에서는 용량 관리와 증설 계획을 꼼꼼히 준비하였어도 대응이 쉽지 않았다.
실제로 소프트웨어의 서비스 투입 절차가 수동으로 이루어지므로 서버의 수가 많을수록 배포는 느려지고 다양한 변수가 생겨 작업이 쉽지 않았다.
만약 운영 조직의 실수로 일부 서버의 설정이 달라지면, 서비스가 불안정해져 품질에 대한 사용자들의 불만으로 이어진다.
결과적으로 많은 이상 현상들이 나타나며, 개발 조직이 '개발 환경에서 잘 돌아가서 어떤 문제인지 알기 어렵다'라고 하면 장애 현상이 심해지고 점검 시간이 점점 늘어나며 서비스 문제도 자주 발생하게 된다.
이렇게 매 서비스 릴리즈(Release) 후 새벽 장애 대응까지 하면 운영 조직은 릴리즈 주기를 일주일에 한 번으로 바꾸게 되고, 점차 한 달에 한 번, 반년에 한 번까지 바꾸게 된다.
긴 주기에 한 번 릴리즈를 하게 되면 모든 팀이 모여서 프로젝트의 코드를 통합할 때 코드 충돌이 일어날 수밖에 없게 되고, 결국 아무도 품질을 안정화할 수 없게 된다.
이에 따라 서로의 이해관계에 불만이 발생하며, 이러한 불협화음들은 서비스 품질에 직접적인 영향을 주어 회사 비즈니스에도 영향을 미친다.
하지만 최근에 많은 회사가 직접 데이터 센터를 관리하지 않고 클라우드를 사용하면서 개발과 운영이 분리되었던 환경에 많은 변화가 이루어지고 있다. 아마존 웹 서비스(Amazon Web Service, AWS), 마이크로소프트 애저(Microsoft Azure), 구글 클라우드(Google Cloud)를 통해 물리 장비 관리에 쏟던 시간 대부분을 소프트웨어 구성과 형상 관리, 그리고 배포 자동화 도구와 방법을 고민하게 되었다.
또한, 시스템 운영 업무 역시 해당 도구들로 서비스 정책을 고려하여 자동화를 통해 코드 형태로 형상을 관리하는 업무로 점점 변화하고 있다.
결과적으로, 소프트웨어를 구성하기 위해 개발과 운영 조직이 함께 일해야 하는 시간이 많아졌으며, 두 팀 간의 경계도 허물어지고 있다.
회사 정책에 따라서 개발 조직은 애플리케이션 코드 개발의 책임, 운영 조직은 운영 책임으로 명확하게 나뉜 곳도 있으나, 서로 간의 업무를 예전보다 더 많이 공유하며, 함께 일하고 함께 문제를 해결해야 한다는 것은 모두 다 공감하는 부분이 되었다.
이런 변화와 움직임이 데브옵스(DevOps)가 등장한 배경이라고 한다.
데브옵스의 목적은 소프트웨어를 전달하기 위한 절차와 방법을 훨씬 더 효율적으로 만드는 것이다.
데브옵스는 소스 코드를 매번 수동으로 통합하고 오류를 눈으로 검출해야 하는 악몽에서 벗어나 코드를 지속해서 통합하고 이상 유무를 자동으로 검증하며, 항상 배포 가능한 상태로 만들 수 있다고 한다.
한 달에 한 번 배포 작업이 있었다면, 이제는 하루에 수십 번 혹은 코드를 커밋(commit)할 때마다 배포할 수 있게 되었다.
또한, 서비스 장애와 중지 시간을 고려하여 자동으로 복구할 수 있도록 구성되었으며, 자동으로 복구하지 못할 때는 시스템을 통한 모니터링과 경고로 문제 상황을 충분히 감지할 수 있게 되었다고 한다.
이러한 데브옵스로의 변화를 실천에 옮기고 있는 회사의 결과는 매우 놀랍다고한다.
예를 들어, 노드스트롬(Nordstrom)사에서는 데브옵스의 모범사례를 조직에 도입하여, 한 달에 기능 업데이트를 두 배 정도 더 할 수 있었다고 한다.
또한, 결함을 절반으로 줄였으며, 서비스 기획부터 개발과 상용 적용까지의 시간을 60% 줄일 수 있었다고 한다.
또한, 상용 서비스 환경에서 발생하는 문제를 60~90% 줄였다고 한다.
그리고 HP의 레이저젯(LazerJet) 펌웨어를 개발하는 조직에서는 개발자들이 실제로 업무에서 신규 기능을 개발하는 시간이 5%에서 40%로 증가했으며, 전체 개발 비용도 40% 절감할 수 있었다고 한다. 엣시(Etsy)에서는 문제가 자주 발생하던 스트레스가 높고 비정기적인 배포 절차를 데브옵스 사례를 적용하여 하루에 20~50번 배포하더라도 문제가 드물게 일어났다고 한다.
데브옵스의 움직임에는 문화, 자동화, 측정, 공유라는 네 가지 핵심 가치가 존재한다.
목적은 최대한 소프트웨어 배포 절차를 자동화하는 것이며, 웹페이즈를 일일이 클릭하거나 시스템 명령어를 수동으로 수행하며 인프라를 관리하는 것이 아니라 코드 형태로 관리한다는 뜻이다.
이것이 일반적인 코드형 인프라의 개념이라고 한다.
코드형 인프라란 무엇인가?
코드형 인프라(Infrastructure as Code, IaC)란 코드 형태로 인프라를 작성, 정의, 배포, 업데이트하는 것을 의미한다.
물리 장비를 설정하는 것뿐만 아니라 모든 운영을 코드 형태로 한다는 인식 전환이 중요하다.
실제로 데브옵스는 서버, 데이터베이스, 네트워크, 로그 파일, 애플리케이션 설정, 자동화된 검증 절차, 배포 방법 등 모든 것을 코드 형태로 관리한다.
IaC 도구들은 크게 네 가지 범주로 나뉘며, 하나씩 상세하게 알아보자.
- 애드 혹 스크립트
- 구성 관리 도구
- 서버 템플릿 도구
- 서버 프로비전 도구
애드 혹 스크립트
가장 간단하게 코드 형태로 자동화를 구현할 수 있는 것은 즉각적인 호출과 응답을 할 수 있는 스크립트를 만드는 것이다.
수동으로 작업하는 것을 절차별로 정의한 다음에 스크립트 언어(배시, 루비, 파이썬 등)로 구현하고 대상 장비에서 수행한다.
예를 들면, 다음과 같이 의존성을 확인하여 설치하면 깃(git) 저장소로부터 코드를 내려받으며, 아파치 웹 서버를 시작하는 setup-webserver.sh라는 배시(Bash) 스크립트를 볼 수 있다.
# Update the apt-get cache
sudo apt-get update
# Install PHP
sudo apt-get install -y php
# Install Apache
sudo apt-get install -y apache2
# Copy the code from the repository
sudo git clone https://github.com/brikis98/php-app.git/var/www/html/app
# Start Apache
sudo service apache2 start애드 혹 스크립트는 대중적인 프로그래밍 언어를 사용하여 원하는 어떤 것이라도 개발할 수 있지만, 모든 것을 직접 개발해야 한다.
코드형 인프라를 위해 개발된 도구들은 일반적으로 복잡한 작업을 수행하는 데 간결한 API를 제공하지만, IaC 도구가 아닌 일반적인 프로그래밍 언어를 사용한다면 모든 작업에 대해 직접 코드를 작성해야 한다.
또한, IaC는 일반적인 코드와 같이 자유로운 형태로 작성하는 것이 아닌 특정 코드 구조와 문법 형태에 따라서 작성하도록 만들어졌다.
웹 서버 한두 대를 배포하는 것에 대해서는 일반 코드 형태도 큰 문제는 아니지만, 수많은 서버와 데이터베이스, 부하 분산 장치, 네트워크 설정을 관리하기 위해서는 혼란스러울 수밖에 없다. 만약 누군가의 애드 혹 스크립트를 운영해 본 적이 있다면 스크립트를 이해하기도 쉽지 않으며, 거의 항상 유지 보수가 불가능한 스파게티 코드가 되었던 경험이 있을 것이다.
결론적으로 애드 혹 스크립트는 규모가 작거나 단발성 작업에 적합하며, 모든 장비를 코드 형태로 관리할 계획이 있다면, 대규모 인프라 관리 목적에 의해 개발된 IaC 도구를 통해 관리해야 한다.
구성 관리 도구
셰프(Chef), 퍼핏(Puppet), 앤서블(Ansible), 솔트스택(Saltstack)은 구성 관리 도구에 속하며, 서버에 소프트웨어를 설치하거나 관리하는 목적으로 사용한다.
예를 들어, 이전에 본 아파치 웹 서버를 설치하는 배시 스크립트와 동일한 작업을 하는 앤서블 롤(Role)은 다음과 같다.
*셰프(CHEF), 퍼펫(Puppet), 솔트스택(Saltstack) 요약본
- name: Update the apt-get cache
apt:
update_cache: yes
- name: Install PHP
apt:
name: php
- name: Install Apache
apt:
name: apache2
- name: Copy the code from the repository
git: repo=https://github.com/brikis98/php-app.git dest=/var/www/html/app
- name: Start Apache
service: name=apache2 state=started enabled=yes구성 관리 도구의 코드는 배시 스크립트와 비슷하나 더 많은 장점을 제공한다.
코딩 규칙
앤서블은 문서화, 파일 배열 구성, 명확히 정의된 변수, 암호화 관리를 포함하여 일관성 있고 예측 가능한 구조로 개발하도록 구성되어 있다.
모든 개발자와 운영자가 각각 애드 혹 스크립트의 관리 방법이 달랐다면 코드 작성 규칙을 통해 더욱더 쉽게 읽고 관리할 수 있다.
멱등성
애드 혹 스크립트를 개발하는 작업 자체는 어렵지 않다.
하지만 단발성 스크립트가 아니라 지속해서 수행해야 한다면 폴더가 이미 생성되어 있는지, 설정 값에 특정 변수가 이미 선언되어 있는지 애플리케이션이 이미 실행 중인 모든 상황을 고려해서 개발하고 수행해야 한다.
멱등성은 같은 코드라면 수행 횟수에 상관없이 결괏값은 항상 같아야 한다는 의미이다.
배시 스크립트에서 멱등성을 구현한다고 하면 앞에서 설명한 많은 고려사항을 조건문으로 처리해야 한다.
앞의 앤서블 롤에 따른 동작 방식을 예로 들면, 아파치가 설치되어 있지 않을 때만 아파치의 설치를 진행하고, 웹 서버가 동작하고 있지 않을 때는 아파치를 실행시키는 방식이다.
결론적으로 몇 번을 수행하더라도 항상 같은 형상과 멱등성이 유지된다.
분산형 구조
애드 혹 스크립트는 소규모, 단발성에 적합하며, 앤서블을 포함한 다른 구성 관리 도구들은 대규모 분산 환경을 관리할 수 있도록 설계되어 있다.
예를 들어, 간단하게 다음의 IP를 갖는 5대의 서버를 앤서블을 통해 같은 설정의 웹 서버로 구성할 수 있다.
[webservers]
11.11.11.11
11.11.11.12
11.11.11.13
11.11.11.14
11.11.11.15그리고 다음과 같인 앤서블 플레이북(playbook)을 정의하면 된다.
- hosts: webservers
roles:
- webserver마지막으로 다음과 같이 수행한다고 한다.
ansible-playbook playbook.yml이렇게 앤서블을 수행하게 되면 5대의 서버에 병렬로 수행되며, 무중단 서비스를 위해 롤링(rolling) 배포로 순차적으로 적용하고자 할 때 serial이라는 변수를 플레이북에 정의하면 된다.
예를 들어, serial 값을 2로 설정한다면 앤서블은 한 번에 서버 2대에 작업을 수행한다는 의미다.
애드 혹 스크립트에서 이러한 작업을 수행한다고 하면 수십, 수백 줄의 추가 코드가 들어가야 한다.
서버 템플릿 도구
구성 관리 도구의 대안으로 말할 수 있는 것은 도커(Docker), 패커(Packer), 베이그란트(Vagrant) 등의 서버 템플릿 도구다.
많은 서버를 배포하고 같은 코드를 서버마다 같은 설정으로 동일하게 수행하는 것이 아니라 소프트웨어와 수행 시에 필요한 설정과 의존성 있는 프로그램들을 포함한 특정 시점에 운영 체제와 함께 스냅샷(Snapshot)하여 템플릿 이미지화하는 것이다.
특정 IaC 도구를 통해 서버에 템플릿 이미지를 배포하고 서비스를 구성할 수 있다.
이미지에 대해서는 다음과 같이 크게 두 분류로 나눌 수 있다.
가상머신
가상 머신(Virtual Machine, VM)을 통해서 하드웨어 레벨의 연관 관계를 포함한 시스템의 정보를 이미지화할 수 있다.
VM웨어(VMware), 버추얼박스(VirtualBox) 또는 패러랠스(Parallels) 같은 하이퍼바이저(Hypervisor)를 통해 CPU, 메모리, 물리 디스크와 네트워크를 가상화할 수 있다.
가상 머신 이미지의 장점은 하이퍼바이저가 구성된 환경이라면 개발, 준비, 상용 환경의 어느 곳에서라도 동일하게 배포, 수행할 수 있을 뿐만 아니라 가상 머신을 다른 리소스와 독립적으로 분리하여 운영할 수 있다.
하지만 단점으로 하드웨어 위의 가상화 계층에서 서로 격리된 공간을 할당해야 하므로 CPU와 메모리의 오버헤드를 일으킬 수밖에 없고 가상 머신이 준비되고 배포할 때 걸리는 시간의 부담이 있다.
컨테이너
컨테이너(Container)는 운영 체제의 사용자 영역만 에뮬레이트(emulate)한다.
도커나 코어OS(CoreOS)가 제공하는 rkt를 사용한다면 독립된 프로세스, 메모리, 네트워크와 마운트 정보들을 묶음으로 만들 수 있다고 한다.
컨테이너의 장점은 어느 환경이든 컨테이너 엔진만 있다면 별도의 사용자 공간을 가질 수 있다.
어느 곳이든 같은 형태대로 서비스를 유지할 수 있으며, 가상 머신과 같이 운영 체제 영역을 함께 가상화하는 것이 아니므로 오버헤드도 적고 가볍다.
하지만 운영 체제 커널과 물리적인 영역을 함께 공유해야 하므로 보안상 더 취약할 수밖에 없다고 한다.
다음은 실제로 패커로 웹 서버용 아마존 머신 이미지(AMI, Amazon Machine Image)를 제작하는 web-server.json 설정 파일이다.
{
"builders": [{
"ami_name": "packer-example",
"instance_type": "t2.micro",
"region": "us-east-1",
"type": "amazon-ebs",
"source_ami": "ami-40d28157",
"ssh_username": "ubuntu"
}],
"provisioners" [{
"type": "shell",
"inline": [
"sudo apt-get update",
"sudo apt-get install -y php",
"sudo apt-get install -y apache2",
"sudo git clone https://github.com/brikis98/php-app.git /var/www/html/app"
]
}]
}패커를 통해 앞에서 언급한 setup-webserver.sh와 같은 역할을 하는 템플릿 설정이다.
한 가지 다른 점이 있다면 패커 설정에서는 아파치 서버를 시작하지 않는다.
일반적으로 서버 템플릿으로 이미지화한다는 것은 소프트웨어 설치까지의 단계를 담당함을 의미한다.
또한, 소프트웨어의 실행은 이미지를 통해 서버를 시작하는 단계에서 수행하도록 설정함을 의미한다.
packer build web-server.json 명령어로 AMI를 생성할 수 있으며, 생성 작업이 완료되면 해당 AMI를 통해 아마존 웹 서비스 서버 여러 대를 동시에 생성할 수 있다.
또한, 각 서버가 시작될 때 아파치가 실행되도록 설정할 수 있다고 한다.
다양한 서버 템플릿 도구마다 각각 다른 목적을 가진다.
패커는 아마존 웹 서비스에서 AMI를 통해 상용 환경 서버를 구성할 때 사용되는 가장 대중적인 서버 템플릿 도구라고 한다.
베이그란트는 개발 환경을 구성한 PC에서 버추얼박스를 통해 이미지를 만들기에 적합한 도구라고 한다.
도커는 독립적인 애플리케이션에 대한 이미지를 생성할 때 적합하다고 한다.
도커 이미지는 도커 엔진만 구성되어 있다면 상용 환경과 개발 환경에 함께 사용할 수 있으며, 앞서 언급된 도구를 통하여 도커 엔진을 구성할 수 있다고 한다.
도커로 애플리케이션을 배포하는 단계로 예를 들면, 패커를 통해 도커 엔진을 설치한 AMI를 구성 및 배포한 다음 각 애플리케이션의 컨테이너를 함께 배포하여 컨테이너 클러스터 구성을 쉽게 할 수 있다.
서버 템플릿은 변하지 않는 인프라(Immutable Infrastructure)의 주요한 기능이며, 이것은 함수형 프로그램처럼 가변적인 변수를 제거하여 항상 값을 불변으로 유지한다고 한다. 무엇을 수정하려고 할 때 새로운 값으로 정의해야 하며, 이렇게 정의된 값은 절대 변하지 않기 때문에 개발할 때 다양한 장점이 존재한다고 한다. 변하지 않는 인프라 역시 비슷한 개념이며, 서버를 한번 배포하면 해당 서버는 절대 변하지 않는 설정을 가진다.
만약에 새로운 버전의 소프트웨어 업데이트가 필요하다면 새로운 서버를 위한 새로운 이미지를 작성해야 한다.
이미 배포된 서버의 설정은 절대 변경되지 않으므로 배포된 내용을 알아내는 작업은 매우 간단해진다고 한다.
내가 생각한 예 ex) docker image에 Hello World:1.0, Hello World:1.1, 1.2 등등?
서버 프로비전 도구
구성 설정 도구와 서버 템플릿 도구가 각 서버에 코드를 정의하기 위해 사용되었다면, 테라폼, 클라우드포메이션(CloudFormation), 오픈스택 히트(Opstack Heat)는 서버 자체를 구성하기 위한 도구다.
아래와 같이 서버뿐만 아니라 데이터베이스, 캐시, 네트워크 장비, 서브넷 설정, 라우팅 정책, SSL 인증서, 방화벽 등 서비스를 이루고 있는 다양한 리소스를 생성하고 관리할 수 있다.
예를 들면, 다음과 같은 테라폼 코드를 통해서 웹 서버를 구성할 수 있다고 한다.
resource "aws_instance" "app" {
instance_type = "t2.micro"
avilability_zone = "us-east-1a"
ami = "ami-40d28157"
user_data = <<-EOF
#! /bin/bash
sudo service apache2 start
EOF
}여기서는 두 가지 매개 변수만 이해하자.
AMI
ID 형태로 구성되어 있으며, 서버에 배포할 때 기본이 되는 이미지 정보다.
이 AMI ID는 패커를 통해서 PHP, 아파치와 애플리케이션 코드를 구성한 web-server.json으로 만들어지는 값이라고 한다.
user_data
배시 스크립트로 작성되어 있으며, 웹 서버가 부트 할 때 아파치와 함께 시작하도록 설정할 수 있다.
결론적으로 이 코드와 같이 서버 프로비전 도구와 서버 템플릿 도구를 함께 사용해서 변하지 않는 인프라를 구성할 수 있다고 한다.
코드형 인프라의 장점
2016년도에 발표된 데브옵스 리포트에 따르면 조직에서 코드형 인프라와 같은 데브옵스를 적용하였을 때 배포 주기는 200배 이상 빨라졌고, 장애 복구 시간은 24배 빨라졌다고 하며, 개발에서 상용 서비스 적용을 위해 거쳐야 하는 프로세스가 2천 배 이상으로 줄어들었다고 한다.
이렇게 인프라를 코드로 관리할 때, 다양한 소프트웨어 엔지니어링 방법들을 모색할 수 있다고 한다.
아래와 같은 방법으로 소프트웨어 전달 효율성을 높일 수 있다고 한다.
셀프 서비스
조직 대부분은 코드를 수동으로 배포하고 소프트웨어 배포와 상용 환경에서 실제 작업을 수행하는 서비스 운영 담당자는 적은 인원(주로 단 한 명)이라고 한다.
이러한 구조가 회사가 성장할 때 가장 큰 병목 현상이 된다고 한다.
만일 코드 형태로 관리하고 배포 절차를 자동화하면 개발자가 원하는 시점에 배포할 수 있다고 한다.
속도와 안정성
만일 배포 절차가 자동화된다면, 운영자가 수동으로 배포하지 않고 컴퓨팅 리소스가 신속하게 배포하므로 속도와 안정성이 눈에 띄게 향상될 것이다.
자동화된 프로세스는 더욱 일관성 있게 반복할 수 있으며, 수동 오류를 줄일 수 있다고 한다.
문서화
인프라의 상태 정보가 시스템 관리자의 머릿속에만 저장된 것이 아닌 누구나 읽을 수 있고 볼 수 있다면, 코드형 인프라 자체가 문서로 만들어진 형태라 할 수 있다.
시스템 관리자가 휴가를 가더라도 모든 사람과 조직이 어떻게 동작하는지 알 수 있다고 한다.
버전 관리
코드형 인프라 파일 역시 버전 관리를 할 수 있다.
인프라의 변경 사항과 커밋 로그 등을 남길 수 있다는 의미다.
변경 사항에 이력을 남길 수 있다는 것은 추후 문제가 발생하였을 때 어떤 부분이 변경 혹은 적용되었는지 알 수 있고, 이전 정보로 되돌려 문제 현상을 빠르게 복구할 수 있다는 것이다.
확인 및 검사
인프라 상태를 코드 형태로 관리하여 변경되는 모든 것을 코드로 남긴다면 인프라의 변경 사항 역시 코드 리뷰를 할 수 있으며, 자동화된 형태로 유효성 검사를 할 수 있다.
또한, 분석 도구를 통해 코드의 적용 가능 유무를 확인할 수 있다.
이러한 자동화된 확인 및 검사 단계를 통해서 결함 가능성을 크게 낮출 수 있다.
재사용성
인프라를 코드화하여 모듈화 할 수 있다면 모든 배포 단계와 환경에서 처음부터 시작할 필요 없이 공통된 사항들을 재사용할 수 있다.
검증된 것, 문서로 만들어진 것을 활용하여 서비스에 맞게 구성할 수 있다고 한다.
운영 관리의 편안함과 행복
다른 부분도 중요하지만, 운영의 효율화와 편안함이 코드형 인프라 도입에서 가장 중요하다.
코드를 배포하고 인프라를 수동으로 관리하는 것은 매우 반복적이고 지루한 일이다.
개발자와 운영자는 반복적인 업무가 수행될수록 독창적이며 새로운 것에 대한 도전과 변화가 없으므로 발전하기 어렵다.
언젠가 사고가 발생하기 전까지는 아무도 배포 단계와 작업 절차를 신경 쓰지 않을 것이다.
하지만 이것은 건강하지 못한 환경이며, 문제가 발생했을 때 되돌리기 매우 어렵다.
코드형 인프라는 자동으로 최대한 단순 반복 작업을 하도록 지원하며, 운영자와 개발자가 가장 가치 있는 일(기능 개발, 개선 작업)에 집중할 수 있도록 한다고 한다.
이런 장점들로부터 코드형 인프라가 왜 중요한지 파악했다.
다음으로는 왜 테라폼이 코드형 인프라를 이루는데 적합한 도구이며, 왜 필요한지 설명한다고 한다.
테라폼의 동작 방식
테라폼이 어떻게 동작하는지 높은 수준의 단순화된 보기를 통해 알아보자.
테라폼은 Go로 프로그래밍되어 있는 오픈 소스 도구다.
Go 코드는 하나의 바이너리로 컴파일되어 있고, terraform이라는 명령어로 수행할 수 있다.
이 바이너리 파일은 빌드 서버뿐만 아니라 데스크톱, 노트북 등 어느 환경에서도 사용할 수 있으며, 다른 추가 리소스는 필요하지 않다.
테라폼 바이너리를 통해 코드에 정의된 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드, 오픈스택과 같은 공급자가 제공한 API를 통해 호출을 만든다고 한다.
이 뜻은 테라폼이 공급자가 제공하는 API 서버 리소스를 활용함을 의미하며, 추가 인프라에 대해서는 고민할 필요가 없다고 한다.
어떻게 테라폼이 API 호출을 만드는 것인지는 다음의 예처럼 테라폼 설정 값을 통해서 확인할 수 있다고 한다.
이 설정 파일이 만들고자 하는 인프라에 대한 정보를 포함한 문서이며, 코드형 인프라를 만들어 주는 방법이라고 한다.
resource "aws_instance" "example" {
ami = "ami-40d28157"
instance_type = "t2.micro"
}
resource "dnsimple_record" "example" {
domain = "example.com"
name = "test"
value = "${aws_instance.example.public_ip}"
type = "A"
}테라폼 코드에 대한 경험이 없더라도 위의 코드를 읽고 이해하는 데는 어렵지 않을 것이다.
이 짧은 코드는 테라폼을 통해 아마존 웹 서비스에 API 호출을 하여 서버를 배포한 다음, DNSimple API를 통해 해당 서버 IP를 example.com 도메인의 DNS A 레코드로 추가한다.
문법이 쉽고 간단한 테라폼 코드를 사용하여, 여러 클라우드 공급자 간에 상호 연결된 리소스를 배포할 수 있다.
서버, 데이터베이스, 네트워크 장비와 형상(topology)을 포함한 모든 인프라를 코드 형태로 관리할 수 있으며, 설정 정보에 대한 파일을 버전 관리할 수 있다.
또한, 테라폼 명령어를 수행하여 인프라를 배포할 수 있다.
테라폼 바이너리는 클라우드 공급자 API에 맞도록 코드를 변환해서 수행하며, 사용자를 대신하여 최대한 효과적으로 API 호출이 이루어지도록 한다.
팀 구성원이 인프라 변경이 필요하다고 하면, 수동으로 리소스를 변경하는 것이 아니라 테라폼 설정을 변경하고 코드 리뷰를 통해서 변경 관리를 한다.
확인 후 문제가 없으면 버전 관리 시스템을 통해 코드를 업데이트한다.
그 후 terraform apply 명령을 통해 테라폼이 변경된 사항에 맞춰서 API를 변환, 수행할 수 있도록 한다.
테라폼이 다른 코드형 인프라 도구와 다른 점은 무엇인가?
주요 비교 사항
- 구성 관리 vs 배포 도구
- 가변적인 인프라 vs 변하지 않는 인프라
- 절차적 언어 vs 선언형 언어
- 마스터 유무
- 에이전트 유무
- 커뮤니티 규모
- 성숙한 기술 vs 신규 기술
구성관리 vs 배포 도구
셰프, 퍼핏, 앤서블, 솔트스택은 구성 관리 도구이며, 테라폼, 클라우드포메이션, 오픈스택 히트는 배포 도구다.
구성 관리 도구 역시 기본적인 리소스 프로비전을 제공하므로 경계선을 정확하게 나누기는 어렵다(예로 앤서블로 서버를 배포할 수도 있다).
그리고 프로비전 도구 역시 서버 생성 시에 설정 및 초기화 스크립트를 통해서 구성 관리 정보를 수집, 설정할 수 있다.
이런 다양한 도구들의 목적이 비슷한 만큼 서비스 사용 사례에 가장 적합한 도구를 선택해야 된다고 한다.
특히, 도커와 패커와 같은 서버 템플릿 도구를 사용하고 있다면 이미 구성 관리가 적용된 형태라 볼 수 있다.
도커파일(Dockerfile) 혹은 패커 템플릿 이미지를 이미 가지고 있다면, 그 이미지를 동작시키기 위한 인프라가 필요하다.
이와 같은 상황에서는 서버 프로비전 도구가 가장 효과적인 선택이며, 서버 템플릿 도구를 사용하지 않는다면 설정 관리 도구와 프로비전 도구를 함께 사용하는 것이 최적의 선택이라고 한다.
예를 들어, 테라폼으로 인프라 소스를 배포하고 셰프로 설정 관리를 수행하여 소프트웨어를 설치한다.
- (내 생각) 뭔가 당연한 말을 하고 있는 듯한 느낌이 든다.
알아야 되는 말을 하는 것이 아닌...? 모르겠당🙄
가변적인 인프라 vs 변하지 않는 인프라
셰프, 퍼핏, 앤서블, 솔트스택 등의 구성 관리 도구는 가변적인 인프라 패러다임을 기본 원칙으로 한다.
예를 들어, 셰프를 통해서 OpenSSL의 새로운 버전을 설치한다고 하였을 때, 셰프는 기존 서버에 소프트웨어를 업데이트하고 모든 변경사항을 해당 서버에서 적용한다.
그 이후로 더 많은 업데이트를 수행할수록 서버는 각각 독립적인 변경 이력을 가진다.
결과적으로, 각 서버는 다른 서버들과 달라지고 진단 및 복구가 어려운 구성 결함이 발생한다.
수동으로 발생하였을 때 벌어지는 이러한 문제 상황은 구성 관리 도구를 통해 자동화를 사용하면서 극복할 수 있지만, 구성 관리 도구 역시 이러한 문제점을 100% 해결할 수는 없다.
자동화된 테스트 방안이 있더라도 서버가 미묘하게 구성이 변경된 사항은 파악하기 어려우며, 테스트 환경과 상용 환경이 정확히 같지 않으므로 상용 환경 서버에서는 다른 문제가 발생할 수 있다.
물론 구성 관리 도구로도 변경 사항을 변하지 않는 형태로 구성할 수도 있으나 이것은 그 도구의 목적에 부합하지 않는다.
불변의 접근 방법 역시 자체적인 단점이 존재한다.
예를 들어, 서버 템플릿을 통해 새로 이미지를 만들고 이전 서버의 모든 변경 사항을 다시 다 적용하는 데 시간이 오래 걸릴 수밖에 없다.
- (내 생각) 결국 어떤 상황에서 이런 도구가 유용할지도 모른다 이런 내용도 없다.
약간 이런 상황이 있고 저런 상황이 있을 수도 있지만 그러하다. 이런 느낌의 글이라고 해야 되나...?
절차적 언어 vs 선언형 언어
셰프와 앤서블은 원하는 최종 상태를 만들기 위해서는 매 단계별로 코드를 작성하는 것과 같은 절차적인 스타일을 권장한다.
하지만 테라폼, 클라우드포메이션, 솔트스택, 퍼핏, 오픈스택 히트는 코드를 선언형으로 작성하도록 권장하며, 최종으로 원하는 형태만 선언하면 되고, IaC 도구가 해당 형태를 만들기 위한 상태를 관리하는 역할을 한다.
다음 예제를 통해 다른 점을 알아보자.
다음은 절차적 접근을 하는 앤서블을 통해 AMI ID가 ami-40d28157인 우분투 이미지로 10대 서버를 배포하는 예제이다.
- ec2:
count: 10
image: ami-40d28157
instance_type: t2.micro그리고 동일한 기능을 하는 선언형 방식의 테라폼 설정이다.
resource "aws_instance" "example" {
count = 10
ami = "ami-40d28157"
instance_type = "t2.micro"
}앤서블 혹은 테라폼을 통해 초기 작업을 수행할 때는 겉으로는 두 설정이 비슷해 보여 같은 결괏값을 얻을 수 있다.
하지만 변경사항이 생길 때는 두 방식의 차이점을 파악할 수 있다.
예를 들어, 서비스 사용량이 늘어나 서버를 15대로 늘려야 한다면 앤서블의 이전 코드는 더는 유효하지 않다.
만약 그 코드의 서버를 15대로 늘린다고 하면, 15대의 새로운 서버가 생성되며 총 25대의 서버가 생성된다.
그래서 최종 수량이 아닌 추가되는 수량(5대)만큼만 코드에 업데이트해야 한다.
- ec2:
count: 5
image: ami-40d28157
instance_type: t2.micro선언형 코드에서는 원하는 최종 상태의 정보만 정의하면 되고 테라폼이 현재 상태의 정보와 비교하여 최종 상태를 적용한다.
테라폼은 이전의 정보 상태를 알고 있으므로 최종적인 서버 대수만 고려하면 된다.
즉 이전에 사용했던 테라폼 설정 값을 10에서 15로 늘리면 된다.
resource "aws_instance" "example" {
count = 15
ami = "ami-40d28157"
instance_type = t2.micro
}만약 이 설정 정보를 적용하면, 테라폼이 기존에 10대의 서버를 만들었던 것을 기억하므로 5대의 서버만 추가로 생성한다.
실제로 설정이 적용되기 전에 테라폼의 plan 명령어로 변경 사항을 미리 알 수 있다.
> terraform plan
+ aws_instance.example.11
ami: "ami-40d28157"
instance_type: "t2.micro"
+ aws_instance.example.12
ami: "ami-40d28157"
instance_type: "t2.micro"
+ aws_instance.example.13
ami: "ami-40d28157"
instance_type: "t2.micro"
+ aws_instance.example.14
ami: "ami-40d28157"
instance_type: "t2.micro"
+ aws_instance.example.15
ami: "ami-40d28157"
instance_type: "t2.micro"
Plan: 5 to add, 0 to change, 0 to destroy.만약에 새로운 버전의 애플리케이션이 포함된 AMI ID가 ami-408c7f28로 바뀌게 되면 어떤 일이 발생할지 예상되는가?
절차 지향적 접근 방식을 사용하면 이전에 사용했던 앤서블 템플릿은 더는 유효하지 않으므로 이미 배포된 10대의 서버를 추적하고 다시 새로운 버전의 템플릿을 작성해야 한다.
하지만 테라폼의 선언형 접근 방식에서는 이전과 같은 설정 값을 활용하여 ami 변수에 ami-408c7f28만 변경하면 된다.
resource "aws_instance" "example" {
count = 15
ami = "ami-40d28157"
instance_type = "t2.micro"
}예제에서 확인할 수 있듯이 매우 간단하게 사용할 수 있다.
앤서블은 태그를 사용하여 새 EC2 인스턴스를 배포하기 전에 기존의 인스턴스를 확인할 수 있다(예를 들어, instance_tag와 count_tag 변수를 사용하는 것이다).
하지만 모든 리소스에 대해 수동으로 이전 이력들의 기준을 토대로 관리하는 것은 매우 복잡한 일이다(예를 들면, 존재하는 서버에 대해 태그뿐만 아니라 이전 이미지 버전, 가용 영역 등을 모두 파악해야 한다).
이는 절차적 IaC 도구의 두 가지 문제점을 강조한다.
1. 절차적인 코드들은 인프라의 모든 상태를 저장하기 어렵다.
앞의 세 가지 앤서블 템플릿을 보고 읽는 것으로는 배포 내용을 확인하기 힘들다.
따라서, 템플릿이 적용된 순서 정보 역시 알고 있어야 한다.
만약 적용 순서가 다르다면 다른 인프라가 될 가능성이 높다.
이것은 코드 기반 자체에서 확인하기 어려운 일이며, 다른 말로 하면 앤서블 혹은 셰프의 코드와 지금까지 변경된 모든 이력을 함께 알아야 한다.
또한, 절차적인 코드는 재사용이 불가능하며, 코드의 재사용은 본질적으로 현재 인프라 상태를 고려해야 하므로 제한이 된다.
상태가 계속 변경되므로 일주일 전에 사용한 코드들은 이전의 인프라 역시 더는 존재하지 않으므로 다시 사용하기는 어려워진다.
결과적으로 절차 기반 코드는 시간이 지남에 따라 무겁고 복잡해지는 경향이 있다.
2. 테라폼의 선언형 접근방법을 통하여 코드는 항상 최신의 인프라 상태를 나타낸다.
히스토리 및 타이밍을 걱정할 필요 없이 현재 배포된 내용과 구성 내역을 알 수 있다.
이것은 수동으로 현재 상태를 설명할 필요가 없으므로 코드를 재사용하기 쉬워진다.
만들고자 하는 상태를 설명하는 것에 집중하고, 테라폼은 자동으로 한 상태에서 다른 상태로 전환하는 방법을 보여준다.
결과적으로 테라폼의 코드를 간단하고 이해하기 쉽게 구성할 수 있다.
물론 선언적 언어에도 단점은 존재한다고 한다.
전체 프로그램 언어를 이해하지 못하면 표현이 매우 제한된다.
예를 들어, 무중단 배포와 같은 일부 유형의 인프라 변경은 단순히 선언적 용어로 표현하기 어렵다고 한다.
또한, 절차형 언어와 비슷하게 논리적인 구성을 수행할 수 없다(예를 들어, 조건문이나 반복문).
일반적으로 생성해야 하며, 재사용 가능한 코드는 까다로울 수 있다.
또한, 조건문이나 반복문과 같은 논리적인 구성을 수행할 수 없어 나열하는 형태로 코드가 작성되며, 재사용이 까다롭다.
하지만 테라폼은 몇 가지 강력한 기본 구성을 제공한다고 한다.
예를 들어, 변수 입력, 출력, 모듈화, 생성하기 전에 삭제, 숫자 반복, 다양한 구문들, 채움 참조 함수들을 제공한다고 한다.
이것을 통해 더욱더 깔끔하게 설정할 수 있으며, 선언형 언어에서도 모듈식 코드를 구성할 수 있다.
마스터 유무
기본적으로 셰프, 퍼핏, 솔트스택 모두 다 마스터 서버가 필요하며, 인프라의 정보와 배포할 업데이트를 저장하고 있다.
인프라를 변경할 때 명령어, 클라이언트를 통해 머스터에 정보를 갱신하고 마스터 서버는 다른 서버에 업데이트를 전송하거나 각 서버가 마스터로부터 최신의 업데이트를 내려받아서 수행한다.
마스터 서버의 존재는 몇 가지 장점을 제공한다.
첫째는 인프라의 상태를 중앙 한 곳에서 관리하고 확인할 수 있다.
또한, 많은 구성 관리 도구는 웹 인터페이스를 제공하여 작업 진행 내역을 손쉽게 확인할 수 있다.
둘째로 마스터 서버는 백그라운드로 지속해서 실행되고 구성 변경을 감지할 수 있다.
예를 들어, 누군가가 수동으로 서버의 설정 정보를 변경한다면, 마스터에서 승인되지 않은 변경사항에 대해 다시 복구시킬 수 있다.
하지만 마스터의 존재로 인한 단점들도 존재한다.
추가적인 리소스
마스터 시스템을 위해 추가 리소스를 구성해야 하며, 가용성, 확장성을 위해 필요에 따라 클러스터까지 구성해야 한다.
운영
마스터 서버 자체도 중요한 시스템이므로 관리, 운영, 업그레이드, 백업, 모니터링도 수행해야 한다.
보안
마스터 서버와 모든 클라이언트 간에 통신할 수 있도록 네트워크 연결을 열어 놓아야 하며, 연결을 위한 특정 포트나 권한을 고려해야 한다.
모든 서버와 연동되는 단일 통신 채널에 대한 보안도 강화해야 한다.
- (내 생각) 마스터 서버가 내 주 서버라고 생각하면 "모든 클라이언트"라는 말은 일꾼이라고 할 수 있는 것인가?
이 모든 클라이언트가 마스터 서버의 정보를 받고 자신의 서버를 마스터 서버와 동일하게 설정을 바꾸게 된다?
클라이언트 서버가 결국 에이전트 서버와 같은 것인가?
셰프, 퍼핏, 솔트스택은 각 서버에서 에이전트 소프트웨어만 마스터 없이 수행하는 형태도 지원한다.
통상적으로 특정 주기로 스케줄러 혹은 리눅스 크론잡(cronjob)을 걸어서 마스터 서버가 아닌 버전 관리 서버에서 최신의 정보를 받아와 수행할 수도 있다.
이렇게 설정 단계를 최소화할 수 있지만, 다음 절에서 설명할 서버를 배포하고 에이전트 소프트웨어를 설치하는 방법과 관련해 여러 가지 해결되지 않은 질문이 남아 있다.
앤서블, 클라우드포메이션, 히트, 테라폼은 전부 다 마스터 없이 수행하는 것을 기본적으로 한다.
또는, 정확성을 위해 마스터 서버를 사용한다.
하지만 이것은 이미 사용하고 있는 리소스의 일부이고, 관리를 위해 추가할 필요는 없다.
예를 들어, 테라폼은 클라우드 공급자 API를 통해 통신하므로 API 서버가 마스터 서버가 되고 추가적인 인증 메커니즘이 필요하더라도 별도의 마스터 서버는 필요하지 않고 받은 API 키를 사용하면 된다.
앤서블은 SSH를 통해 직접 서버와 통신한다.
이것 역시 별도의 인증을 위한 인프라는 추가되지 않는다(SSH 키를 사용).
에이전트 유무
셰프, 퍼핏, 솔트스택 모두 다 설정을 하고자 하는 각 서버에 에이전트 소프트웨어가 필요하다(Chef Client, Puppet Agent, Salt Minion).
각 에이전트는 일반적으로 각 서버 백그라운드로 수행되며, 최신의 설정 관리 업데이트를 담당한다고 한다.
하지만 몇 가지 단점이 있다고 한다.
부트스트랩핑
서버를 프로비전하고 어떻게 소프트웨어를 설치하는가?
일부 구성 관리 도구는 일부 외부 프로세스가 처리할 것으로 가정하여 진행한다(예를 들어, 아마존 머신 이미지(AMI)를 통해 수십 대의 서버를 배포할 때 에이전트가 미리 깔려 있을 것으로 가정한다).
다른 구성 관리 도구는 특별한 부트스트랩핑 프로세스를 제공하며, 일회용 명령을 실행하여 클라우드 공급자 API를 사용하여 서버를 프로비전하고 SSH를 통해 해당 서버에 에이전트 소프트웨어를 설치한다.
유지 관리
에이전트 소프트웨어는 주의 깊게 정기적으로 업데이트해야 하며, 마스터 서버와 동기화를 신중하게 유지해야 한다.
에이전트 소프트웨어가 재시작되거나 문제가 발생했을 때 모니터링할 수 있어야 한다.
보안
에이전트 소프트웨어는 마스터 서버로부터 설정을 내려받아야 하며, 모든 서버가 외부와 통신할 수 있도록 열어 두어야 한다.
만약 마스터 서버가 에이전트로 설정 값을 전달한다는 방식이라면 모든 서버에서 마스터 서버로부터의 접근을 허용하도록 포트를 열어주어야 한다.
두 방식 다 에이전트와 서버 간 통신을 위해 인증을 어떻게 받아야 할지 고려해야 한다.
이 모든 것이 외부 공격자의 공격 대상이 될 수 있다고 한다.
앞에서 언급한 대로 셰프, 퍼핏, 솔트스택은 비 에이전트 방식에 다양한 지원을 하고 있다고 한다.
하지만 이것은 구성 관리 도구의 전체 기능 세트를 지원하지 않은 것처럼 느껴진다고 한다.
실제로는 아래와 같이 셰프, 퍼핏, 솔트스택의 기본적인 구성 방안은 마스터와 에이전트를 설치하는 것을 권한다고 한다.
에이전트 방식에 대해 추가되는 리소스도 오류 관리가 필요하다고 한다.
새벽 3시에 장애를 처리한다고 가정하면, 애플리케이션 코드, IaC 코드 혹은 구성 관리 도구의 클라이언트와 서버에서 결함 혹은 연동 관계의 오류 사항을 발견해야 하고, 기존에 존재하지 않았던 다양한 이슈를 확인해야 한다고 한다.
앤서블, 클라우드포메이션, 히트와 테라폼은 추가적인 에이전트가 필요하지 않다고 한다.
더욱 정교한 설치나 진단을 하기 위해서는 에이전트 설치가 필요하지만, 통상적으로는 사용하는 인프라에 이미 구성되어 있다고 한다.
예를 들어, 아마존 웹 서비스, 애저, 구글 클라우드 혹은 다른 클라우드 공급자에서 설치, 관리하고 인증 에이전트 소프트웨어를 연동하는 역할을 직접 담당한다고 한다.
실제로 아래 그림과 같이 테라폼의 사용자들은 어떻게 클라우드 공급자에 API를 전달하고 수행하는지 신경 쓸 필요가 없으며, 앤서블에서는 SSH 데몬만 구동되어 있으면 어떤 서버라도 접속할 수 있다고 한다.
커뮤니티 규모
최신 기술을 선택한다면 커뮤니티의 규모도 중요하다.
많은 경우 프로젝트의 생태계가 기술 자체의 고유한 품질보다 더 큰 경험을 할 수 있도록 해 준다.
커뮤니티는 얼마나 많은 사람이 프로젝트에 기여하며, 얼마나 많은 플러그인을 제공하고, 연동하고, 확장 기술을 지원할 것인지를 결정한다고 한다.
이를 통해 다양한 도움을 받을 수 있고, 요청(블로그, 스택오버플로 등)할 수 있으며, 회사 프로젝트에 기여할 인력(컨설턴트, 지원 가능한 외부 단체)도 찾을 수 있다고 한다.
커뮤니티를 비교하는 것 자체는 매우 어려운 일이지만, 검색 페이지를 통해서 트렌드를 파악할 수 있다고 한다.
실질적으로 위에 표를 통해서 도구들을 단일 비교하기는 어렵다고 한다.
예를 들어, 도구는 보통 하나 이상의 저장소를 갖고 있으며, 이 중의 일부는 오류 해결 혹은 질문을 위해 다른 방법을 사용한다고 한다.
또한, 셰프, 퍼핏, 등의 일반 명사는 정확하게 IaC 도구와 관련된 직업의 숫자라고 하기도 어렵다고 한다.
성숙한 기술 vs 신규 기술
또 다른 비교 지표는 기술의 성숙도라고 말할 수 있다.
다시 말하자면, 이것 역시 단일 비교는 할 수 없다.
도구마다 다른 버전 관리를 하고 있으나, 추세를 파악할 수는 있다.
테라폼은 비교적 최근에 나온 새로운 IaC 도구이며, 아직 1.0.0 버전 전이다.
이것은 안정성, API의 호환성을 완벽하게 보장하지는 않으며, 코드가 아직 안정화되지 않았음을 의미한다고 한다.
테라폼의 가장 큰 단점은 비교적 짧은 시간에 성장한 도구라고 한다.
이는 새로운 도구를 사용하는 것에 대한 대가는 다른 IaC 도구들처럼 아직 성숙하지 않다는 것이라고 한다.
결론
위에 사진에서 모든 것을 하나로 표현한 것을 보여준다고 한다.
위에 표는 다양한 IaC 도구가 사용되는 기본 또는 가장 일반적인 방법을 보여주지만, 이 장의 앞부분에서 설명한 바와 같이 이러한 IaC 도구는 다른 구성에서도 사용할 수 있을 만큼 유연하다고 한다(예를 들어, 셰프는 마스터 없이 사용할 수 있으며, 솔트스택을 변하지 않는 인프라의 도구로 사용할 수 있다).
그런트웍스(https://www.gruntwork.io/)에서는 오픈 소스와 선언형 언어, 비 마스터와 에이전트가 없는 구조, 변하지 않는 인프라 형태의 특정 클라우드에 구속받지 않는 프로비전 도구, 그리고 큰 커뮤니티와 성숙도 있는 코드가 주요한 기준이었다.
테라폼은 완벽하지는 않지만, 그런트웍스의 요구사항 기준에 가장 적합한 도구였다고 한다.
다음 블로그에서는 테라폼을 사용하는 방법을 알아보도록 하자.
드디어 실습인 듯!
🤔 블로그 정리 후, 느낀 점
뭔가 이해가 가지 않는 부분들도 꽤(?) 있었다.
당연한 말을 하는 부분들도 있었던 것 같고, 어떠한 상황일 때 이 도구를 사용하는 것이 유용하다 혹은 쓰는 것이 좋아보인다라는 말도 거의 없었던 것 같아서 쉽지 않았다.
그리고 위 책에 나오는 도구들을 사용해보지 않아서 이해가 더 어려웠던 것 같다.
나중에 천천히 실습을 하고 다른 도구들도 사용 혹은 공부를 하다보면 "아 그땐 그랬구나, 어? 이거 어디서 많이 들어본 말인데?" 하면서 기억을 회상할 수도 있을 것 같다ㅋㅋ🤮
중요한 것 같은 부분은 Bold 처리했다!
나중에라도 천천히 한번은 보면 좋을 듯!
📝 이번 게시물을 만들기 위해 참고한 사이트
1. 다른 사람의 블로그_1
2. 다른 사람의 블로그_2
3. 다른 사람의 블로그_3
'DevOps > Terraform' 카테고리의 다른 글
| Terraform Up & Running (3-2) - 테라폼 시작하기(웹 서버 클러스터 구성하기, 로드 밸런서 배포하기) (0) | 2023.07.19 |
|---|---|
| Terraform Up & Running (3-1) - 테라폼 시작하기(단일 웹 서버 배포하기, 설정 가능한 웹 서버 배포하기) (0) | 2023.07.12 |
| Terraform Up & Running (3) - 테라폼 시작하기 (0) | 2023.07.07 |
| Terraform Up & Running (1) (0) | 2023.06.26 |
