ref. Ansible Document

About Ansible

Ansible은 IT 자동화 도구이다. 시스템을 구성하고 소프트웨어를 배포한다. 또한 지속적 배포(CD, continuous deployments)나 다운타임 제로 업데이트와 같은 고급 IT 작업을 조정한다.

Ansible의 주요 목표는 단순성과 사용 편의성이다. 또한 보안과 안정성에 중점을 두고 있으며 부품 이동의 최소화, (다른 전달 수단 및 pull 모드의 대안으로써) 전달을 위한 OpenSSH이 사용, 프로그램에 익숙하지 않은 사람까지도 이해하기 쉽도록 설계된 언어를 포함한다.

우리는 단순함이 모든 규모의 환경과 관련이 있다고 생각하므로 개발자, 시스템 관리자, 릴리스(release) 엔지니어, IT 관리자 및 그 사이의 모든 유형의 사용자들을 위해 설계하였다. Ansible은 소수의 인스턴스가 있는 소규모 설정에서 수천 개의 인스턴스가 있는 엔터프라이즈 환경에 이르기까지 모든 환경을 관리하는데 적합하다.

Ansible은 에이전트 없이 시스템을 관리한다. 원격 데몬(daemon)을 업그레이드하는 방법이나 데몬이 제거돼 시스템을 관리 할 수 없는 문제에 대한 질문은 없다. OpenSSH는 가장 많이 검토된 오픈 소스 구성 요소 중 하나이므로 보안 노출이 크게 줄어든다. Ansible은 분산돼있으며 기존 OS 자격 증명을 사용하여 원격 컴퓨터에 대한 엑세스를 제어한다. 필요한 경우, Kerberos, LDAP, 기타 중앙 집중식 인증 관리 시스템과 쉽게 연결할 수 있다.

Ansible은 매념 약 3-4회 Ansible의 새로운 주요 버전을 release한다. 핵심 응용 프로그램은 언어 설계 및 설정의 단순성을 평가하면서 다소 보수적으로 발전한다. 그러나 새로운 모듈, 플러그인 개발에 대한 커뮤니티는 매우 빠르게 움직이며 각 release에 많은 새로운 모듈을 추가한다.

Ansible 개념

ref. 사용자 안내서 > Ansible 개념

아래 개념은 Ansible의 모든 용도에 공통이다. 모든 종류의 자동화에 Ansible을 사용하려면 이를 이해해야한다. 이 기본 소개는 나머지 사용자 안내서를 따르기 위한 배경을 제공한다.

Control node

• Ansible이 설치된 (종류에 상관없이) 모든 시스템

어떤 제어 노드에서든 /usr/bin/ansible 또는 usr/bin/ansible-playbook 호출함으로써 command와 playbook을 실행할 수 있다. 랩탑, 공유 테스크탑, 서버는 모두 Ansible을 실행할 수 있는데, 즉 이는 Python이 설치돼있다면 어떤 컴퓨터든 컨트롤 노드로 사용될 수 있음을 말한다. 단, Windows 시스템을 제어 노드로 사용할 수는 없다. 여러 제어 노드를 가지는 것은 가능하다.

Managed nodes

• Ansible로 관리하는 네트워크 장치 (and/or servers)

관리되는 노드는 때때로 호스트(host)라고도 한다. 관리되는 노드에 Ansible이 설치 돼있지는 않다.

Inventory

• 관리되는 노드의 목록

인벤토리 파일은 때때로 호스트 파일이라고도 한다. 인벤토리는 관리되는 노드에 대한 각각의 IP주소와 같은 정보를 지정할 수 있다. 또한 인벤토리는 관리 노드를 구성하여 쉽게 확장 가능하도록 그룹을 만들고 중첩시킬 수 있다. 자세한 정보는 인벤토리 작업 섹션을 참조하라.

Modules

• Ansible 코드의 실행 단위

각 모듈은 특정 유형의 데이터베이스에서 사용자를 관리하는 것부터 특정 유형의 네트워크 장치에서 VLAN 인터페이스 관리까지 특정한 용도로 사용된다. 작업으로 단일 모듈을 호출하거나, 플레이북에서 여러 다른 모듈을 호출 할 수도 있다. Ansible에 몇 개의 모듈이 포함돼있는지 알아보려면 모든 모듈 목록을 확인해라.

Tasks

• Ansible의 작업 단위

ad-hoc 명령을 사용하여 단일 작업을 한 번 실행할 수 있다.

Playbooks

• 반복해서 실행하고자 해당 작업을 실행 순서대로 저장해 놓은 정렬된 작업 리스트

플레이북에는 task 뿐만 아니라 변수도 포함될 수 있다. 플레이북은 YAML로 작성돼있으며 읽거나 쓰거나 공유하거나 이해하는데 어렵지 않다. 플레이북에 대한 자세한 내용은 플레이북 정보를 참조하라.

시작하기

ref. https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html#action-create-a-basic-inventory

기본적인 Ansible command 또는 playbook

• 인벤토리에서 실행할 기계를 선택한다.
• 일반적으로 SSH를 통해 해당 시스템 (or 네트워크 장치 or 기타 관리 노드)에 연결한다.
• 하나 이상의 모듈을 원격 시스템에 복사하고, 거기서 실행을 시작한다.

Ansible은 훨씬 더 많은 작업을 수행 할 수 있지만 Ansible의 모든 강력한 구성, 배포, 오케스트레이션 기능을 탐색하기 전에 가장 일반적인 사용 사례를 이해할 필요가 있다. 이 페이지에서는 간단한 인벤토리와 ad-hoc command를 사용하는 기본 프로세스를 보여준다. Ansible의 작동 방식을 이해하면 ad-hoc에 대한 자세한 내용을 읽고, 인벤토리를 사용해 인프라를 구성하고 플레이 북을 통해 Ansible의 모든 기능을 활용할 수 있다.

---

🔎오케스트레이션(orchestration)
ref. redhat/what-is-orchestration
오케스트레이션은 컴퓨터 시스템과 어플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미한다.
IT 팀은 많은 서버와 어플리케이션을 관리해야 하지만 이를 수동으로 수행하는 것은 확장 가능한 전략이 아니다. IT 시스템이 복잡해질수록 유동적인 부분을 모두 관리하는 것 또한 복잡해지며 시스템 또는 기기 전체에서 자동화된 여러 테스크와 관련 설정을 결합해야 할 필요성도 높아진다. 바로 이 부분에서 오케스트레이션이 큰 도움이 된다.

자동화와 오케스트레이션은 서로 다르지만 그 개념은 연관 되어 있다. 자동화는 기업에서 IT 시스템에 대한 수작업을 줄이거나 대체하고, 그 대신 소프트웨어를 사용해 테스크를 수행함으로써 비용, 복잡성, 오류를 줄이는 방식으로 효율성을 개선하도록 지원한다.
📌일반적으로 자동화가 단일 태스크의 자동화를 의미하는 반면, 오케스트레이션은 여러 이기종 시스템 정반에서 다양한 단계를 수반하는 프로세스 또는 워크플로우를 자동화하는 방법을 뜻한다. 우선 프로세스를 자동화하고 나면 이를 자동으로 실행되도록 오케스트레이션 할 수 있다.

---

Selecting machines from inventory

Ansible은 인벤토리에서 관리하려는 머신에 대한 정보를 읽는다. IP 주소를 임시 명령으로 전달할 수 있지만 Ansible의 전체 유연성과 반복성을 활용하려면 인벤토리가 필요하다.

Action: create a basic inventory

기본 인벤토리를 위해 /etc/ansible/hosts를 수정하거나 만들고 몇몇의 리모트 시스템을 추가한다. 예를 들어 IP 주소나 FQDNs를 사용할 수 있다.

192.0.2.50
aserver.example.org
bserver.example.org

Beyond the basics

인벤토리는 IP 및 FQDN보다 훨씬 많은 것을 저장할 수 있다. aliase(별명)를 작성하기, 호스트 변수가 있는 단일 호스트에 대한 변수값 설정하기, 그룹 변수가 있는 여러 호스트에 대한 변수값을 설정하기 등이 가능하다.

Connecting to remote nodes

Ansible은 SSH 프로토콜을 통해 원격 시스템과 통신한다.
Ansible은 기복적으로 SSH와 마찬가지로 기본 OpenSSH를 사용하고 현재 사용자 이름을 사용해 원격 시스템에 연결한다.

---

🔎 SSH, OpenSSH
SSH

• Secure Shell
• 네트워크 상의 다른 컴퓨터에 로그인 하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해주는 응용 프로그램 또는 그 프로토콜을 가리킨다.
• 기존은 rsh, rlogin, 텔넷 등을 대체하기 위해 설계
• 강력한 인증 방법과 (안전하지 못한 네트워크에서) 안전하게 통신 할 수 있는 기능을 제공
• 기본적으로 port#22 사용

OpenSSH

• ssh 프로토콜을 이용하여 암호화된 통신 세션을 컴퓨터 네트워크에 제공하는 컴퓨터 프로그램의 모임
• SSH communications security가 제공하는 사유 시큐어 셀 소프트웨어 제품군을 대체할 목적으로 오픈 소스 로 작성되었다.

---

Action: check your SSH connections

동일한 사용자 이름을 사용해 인벤토리 내 모든 노드에 SSH를 사용한 연결이 가능한지 확인해라. 필요한 경우 공개 SSH key를 해당 시스템의 authorized_keys 파일에 추가하라.

Beyond the basics

여러가지 방법으로 기본 리모트(원격) 사용자 이름을 대체할 수 있다.

• command line에서 -u 파라미터로 전달
• 인벤토리 파일에서 사용자 정보 설정
• configuration 파일에서 사용자 정보 설정
• 환경변수 설정

✔️(참고)어떻게 엔시블의 동작을 제어하는가
사용자 정보를 전달하는 각 방법의 (때때로 직관적이지 못한) 우선 순위에 대한 세부 사항을 위한 우선순위 규칙이 존재한다. 연결 방법 및 세부 사항에서 연결에 대한 자세한 내용을 읽도록 하라.

Copying and executing modules

일단 연결되면 Ansible은 command 또는 플레이북에 필요한 모듈을 원격 컴퓨터로 전송하여 실행한다.

Action: run your first Ansible commands

ping 모듈을 사용해 인벤토리의 모든 노드를 Ping한다 :

$ ansible all -m ping

이제 모든 노드에서 실시한 command을 실행한다 :

$ ansible all -a "/bin/echo hello"

다음과 같이 인벤토리의 각 호스트에 대한 출력이 표시되어야한다"

aserver.example.org | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

Beyond the basics

Ansible은 기본적으로 SFTP를 사용해 파일을 전송한다. 관리하려는 시스템 또는 장치가 SFTP를 지원하지 않는 경우 Ansible 구성에서 SCP모드로 전환 할 수 있다. 파일은 임시 디렉토리에 저장되고 거기서 실행된다.
명령을 실행하기 위한 (sudo 같은) 권한의 점진적 확대가 필요한 경우 become 플래그를 전달하도록 한다.

# as bruce
$ ansible all -m ping -u bruce
# as bruce, sudoing to root (sudo is default method)
$ ansible all -m ping -u bruce --become
# as bruce, sudoing to batman
$ ansible all -m ping -u bruce --become --become-user batman

권한 확대에 대한 자세한 내용은 Understanding privilege escalation: become를 참조하라.

Ansible architecture

Ansible은 클라우드 프로비저닝, configuration 관리, 어플리케이션 배포, 인프라-서비스 오케스트레이션 및 여러 기타 IT 요구사항을 자동화 하는 IT 자동화 엔진이다.

프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

Ansible은 처음부터 multi-tier 배포를 위해 설계되었으므로 한 번에 하나의 시스템을 관리하는 것이 아니라 모든 시스템이 상호 관련되는 방식을 설명함으로써 IT 인프라를 모델링한다.
에이전트를 사용하지 않고, 추가적인 커스텀 보안 인프라 또한 사용하지 않으므로 배포가 매우 쉽다. 가장 중요한 것은 매우 간단한 언어인 YAML(Ansible Playbooks에서 사용하고 있는 형식)을 사용해 평범한 영어로 접근하여 자동화 작업을 설명 할 수 있다.

이 섹션에서는 Ansible의 작동 방식에 대한 간단한 개요를 제공하므로 각 조각이 어떻게 결합되는지 볼 수 있다.

Modules

Ansible은 노드에 연결하고 "Ansible modules"라는 스크립트를 푸시함으로써 움직인다. 대부분의 모듈은 원하는 시스템의 상태를 설명하는 파라미터를 승인한다. 그 다음 Ansible은 이러한 모듈을 실행하고 (기본적으로 SSH를 통해), 완료되면 제거한다. 모듈 라이브러리는 모든 시스템에 상주 할 수 있으며, 서버 daemon, DB가 필요하지 않다.

자신만의 모듈을 작성할 수 있지만 반드시 그럴 필요가 있는가에 대해 우선 고민해야한다.
일반적으로 자주 사용하는 터미널 프로그램, 텍스트 편집기 및 버전 제어 시스템을 사용해 컨텐츠 변경 사항을 추적한다. JSON을 반환할 수 있는 모든 언어(Ruby, Python, bash, etc)로 특수 모듈을 작성해야 할 것이다.

Module utilities

여러 모듈이 동일한 코드를 사용하는 경우 Ansible은 해당 기능을 모듈 유틸리티로 저장해 중복 및 유지보수를 최소화한다.
예를 들어 URL을 분석하는 코드는 lib/ansible/module_utils/url.py이다. 자체 모듈 유틸리티도 작성할 수 있다. 모듈 유틸리티는 Python 또는 PowerShell로만 작성할 수 있다.

Plugins

플러그인은 Ansible의 핵심 기능을 강화한다. 모듈이 대상 시스템에서 별도의 프로세스 (모통 리모트 시스템을 의미한다.)로 실행되는 반면, 플러그인은 /usr/bin/ansible 프로세스 내의 제어 노드에서 실행된다. 플러그인은 데이터 변환, output 로깅, 인벤토리 연결 등 Ansible의 핵심 기능에 대한 옵션과 확장을 제공한다. Ansible에는 여러 편리한 플러그인이 포함되어 있으며 쉽게 작성할 수 있다. 예를 들어, 인벤토리 플러그인을 작성하여 JSON을 반환하는 모든 데이터 소스에 연결할 수 있다. 플러그인은 Python으로 작성해야 한다.

Inventory

기본적으로, Ansible은 관리되는 모든 기기를 원하는 그룹으로 묶는 파일(INI, YAML 등)을 가지고 관리하는 기기를 나타낸다. 새 시스템을 추가하기 위해 추가적인 SSL 서명 서버가 필요하지 않으므로 NTP 또는 DNS 문제로 인해 특정 시스템이 연결되지 않는 번거로움이 없다. 인프라에 또다른 source of truth를 원한다면 Ansible도 그에 연결할 수 있다.(If there’s another source of truth in your infrastructure, Ansible can also connect to that.) Ansible은 EC2, Rackspace, OpenStack 등과 같은 소스에서 인벤토리, 그룹, 가변 정보를 가져올 수 있다.

일반 텍스트 인벤토리 파일은 다음과 같다.

---
[webservers]
www1.example.com
www2.example.com

[dbservers]
db0.example.com
db1.example.com

인벤토리 호스트가 나열되면 변수는 간단한 텍스트 파일로써 이에 할당될 수 있다.(‘group_vars/’나 ‘host_vars/’로 불리는 서브 디렉토리 또는 인벤토리 파일에 직접)
또는 이미 언급했듯이 동적 인벤토리를 사용해 EC2, Rackspace, OpenStack과 같은 데이터 소스에서 인벤토리를 가져온다.

Playbooks

플레이북은 한 번에 몇 개의 기기를 처리해야하는지에 대한 세부적인 제어를 통해 여러 인프라 토폴로지의 다양한 조각들을 정교하게 조정할 수 있다. 이는 Ansible이 가장 흥미롭게 시작되는 곳이다.
Ansible은 잘 조정된 단순한 오케스트레이션 접근 방식을 가지고 있다. 이는 당신의 자동화 코드가 앞으로 수년 동안 당신에게 완벽히 이치에 맞아야 하며 특별한 구문이나 특징에 대해 기억할 것이 거의 없을 것이라고 믿기 때문이다.

간단한 플레이북은 다음과 같다:

---
- hosts: webservers
serial: 5 # update 5 machines at a time
roles:
- common
- webapp

- hosts: content_servers
roles:
- common
- content

The Ansible search path

모듈, 모듈 유틸리티, 플러그인, 플레이북, role는 여러 장소에 존재할 수 있다. Ansible의 핵심 기능을 확장하기 위해 고유의 코드를 작성한다면 Ansible 컨트롤 노드 내 다른 위치들에 유사하거나 같은 이름을 가진 여러 파일들을 가지게 될 것이다. 검색 경로는 주어진 플레이북 실행 내에서 Ansible이 발견하고 사용할 파일을 결정한다.

Ansible의 검색 경로는 실행에 따라 점차 증가한다. Ansible이 주어진 실행에 포함된 각각의 플레이북과 role을 찾을 때, 해당 플레이북이나 role과 관련된 어떠한 디렉토리를 검색 경로에 추가한다. 이러한 디렉토리는 플레이북 또는 role의 실행이 완료된 후에도 실행 기간 동안 범위안에서 계속 유지된다. Ansible은 그다음 순서로 모듈, 모듈 유틸리티, 플러그인을 로드한다.

1. 커멘드 라인에서 지정된 플레이북에 인접한 디렉토리. 만약 엔시블 플레이북 /path/to/play.yml로 Ansible을 실행하면 Ansible은 다음 디렉토리가 존재하는 경우에 해당 디렉토리를 추가한다.:

/path/to/modules
/path/to/module_utils
/path/to/plugins

2. 커멘드 라인에서 지정된 플레이북에 의해 정적으로 가져오는 플레이북에 인접한 디렉토리. play.yml이 - import_playbook: /path/to/subdir/play1.yml을 포함하는 경우, Anable은 이러한 디렉토리가 존재하는 경우 해당 디렉토리를 추가한다. :

/path/to/subdir/modules
/path/to/subdir/module_utils
/path/to/subdir/plugins

3. 플레이북에서 참조하는 role 디렉토리의 하위 디렉토리. Play.yml이 myrole을 실행하는 경우 Anable은 이러한 디렉토리가 존재하는 경우 해당 디렉토리를 추가한다.:

/path/to/roles/myrole/modules
/path/to/roles/myrole/module_utils
/path/to/roles/myrole/plugins

4. anable.cfg 또는 관련 환경 변수에 의해 기본 경로로 지정된 디렉토리(여러 플러그인 유형에 대한 경로 포함). 자세한 내용은 Ansible Configuration Settings을 참조하십시오.
   샘플 anable.cfg 필드:

DEFAULT_MODULE_PATH
DEFAULT_MODULE_UTILS_PATH
DEFAULT_CACHE_PLUGIN_PATH
DEFAULT_FILTER_PLUGIN_PATH

샘플 환경 변수:

ANSIBLE_LIBRARY
ANSIBLE_MODULE_UTILS
ANSIBLE_CACHE_PLUGINS
ANSIBLE_FILTER_PLUGINS

5. Ansible 배포판의 일부로 제공되는 표준 디렉토리

사용자 지정 디렉토리의 모듈, 모듈 유틸리티 및 플러그인은 표준 버전보다 우선한다. 여기에는 일반적인 이름을 가진 몇 파일이 포함된다. 예를 들어, basic.py라는 이름을 가진 파일이 사용자 지정 디렉토리에 존재한다면 표준인 ansible.module_utils.basic를 덮어쓴다.

각기 다른 사용자 지정 디렉토리 내에 같은 이름을 가진 두 개 이상의 모듈, 모듈 유틸리티, 플러그인이 있다면, 커멘드 라인에서의 커멘드 순서와 각 플레이 내에서 포함하는 것과 role의 순서는 특정한 플레이를 찾고 사용하는 일에 영향을 준다.