Chocolatey 설치
Vagrant 설치
Controller 가상머신 접속
SSH 키기반 인증(추가요망)
Ansible 설치(추가요망)
엔서블 용어정리
제어노드
Control Node, Controller, Ansible Engine
조건 : Unix 계열, python
관리노드
Managed Node, Target Node/Host ...
BM, VM, Instance, Network Device
관리노드의 사용조건
일반적으로는 SSH가 가능한 모든 시스템, python 설치
Windows : WinRM
인벤토리
정적 인벤토리 : 관리 노드의 목록 파일
(정적 인벤토리로는 수많은 생성되고 삭제되는 노드들을 파악하기 쉽지 않음)
동적 인벤토리 : 클라우드, CMDB에서 관리 노드 목록을 가져옴
CMDB : 구성 관리 데이터 페이스, 회사의 자산 (프린터, 네트워크 장비, 등등) 들을 목록으로 가지고 있는거임
플러그인 (이걸 사용하면 SSH가 아니어도 이용이 가능하게 만듬)
Anible 기능 확장
모듈
Anible 작업을 실행 할 수 있는 기본 단위
Python Code
AD-hoc(뜻 자체가 임시라는 뜻)
Ansible 임시 실행
하나의 모듈을 실행
테스크
하나의 모듈을 실행 -> 하나의 테스크(작업)
플레이
하나 이상의 테스크의 모음
플레이북
하나 이상의 플레이 모음
인벤토리
| 관련 자료 |
|---|
| https://docs.ansible.com/ |
| https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#intro-inventory |
/etc/ansible/hosts 가 인벤토리 기본 로케이션이고 만약 다르다면 -i 옵션으로 경로를 지정해주어야한다.
그리고 이 기본 인벤토리 파일은 사용하지 않는편이 좋다
포멧방식은 ini, yaml이 있는데 보통 ini를 사용함 yaml은 좀 더 복잡함
ini 형식의 예
key 값 형식이고
section으로 구분되어짐
유닉스에서는 확장자 개념이 없지만 관습적으로 윈도우처럼 확장자를 쓰기도한다. 유닉스에서는 구별 없이 전체를 파일명으로 읽기는 함
###예시
mail.example.com
[webservers]
for.example.com
bar.example.com
[dbservers]
one.example.com
two.example.com
three.example.com
### [] : 인벤토리 그룹
### 하나의 노드는 하나의 그룹에만 속해야할 필요는 없다.그룹의 호스트를 분류할 때
what
where
when
등등으로 분류를 하면 좋음 그리고 그룹안에 내용들은 다 서로중복이 가능함
호스트는[01:50]같은 식으로 범위를 지정 가능
인벤토리 변수A=100,B=200등등.. 지정 가능
ansible-inventory -i inventory.ini --graph
### 인벤토리 파일을 시각적으로 볼 수 있다.| 샘플 자료 |
|---|
| https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#intro-inventory |
질문
오토스케일링처럼 호스트가 생기고 없어지면 인벤토리관리는 어떻게 해주어야 하나요?
답변
동적 인벤토리를 사용하면 된다.
플레이북
플레이북은 yaml 포맷으로 되어 있는 파일로서, 인벤터리 파일에서 정의된 서버들에서 무엇을 해야할지를 정의한다. 일반적으로 앤서블을 사용한다고 하면 플레이북을 사용한다는 것을 의미하며, 플레이북 단독으로 사용되는 것이 아닌 플레이북 + 인벤터리의 조합으로 사용하게 된다. 즉, 인벤터리를 통해 어디에서(where) 작업을 수행할지를 명시하고, 플레이북을 통해 무엇을(what) 할지를 정의한다. (위에서 사용했던 예시는 플레이북을 사용하지 않았는데, 인벤터리에서 명시된 서버들에 정상적으로 접속할 수 있는지 단순히 테스트(ping) 하는 용도였기 때문이다)
간단한 플레이북의 예시를 들어보면 위와 같다. 위 플레이북의 이름은 lets nginx install 이고, 인벤터리 파일에서 모든 호스트를 대상으로 (hosts: all) 수행함을 명시하고 있다. become: true는 인벤터리의 접속한 리눅스 사용자가 sudo 권한으로 수행할지를 의미한다.
그 아래에 정의된 tasks 가 실제로 플레이북에서 실행되는 작업들을 나열한 것이며, 플레이북에서 가장 중요한 부분이다. tasks의 하위 항목에는 task를 나열할 수 있고, 위 예시에서는 1개의 task만이 정의되어 있다. 해당 task의 이름은 nginx package install 이고, yum을 통해 nginx를 (name: nginx) 설치해라 (state: installed) 라는 의미를 갖고 있다. 물론, "설치해라" 대신 "삭제해라" (state: removed) 라는 명령 또한 가능하다.
플레이북은 ansible-playbook 이라는 명령어를 통해 실행할 수 있으며, 가장 마지막 인자로 플레이북 파일의 이름을 입력한다.
ansible-playbook -i hosts.ini nginx.yaml보통 튜토리얼에서는 이해를 돕기 위해 1개의 플레이북만을 사용하지만, 실제로는 롤(role) 이라는 앤서블의 요소를 사용해 여러 개의 플레이북을 정의해 사용한다. 롤에 대한 설명은 추후 포스팅할 예정이다.
Tip : yaml 파일은 일반적으로 ---로 시작하는데, 이는 yaml 파일임을 명시하기 위한 목적으로 쓰인다. 또한, yaml에서 - name: nginx 와 같이 - 로 시작하는 항목은 리스트 (또는 배열) 로 사용됨을 나타낸다.
모듈
모듈은 플레이북에서 task가 어떻게(how) 수행될지를 나타내는 요소이다. 예를 들어 yum 명령어를 통해 패키지를 설치할 떄에는 yum 모듈을 사용할 수 있다. 위의 nginx.yaml 예시에서는 yum 모듈을 사용하였으며, task의 이름 (- name: nginx package install) 바로 밑에 모듈의 이름인 yum을 명시하였다.
당연하지만, yum으로 패키지를 설치하려면 어떤 패키지를 설치할 것인지, 해당 패키지를 삭제할지 설치할지 업데이트할지 등을 명시해야 한다. 따라서 yum 모듈은 어떤 패키지를 (name: nginx) 설치할지 삭제할지 (state: installed)에 대한 옵션을 명시해야만 한다. 여기서 한 가지 알 수 있는 것은, 모듈마다 요구하는 옵션이 모두 다르기 때문에 사용하려는 모듈의 옵션 사용 방법을 미리 숙지해야만 한다는 점이다.
다른 예시를 들어보자. debug 모듈은 인벤터리에 정의된 서버에서 디버깅을 위한 각종 값 또는 변수의 출력에 쓰이는 모듈이다.
debug 모듈은 yum 모듈과 다르게 어떠한 내용을 출력할지에 대한 명시가 있어야 하기 때문에 msg: 라고 하는 옵션을 명시해줘야만 한다. 이와 같이 각 모듈은 사용하는 방법이 모두 제각각이기때문에, 사용하기 전 반드시 구글링을 통해 사용 방법을 숙지해야만 한다. 앤서블은 약 500개의 모듈을 제공하고 있다고는 하지만, 자주 쓰이는 모듈은 사실상 한정되어 있으며 그러한 모듈의 사용 방법은 구글링하면 stack overflow나 server fault 등에서 쉽게 찾을 수 있기 때문에 크게 걱정하지 않아도 된다.
참고로, 위 debug 모듈의 결과값은 아래와 같다. debug 모듈은 꽤 자주 쓰이기 때문에 알아두면 편리하다.
앤서블과 멱등성
일반적으로, 앤서블은 멱등성 (idempotence) 를 제공하는 환경 자동화 도구라고 언급된다. 멱등성이란 수학에서 쓰이는 용어로, 동일한 작업을 수행해도 변화가 없음을 뜻한다. 예를 들어 100에 1을 곱해도 이는 여전히 100이기 때문에 멱등성의 예시로 쓰일 수 있다. 이와 같이, 똑같은 작업을 몇번을 수행해도 동일한 결과를 얻을 수 있다면 이를 멱등성이라고 칭한다.
앤서블 및 셰프, 퍼펫과 같은 환경 배포 자동화 도구는 멱등성을 제공하는 것을 지침으로 한다. 앤서블의 플레이북에서는 모듈 실행 시 결과를 상태 (state) 로 정의함으로써 최종적으로 존재해야 하는 환경을 명시한다. 해당 상태가 만족된다면 앤서블은 다른 작업을 하지 않고 task를 종료하는데, 이는 플레이북을 몇번이라도 실행하더라도 동일하게 수행된다. 따라서 앤서블은 플레이북에서 정의된 바람직한 상태를 만족하도록 수행하기 때문에 동일한 플레이북을 몇 번이고 실행해도 동일한 최종 결과값을 얻을 수 있는, 이른바 멱등성의 성질을 띠게 된다.
앤서블이 제공하고 있는 모듈의 대부분은 멱등성을 제공하는 것을 원칙으로 하기 때문에 모듈의 옵션 또한 멱등성을 고려하여 명시하도록 되어 있다. 따라서 한 번 성공적으로 수행된 플레이북은 다시 재실행하더라도 서버에 전혀 영향을 끼치지 않게 된다. 이미 플레이북이 원하던 상태(state)에 도달하였기 때문에 더 이상 작업을 수행하지 않는 멱등성을 준수하게 되는 것이다. 예를 들어 yum 모듈을 통해 state: installed 로 명시된 플레이북이 실행될 때, 해당 패키지가 이미 설치되어 있다면 해당 task는 아무런 동작도 하지 않고 success로 처리된 뒤 종료된다.
