Terraform Studay 01

이 글은 테라폼 설치에서 운영까지를 읽고 정리한 글이다.

What is Devops?

devops에 대해서는 회사마다, 또는 개발자마다 생각하는 의미가 다르다.  
이 책에서는 소프트웨어를 전달하기 위한 절차와 방법을 효율적으로 만드는 것이라고 개념을 정의한다.  

나의 경험과 그에 근거한 생각에서 기존의 소프트웨어를 만드는 개발자들은 CI/CD 구성까지 역할을 하였다.
개발자가 만든 코드를 빌드하여 이를 이미 구성되어있는 서버로 배포하고 유지하는 역할이다.
위에서 언급한 이미 구성된 서버(피지컬 서버일수도 vm 일수도, 아니면 container일 수도 있다.)는 이전까지는 개발자와는 분절된 영역에 속한 부분이었다.
코드를 배포할 서버의 대수를 조절(scale-out)하거나 성능을 높이는(scale-up) 등은 인프라를 전담하는 조직에 요청하여 처리하는 것이 이전까지의 방법이었고 나름의 규칙이었다.

이제는 이전에 인프라팀에서 전담했던 위의 부분을 개발자가 스스로 할 수 있는 허들이 낮춰졌고 이를 개발자가 담당하며 해당 관리 기록이나 설정을 코드로 관리하는 것까지를 포함하여 devops라고 생각한다.
즉 내 관점에서의 devops란 책에 나온 용어처럼 Infra as Code, 즉 (sh가 아닌)코드로 인프라를 관리하는 것을 의미한다.
물론 실제 피지컬 서버의 랙을 구성한다거나 망을 관리하는 등은 여전히 전통적인 인프라 전담팀의 역할이라고 생각하며 이 부분에 대해서는 넘어갈 예정이다.

Ad-hoc script

전통적인 쉘스크립트 방식의 infra관리이다.
각 운영체제 마다 패키지 관리자의 커맨드를 미리 하나의 쉘스크립트에 작성해두어 서버를 띄울때마다 이를 실행시켜 공통화된 서버 환경을 갖게끔 해준다.

예제 스크립트

# install packages
apt-get install gcc g++ imagemagick

# set swap 2G
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

이 방식에서 가장 큰 문제는 OS마다의 서로 다른 커맨드, 패키지 매니저 이용 방식이다.
예를 들어 Ubuntu 계열에서는 apt-get을 이용하여 패키지를 관리한다.
하지만 Redhat 계열에서는 yum을 이용하여 패키지를 관리한다.
이럴 경우 OS마다 서로 다른 스크립트를 작성해야 하는 불편함이 생긴다.

구성 관리 도구

여기서는 Ansible, Chef 등의 도구를 구성 관리도구 라고 말한다.
위의 Ad-hoc과 같은 일을 한다고 본다. 다만 이러한 도구들 (Ansible을 써본 경험에서 보면)은 OS에 종속되지 않게 코드를 구성하게 해준다거나
멱등성(이미 설치된 것은 skip) 등을 보장해주어 좀 더 효율적인 인프라 관리를 할 수 있도록 해준다.
또한 여러 서버에 대해 동시 다발적으로 인프라 관리를 적용하는 기능을 좀더 편리하게 할 수 있도록 해준다.

이 도구의 담당은 서버 인스턴스마다의 메모리, 디스크, swap, init.d 등 소프트웨어가 돌아가기 위한 기본적인 vm 설정을 담당한다고 본다.

서버 템플릿 도구

Packer, Docker, Vagrant 등이 여기에 속한다고 한다.
서버에서 돌아갈 소프트웨어에 의존적인 것들을 설정 및 관리하는 도구라고 생각한다.

예를 들면 도커파일에는 보통 다음의 항목들이 정의된다.

  • 기반 이미지
  • Library 설치
  • EntryPoint(어떤 코드를 실행할지)

이 부분에서는 VM과 컨테이너의 차이도 설명을 하는데 이를 굳이 이해할 필요는 없다고 본다.

서버 프로비전 도구

테라폼이 여기에 속한다.
쉽게 말해서 서비스를 구성하는 서버 아키텍쳐를 구성하기 위한 도구라고 보면 될거 같다.

IaC 장점

책에서 여러가지 장점을 이야기한다.
하지만 대부분은 평소에는 크게 체감하지 못한다.
코드형 인프라 도구의 장점을 알게 되는 순간은 개인적으로 크게 2가지 라고 생각한다.

하나는, 동적인 개발 환경 서버의 구성이다.
기존 방식에서는 dev, staging, live 서버를 각각 정해진 VM에 대해 구성하고 서로 순번을 정하며 이를 사용한다.
IaC로 관리할 경우 dev에서라도 각 feature마다 다른 서버를 언제든지 쉽게 구성하여 사용하고 완료 후 이를 제거할 수 있다.

다른 하나는 인프라 장애 발생 상황이다.
모종의 이유로 서버에 장애가 생겨 부팅이 되지 않거나 접속등이 안되는 경우에 급하게 다른 서버를 준비해야 한다.
이와 같은 장애 상황에서 손으로 일일히 타이핑하다보면 실수가 생기기 마련이고 이는 빠른 장애 해결을 할 수 없게 만든다.
기존에 코드로 관리를 해두었다면 이상적으로는 엔터 한번을 통해 인프라 이사를 쉽게 처리하여 장애 처리를 더 신속하고 편하게 할 수 있다.

(개인적 기준의) 이상적인 개발 배포와 진행 흐름

테라폼으로 인프라 이키텍쳐를 형상 관리한다.
그리고 각 인프라 서버의 설정들은 Ansible 을 이용하여 관리하며 각 서버는 도커의 컨테이너로 실행되어 관리된다.
이는 CI/CD를 통해 버져닝 되어 동적으로 배포 관리가능하게 된다.

마지막으로 테라폼은 선언형 언어다. 이말은 즉 코드가 표현하는 것은 스냅샷이라는 것이다.


realjays

반박시 당신말이 맞습니다.