#6 IaC 개선(구성 관리 도구와 특징)

VagrantFile
 - VM 생성
 - VM 초기상태, 구축, 절차 > Shell Script 사용
 : 두 행위를 하나의 파일로 합쳐서 진행
 : Text로 표현 => 변경 전, 후에 대한 비교가능 > 예상 가능

Vagrant
 : VM 생성 후 Provisioning 도구(초기상태 구축 툴)
 : 개인화 된 환경 구축 

Vagrant로 IaC구현
 - Lcoal 개발환경(개인화 환경) 구축 절차를 Code화
  : Shell Script를 통해    절차 표현
 - 환경 구축절차와 환경 정보(Cpu 개수, Memooory 크기, Host 이름 등) 기술

Vagrant 사용 이점
 : 환경 구축 작업의 간소화 > vagrant up
 : 환경 공유가 용이
   > vagrant file 공유 : 환경 정보 자체를 공유
 : 환경 파악이 쉬워짐
  > 서버가 담당하는 일을 Vagrantfile을 보면 알 수 있음
 : 팀 차원 유지보수 가능
  > 팀 멤버 누구라도 이 파일을 참조
  > vagrant up 실행시 환경 이용가능
~> IaC로 구현시 얻는 이점: 논의 > 공유 > 개선이 가능하기 때문

Vagrant 단점
 : 구축 적차를 알기 어려움
  > Vagrantfile에 shell script형태로 구축 절차 표현
  > 구축 절차를 기술하는 사람에 따라 달라짐
  > 약간의 설정변경 > 작성 방법이 작성자에게 위임(다르게 썼는데 결과가 같은 경우 발생)
 : 설정을 추가할 수 없음
  > 가상 머신을 초기 구축하는 경우에는 문제 없음(처음부터 구축하는 절차)
  > 기 구축된 환경에서 추가 설정하는 경우 해결 못 함
   ~> vagrant provision
  > vagrant provision으로 스크립트 실행하는 것은 가능하지만, 재실행 가능하게 만드는 것은 작성자에게 위임됨
 : 구축 절차를 다른환경에서 유용하기 힘듦
  > Vagrantfile은 Locall 개발 환경 구축에 용이
  > Scale-Out 한 서버 등의 유연성이 필요한 설정이 어려움
   ~> 파라미터 설정이 필요

해결 방법
> OS 구축 후 환경설정
- 어떻게 범용적이고 이해하기 쉽게 할 것인가?

1.  환경 구축 절차에서 속인성 배제
 : 작성자의 역량에 속하는 부분 제거
 : 상이한 환경 ~> 동일한 절차를 사용

- 절차의 속인성 제거
 기존 : Vagrantfile에서 Shell Script로 표현
  > Shell Script는 작성자의 역량 > 작성자마다 가지각색으로 표현될 수 있음
 통일된 형태로 표현
  > 환경 변경을 쉽게 할 수 있을 것으로 기대

2. 서로 다른 환경에서 동일한 절차 이용
 기존 : Vagrantfile을 이용한 환경 구축 > Local 개발 환경
  > Intel/Arm CPU 등에 따라 달라질 수 있음
  > IP 주소, 메모리 할당 크기 등이 달라질 수 있음
>> 파라미터가 다름 : 다른 환경에서 그대로 실행할 수 없는 경우 발생
>> 안전하게 실행 불가능 : 실제 운영 환경에서는 실수가 있으면 안 됨

Infra 구성 관리도구 사용
- 앞선 Vagrant의 문제를 해결하기 위한 방법

특징)
- 선언적
 : 구성 정보에 의해 설정 대상의 상태가 명확히 기재
 : 상태를 파악할 수 있음 = 선언적
 : 미챌 드한(Ansible 개발)은 구성 관리 도구가 선언적 언어로 표현되어야 한다고 말함
  > "서버가 어떤 상태로 존재했으면 좋겠다" > 생각하는 상태를 설명하는 것 O
  > "어떻게 하고 싶은것인가"라는 작업을 기술하는 것 X (절차적 언어임)

- 추상화
 : 구성 정보를 대상 환경의 미세한 차이에 따라 별도로 구분하여 기술하지 않음
  > 코드 실행의 전문성 배제
  > Ubuntu / Debian 등 운영체제의 미세한 차이에 따라 구성 관리 기술(표현)이 바뀌지 않음
 : 구성 정보를 추상적으로 작성
  > Web Server, DB Server와 같이 서버의 상태 자체를 추상화 가능
 : 개발자
  > 전제가 되는 환경을 명확히 인식해야 할 필요 없음
  > OS의 차이, 패키지 관리자(yum, apt-get, snap)의 차이 등을 인식할 필요 없음

- 수렴화 (Convergence)
 : 대상의 상태가 어떠한 상태라고 하더라도 기대했던 상태로 변경되는 것
 : 시간의 흐름과 상태의 정보 분리
  > 이전 파일의 내용에서 특정 부분이 변경되어야 할 때
  ~> 스크립트 작성하는 경우 awk, sed를 사용 > 이전 파일이 기대했던 내용과 다르면 실패할 가능성 높음
  > 이전 상태와 관계 없이 원하는 결과로 귀결

- 멱등성 (Idempotence)
 : 몇 번을 실행해도 같은 결과를 얻을 수 있는 성질
  $f(f(x)) = f(x)$
 : 선언적 + 수렴화의 결합 개념
 : 인프라 구성 관리에서 멱등성의 의미
  > 멱등성이 담보되지 않은 Shell Script
   : 이전 상태 취득, 조건 분기(if)에 의해 조작 수행을 분명하게 정의
  > 멱등성이 있는 도구
   : 도구에 의한 처리 > 기술(표현)의 간결화
   : 잘못된 상태에서 반복 실행 > 결과가 달라지지 않음 > 안심할 수 있음

- 간소화 
 : 기술한 설정 > 실행의 자동화
 : 구성 관리 도구를 통해 구성 정보 기반으로
  > 대상에 대한 설정을 신속하게 수행
  > 여러 대를 동시에 기계적으로 수행 가능 > 실행 속도가 빠름

+) 간소화 관점에서 다른 장점
 1. Portability
  : 텍스트로 관리하기 때문에 팀 내 공유가 쉬움
 2. Review
  : text파일 > 변경 사항의 파악이 용이(diff)
  : 추상화 된 내용의 기술 > 짧은 리뷰 시간
 3. Version 관리
  : 문제가 있는 경우, 이전 버전으로 되돌릴 수 있음
  : 환경을 고정시킬 수 있음(Service Update 문제 해결)
 4. Open Source

구성 관리 도구의 종류
Ansible : Redhat의 구성 관리 도구, Python으로 개발(우분투도 사용 가능)
Chef : Ruby와 Erlang으로 개발, Ruby의 DSL사용
Puppet : Ruby로 개발

인프라 구축 테스트
- 구축/설정 변경 효율화 > 구성 관리 도구 사용
- 구축된 시스템에 대한 테스트
- 절차서 + 파라미터 시트 기반으로 테스트 진행 필요
 > 별도의 테스트 케이스 + 테스트 절차서 > 개별 수행
- 테스트의 필요성은 대부분의 사람이 느낌
 > 테스트 부족 = 버그나 장애의 발생으로 이어짐
- 테스트를 안하는 이유
 > 테스트가 어렵고 번거로움
 > 인프라에 대한 테스트는 더 어려움 

- 테스트의 코드화
장점)
 > 테스트 코드 = 테스트 케이스
 > 테스트 코드 활용
 > 코드를 통한 리뷰 가능

인프라 구축 테스트의 예)
 > 디렉토리 퍼미션(Directory Permission) 검사
 > 설치 대상 패키지 조사
 > 서비스 구동 상태 점검

테스트 자동화 도구
- Serverspec

==========실습 ==========
Ansible이 설치된 VM 생성

sudo bash
#Ansible에 호스트 등록
echo 'localhost" >> /etc/ansible/hosts 
exit

sudo apt install nginx
명령어 분석)
ansible localhost -b -c local -m service -a "name=nginx state=started"  

1) localhost
 : 인벤토리에 기재된 서버 중에서 명령을 수행하는 대상
 : /etc/ansible/hosts에 기재

2) -b
 : 원격 실행되는 대상 서버에서 어떤 사용자에 의해 실행되는지 여부
 : -b는 root 사용자 의미

3) -c local
 : 대상 서버가 자기 자신(실행하는 서버와 동일)인 경우
  ~> ssh 필요 없음(local 연결 부여)
 : 일반적으로는 ssh 사용

4) -m service
 : service 모듈 이용 선언

5) -a "name=nginx state=started"
 : -m에 기술한 모듈에 전달하는 인수
 : name=nginx > 이름이 nginx인 서비스에 대해
 : state=started > 상태가 시작된 상태여야 함
 > 시작 해야한다는 것이 아님
 > 시작되어 있는 상태를 만족해야 하는 것임(선언적)

위의 작업을 기술하기 위해서는)
ansible-playbook
 > 환경 설정 및 구축 절차를 통일된 형식으로 기술
 > 매개 변수 등 환경의 차이를 관리
 > 실행 전에 변경되는 부분을 파악 가능 
 > https://github.com/devops-book/ansible-playbook-sample.git 참고

sudo apt install -y git
(샘플 클론)
git clone https://github.com/devops-book/ansible-playbook-sample.git 

Ansible-playbook-sample 구조

상태
1. OK
 : 결과가 이미 예상했던 대로 되었다.
 : 아무것도 할 필요가 없었음
2. SKIP
 : 명시적인 조건에 의해 Task 자체가 Skip됨(실행 안 함)
3. CHANGED
 : Task 실행에 의해 예상대로 변경 됨
4. UNREACHABLE
 : 원래의 실행 대상 호스트에 도달 불가(Error)
 : 접속이 안 됨
5. FAILED
 : 실행 대상 호스트에 도달했지만, 조작에 실패(Error)
 : 점속은 되었으나 실패


인프라 구성 관리도구가 가져다 주는 것
 1. 구축 절차를 이해하기 어렵다. : 몰라도 되는 것이기에 나빠지는 것이 아님
  > 선언적 기술 방법 > 상태가 수렴화
  > 절차가 아닌 결과만 바라봄
 2. 설정을 추가할 수 없음
  > 모든 설정은 "멱등성"과 "수렴화"에 의해 의존 관계가 해방
   ~> Ansible을 이용해서 새로운 설정파일을 생성 하는 것임
  > 기존 파일에서 일부만 고치겠다 불가능
 3. 구축 절차를 다른 환경에서 유용하기 어려움
  > "추상화" 기술에 의해 OS 등의 환경 조건을 걱정 안 함
  > 약간의 다른 환경에 활용하는 것(적용X)은 다루지 않음