1. Docker를 Ansible로 구축하기

• OS 프로비저닝 - 운영체제 + 기반이 되는 시스템 소프트웨어
• Application 프로비저닝 - Docker Application

2. 프로비저닝이란?

• 사용하길 기대하는 환경을 구성해주는 것

3. Ansible이란?

• 구성 관리 도구

4. Ansible 설치된 VM 만들기

1. Vagrantfile 만들기

Vagrant with VMWare

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  
  config.vm.box = "bento/ubuntu-20.04-arm64"
  config.vm.hostname = "ansible.local"

  config.vm.provider "vmware_fusion" do |vw|
	  vw.memory=4096
  end

  if Vagrant.has_plugin?("vagrant-vbguest")
	  config.vbguest.auto_update = false
  end
 
  config.vm.network "private_network"#, ip: "192.168.33.46", gateway: "192.168.33.1", dns: "8.8.8.8"
  config.vm.synced_folder ".", "/vagrant", type: "rsync", rsync__exclude: [".git/"]

  config.vm.provision "shell", inline: <<-SHELL
  #다음은 ansible을 설치하기 위한 쉘스크립트 시작
    export DEBIAN_FRONTEND=noninteractive
    sudo apt -y update
    sudo apt install -y ca-certificates apt-transport-https
    sudo apt install -y software-properties-common curl
    sudo apt install -y python3-pip python-is-python3
    sudo add-apt-repository --yes --update ppa:ansible/ansible
    sudo apt install -y ansible
    sudo pip3 install docker
  # 쉘스크립트 끝
  SHELL
end

2. ansible.local 머신 부팅 및 접속

1. Vagrant up

2. vagrant ssh

3. Ansible 버전 확인

ansible --version

4. Ansible에 호스트 등록

sudo bash
echo "localhost" >> /etc/ansible/hosts
exit

5. Nginx 서비스 시작

1. 설치

sudo apt install -y nginx

2. ansible로 nginx 시작

ansible localhost -b -c local -m service -a "name=nginx state=started"

• localhost: 인벤토리에 기재된 서버중에서 명령을 수행하는 대상
  -> 지정되지 않다면 /etc/ansible/hosts 에 기재된 서버
• -b: 원격 실행되는 대상 서버에서 어떤 사용자에 의해 실행되는지 여부
  -> -b는 root 사용자를 의미함
• -c local: 대상 서버가 자기 자신인 경우
  -> ssh 가 필요 없음 -> local 연결로 부여
  -> 일반적으로는 ssh 사용
• -m service: service 모듈을 이용함 선언
  ansible에서 사용 가능한 모듈
• -a"name-nginx state=started"
  -> -m에 기술한 모듈에 전달하는 인수
  -> name=nginx: 이름이 nginx인 서비스에 댛
  -> state:started: 상태가 시작된 상태여야 함

6. 위의 작업을 파일에 기술하기 위한 방법

1. ansible-playbook

• 환경 설정 및 구축 절차를 통일된 형식으로 기술
• 매개 변수 등 환경의 차이를 관리
• 실행 전에 변경되는 부분을 파악 가능

2. git에서 Playbook 샘플 가져오기

1. git 설치

sudo apt install -y git

2. git에서 playbook 샘플 clone

git clone https://github.com/devops-book/ansible-playbook-sample.git

7. ansible-playbook 작성

1. roles/common/tasks/main.yml

• 현재 main.yml 은 yum 패키지 관리자를 사용하도록 선언됨.
  -따라서 아래와 같이 두줄 주석처리
  

2. ROLES/NGINX/TASKS/MAIN.YML

yum을 apt로 변경

---
---
# tasks file for nginx
- name: install nginx
  apt: name=nginx state=present
- name: replace index.html
  template: src=index.html.j2 dest=/var/www/html/index.html
- name: nginx start
  service: name=nginx state=started enabled=yes

8. ansible-playbook 실행

1. 실행

ansible-playbook -i development site.yml

2. 상태

• ok: 결과가 이미 예상했던 대로 되었다
  -> 아무것도 할 필요가 없음
• skip: 명시적인 조건에 의해 TASK 자체가 SKIP 됨
• changed: TASK 실행에 의해 예상대로 변경됨
• unreachable: 원래의 실행 대상 호스트에 도달 불가(error)
• failed: 실행 대상 호스트에 도달했지만, 조작에 실패(error)

3. 적용사항 확인

curl localhost

4. production으로 변경

1. 변경

ansible-playbook -i production site.yml

2. 확인

curl localhost

9. ansible-playbookr 구성

1. site.yml

hosts: webservers

• 실행대상 결정
• 인벤토리 파일에 정의된 그룹

roles

• roles 경로에 정의된 수행 TASK를 포함

2. 인벤토리 파일: 실행 대상 정의

1. hosts: webservers의 정의 위치

• -i: 인벤토리 지정
• -i development: development 파일이 인벤토리 파일
• -i production: production 파일이 인벤토리 파일

2. 인벤토리 파일 구성

[섹션 이름]

• 그룹 설정

[그룹 이름: 옵션]

• webservers:children 섹션
  -> development-webservers 그룹을 포함
• development-webservers 섹션
  -> localhost를 포함
  -> 즉 webservers는 localhost 1개

3. role 파일: 실행 내용 정의

앞에서 수정한 roles/xxxx/tasks/main.yml

• xxxx의 이름은 role의 이름
  -> site.yml 에 언급하여 포함시킴
• yaml 형식
• 모듈에 의해 동작이 처리됨

4. 환경에 의한 설정 변경

1. vars

• 인벤토리의 환경 변수는 group_vars에 정의
• group_vars/인벤토리섹션.yml
  

2. template

• roles/ngnix/templates/index.html.j2 파일
  

5. 인프라 구성 관리 도구

1. 인프라 구성 관리 도구의 특징

1. 선언적

• 구성 정보에 의해 설정 대상의 "상태"가 명확하게 기재
• (O) 서버가 어떤 상태로 존재하면 좋을지의 상태를 설명
• (x) 어떻게 하고 싶은 것인지 작업을 기술
• 즉 상태를 파악 할 수 있는 것이 선언적 특징

2. 추상화

• 구성 정볼르 대상 환경의 미세한 차이에 따라 별도로 구분하여 기술하지 않음
• 구성 정보를 추상적으로 작성
  -> 웹 서버, DB서버와 같이 서버의 상태 자체를 추상화 가능

개발자에겐..

• 전제가 되는 환경을 명확하게 인식해야 할 필요 없음
  -> OS의 차이, 패키지 관리자(yum, apt-get, ..)의 차이

3. 수렴화

convergence

• 대상의 상태가 어떠한 상태라고 하더라도, 기대했던 상태로 변경되는 것

시간의 흐름과 상태의 정보 분리

• 이전 파일의 내용에서 특정 부분이 변경되어야 할 때
• 수렴화 = 이전 상태와 관계 없이 원하는 결과로 귀결

4. 멱등성

idempotence

• 몇 번을 실행해도 같은 결과를 얻을 수 있는 성질
• 선언적, 수렴화 개념의 결합

인프라 구성 관리에서 멱등성의 의미

• 도구에 의한 처리 -> 기술(표현)의 간결화
• 잘못된 상태에서 반복 실행될때 결과가 달라지지 않음

5. 간소화

기술한 설정 -> 실행의 자동화

구성 관리 도구를 통해 구성 정보 기반

• 대상에 대한 설정을 신속하게 수행
• 여러 대를 동시에 기계적으로 수행 가능 -> 빠르다

Portability

• 텍스트 형식으로 팀 내 공유가 쉬움

Review

• 텍스트 파일이므로, 변경 사항의 파악이 쉬움(diff 사용)
• 추상화된 내용의 기술 -> 짧은 리뷰 시간

Version 관리

• 문제가 있을 경우, 이전 버전으로 되돌릴 수 있음
• 환경을 고정 시킬 수 있음

2. 인프라 구성 관리도구가 해결해주는 문제

1. 구축 절차 이해하기 어려움

• "선언적" 기술 방법을 이용해 상태가 수렴화
• 절차가 아닌 결과만 바라봄

2. 설정을 추가 할 수 없음

• 모든 설정은 "멱등성"과 "수렴화"에 의해 의존 관계 해방
• 기존 파일에서 일부만 고치겠다 -> 불가능, 구성관리 도구를 통해 고쳐야 함

3. 구축 절차를 다른 환경에서 활용하기 어려움

• "추상화" 기술에 의해 OS등의 환경 조건에 대한 걱정 없음
• 약간의 다른 환경에 활용하는 것은 다루지 않음