용어집
용어집 (Glossary)
Ansible 문서 곳곳에서 쓰이는 용어 정의를 모아 다시 설명한 목록이에요. 전체 문서와 용어가 쓰인 맥락을 보려면 문서 홈페이지를 참고하되, 이 페이지는 Ansible 구성 요소에 대한 지식을 점검하고 그것들이 어떻게 맞물리는지 이해하기 좋은 자료예요. Ansible Forum에 용어가 등장할 때 복습용으로 읽어 보면 좋아요.
출처: 문서
본문
다음은 Ansible 문서에서 다른 곳에 쓰이는 용어 정의를 모은 목록(및 재설명)이에요.
액션 (Action)
액션은 태스크의 한 부분으로, 어떤 모듈을 실행할지와 그 모듈에 어떤 인자를 전달할지를 지정해요. 각 태스크는 액션을 하나만 가질 수 있지만, 다른 매개변수는 여러 개 가질 수 있어요.
임시 명령 (Ad Hoc)
오케스트레이션 언어인 /usr/bin/ansible-playbook 대신 /usr/bin/ansible을 사용해 신속한 명령을 수행하도록 Ansible을 실행하는 것을 말해요. 임시 명령의 예로 인프라의 50대 머신을 재부팅하는 것을 들 수 있어요. 임시로 할 수 있는 모든 것은 플레이북을 작성해서도 해낼 수 있고, 플레이북은 여러 다른 작업을 서로 묶을 수도 있어요.
Ansible (패키지)
ansible-core와 선별된 컬렉션 그룹을 포함하는 소프트웨어 패키지(Python, deb, rpm 등)예요. Ansible 2.9에서 동작했던 플레이북은 Ansible 2.10 패키지에서도 동작해야 해요. Ansible에 포함된 컬렉션 목록과 포함된 ansible-core 버전은 ansible-build-data의 릴리스별 디렉토리에 있는 ansible-<version>.build 파일을 참고하세요.
ansible-base
2.10에서만 사용되는 이름이에요. ansible/ansible 저장소에서 생성된 설치 가능한 패키지(RPM/Python/Deb 패키지)예요. ansible-core를 참고하세요.
ansible-core
2.11부터 쓰이는 이름이에요. ansible/ansible 저장소에서 생성된 설치 가능한 패키지(RPM/Python/Deb 패키지)예요. 커맨드라인 도구와 모듈 코드를 관리 노드로 복사하는 것 같은 기본 기능·함수의 코드를 포함해요. ansible-core 패키지는 몇 가지 모듈·플러그인을 포함하며, 컬렉션을 설치해 다른 모듈을 추가할 수 있게 해줘요.
Ansible Galaxy
Ansible 커뮤니티 콘텐츠를 찾고 공유하기 위한 온라인 배포 서버로, 때로 커뮤니티 Galaxy라고도 불러요. 또한 사용자가 개별 Ansible 컬렉션을 설치하게 해주는 커맨드라인 유틸리티를 뜻하기도 해요. 예: ansible-galaxy collection install community.crypto.
Async (비동기)
완료를 기다리는 대신 백그라운드에서 실행되도록 구성된 태스크를 말해요. SSH 타임아웃보다 오래 실행될 긴 프로세스가 있다면 그 태스크를 async 모드로 실행하는 것이 합리적이에요. async 모드는 몇 초마다 완료를 폴링하거나 'fire and forget' 방식으로 구성해 Ansible이 태스크를 다시 확인하지 않고 그냥 시작하고 다음 단계로 진행하게 할 수 있어요. async 모드는 /usr/bin/ansible과 /usr/bin/ansible-playbook 양쪽에서 동작해요.
콜백 플러그인 (Callback Plugin)
Ansible의 결과를 가로채서 무언가를 하는 사용자 작성 코드를 말해요. GitHub 프로젝트의 몇 가지 제공 예시는 커스텀 로깅, 이메일 발송, 심지어 사운드 효과 재생까지 수행해요.
체크 모드 (Check Mode)
--check 옵션으로 Ansible을 실행하는 것을 말해요. 원격 시스템에서 어떤 변경도 하지 않고, 이 플래그 없이 명령을 실행했다면 발생했을 변경 사항만 출력해요. 다른 시스템의 이른바 '드라이 런(dry run)' 모드와 유사해요. 다만 예상하지 못한 명령 실패나 연쇄 효과를 고려하지 않는다는 점(다른 시스템의 유사 모드에서도 마찬가지)을 알아두세요. 무엇이 발생할지 감을 잡는 데는 쓰되, 좋은 스테이징 환경을 대신하지는 마세요.
컬렉션 (Collection)
플러그인, 롤, 모듈 등을 포함하는 Ansible 콘텐츠를 번들링하고 배포하기 위한 패키징 포맷이에요. 컬렉션은 다른 컬렉션이나 ansible-core와 독립적으로 릴리스되어 기능을 더 빨리 사용자에게 제공할 수 있어요. 일부 컬렉션은 Ansible(버전 2.10 이상)에 패키징돼요. 다른 컬렉션(또는 다른 버전의 컬렉션)은 ansible-galaxy collection install <namespace.collection>으로 설치할 수 있어요.
컬렉션 이름 (Collection name)
정규화된 컬렉션 이름(Fully Qualified Collection Name)의 두 번째 부분이에요. 컬렉션 이름은 컬렉션 네임스페이스를 나누며 보통 그 컬렉션 콘텐츠의 기능을 반영해요. 예를 들어 cisco 네임스페이스에는 Cisco가 유지보수하는 여러 네트워크 장치를 관리하는 콘텐츠를 담은 cisco.ios, cisco.aci, cisco.nxos가 있을 수 있어요.
community.general (컬렉션)
Ansible 커뮤니티 팀이 관리하는 특별한 컬렉션으로, Ansible 2.9에 포함되어 있었지만 전용 컬렉션이 없는 모든 모듈·플러그인을 담아요. Galaxy에서 community.general을 참고하세요.
community.network (컬렉션)
community.general와 비슷하지만 네트워크 콘텐츠에 초점을 둔 컬렉션이에요. Galaxy에서 community.network를 참고하세요.
연결 플러그인 (Connection Plugin)
기본적으로 Ansible은 플러그형 라이브러리를 통해 원격 머신과 통신해요. Ansible은 네이티브 OpenSSH(SSH(Native)) 또는 paramiko라는 Python 구현을 사용해요. 최신 버전을 쓴다면 OpenSSH가 선호되며 Kerberos, 점프 호스트 같은 기능도 활성화해요. 이것은 시작하기 섹션에서 다뤄요. accelerate 모드처럼 SSH 기반 연결 타입 중 하나로 부트스트랩되어야 하지만 매우 빠른 다른 연결 타입과, 로컬 시스템에서 동작하는 local 모드도 있어요. 사용자가 자신의 연결 플러그인을 작성할 수도 있어요.
조건문 (Conditionals)
true나 false로 평가되어 주어진 태스크가 주어진 머신에서 실행될지 결정하는 표현식이에요. Ansible의 조건문은 'when' 문으로 구동되며, 플레이북 다루기 문서에서 다뤄요.
선언적 (Declarative)
그 상태를 달성하기 위해 필요한 단계의 순서에 대한 설명이라기보다 최종 상태에 대한 설명을 사용해 작업을 수행하는 접근 방식이에요. 실제 예로, 선언적 작업 명세는 "나를 캘리포니아에 둬"일 거예요. 현재 위치에 따라 캘리포니아에 가기 위한 단계 순서는 다를 수 있고, 이미 캘리포니아에 있다면 아무것도 할 필요가 없어요. Ansible의 리소스는 선언적이에요. 최종 상태를 달성하는 데 필요한 단계를 Ansible이 알아내요. 또한 최종 상태에 도달하기 위해 단계를 밟아야 했는지도 알려줘요.
디프 모드 (Diff Mode)
--diff 플래그를 Ansible에 전달하면 이것을 지원하는 모듈에서 무엇이 바뀌었는지 보여줄 수 있어요. --check와 결합하면 좋은 '드라이 런'이 돼요. 파일 디프는 보통 unified diff 형식이에요.
배포 서버 (Distribution server)
Ansible Galaxy나 Red Hat Automation Hub처럼 컬렉션을 배포하고 다른 사람들이 그 컬렉션에 접근하게 하는 서버예요. 배포 서버 유형 목록은 '컬렉션 배포하기' 문서를 참고하세요. 일부 Ansible 기능은 특정 배포 서버에서만 사용할 수 있어요.
실행기 (Executor)
/usr/bin/ansible의 직접적인 동력원이 되는 Ansible의 핵심 소프트웨어 구성 요소로, 플레이북의 각 태스크 호출에 대응해요. Executor는 Ansible 개발자가 이야기하는 것이지 실제 사용자 층의 어휘는 아니에요.
팩트 (Facts)
팩트는 원격 노드에 대해 발견된 것을 뜻해요. 변수처럼 플레이북과 템플릿에서 쓸 수 있지만, 팩트는 설정된 것이 아니라 추론된 것이에요. 팩트는 play 실행 시 Ansible이 원격 노드에서 내부 setup 모듈을 실행해 자동으로 발견해요. setup 모듈을 명시적으로 호출할 필요는 없어요. 그냥 실행되니까요. 하지만 필요 없다면 시간 절약을 위해 비활성화하거나 gather_subset: 옵션으로 전체 팩트 중 일부만 수집하도록 Ansible에 지시할 수 있어요. 다른 구성 관리 시스템에서 넘어온 사용자의 편의를 위해, 팩트 모듈은 ohai와 facter 도구가 설치되어 있으면 그 팩트도 가져와요. 이것들은 각각 Chef와 Puppet의 팩트 라이브러리예요. (gather_subset:으로 비활성화할 수도 있어요.)
필터 플러그인 (Filter Plugin)
대부분의 사용자가 이해할 필요가 없는 플러그인이에요. 새로운 Jinja2 필터를 만들 수 있게 해주며, Jinja2 필터가 무엇인지 아는 사람들에게만 거의 유용해요. 필요하다면 API 문서 섹션에서 작성법을 배울 수 있어요.
포크 (Forks)
Ansible은 원격 노드와 병렬로 통신해요. 병렬성 수준은 --forks를 전달하거나 설정 파일에서 기본값을 편집해 설정할 수 있어요. 기본값은 매우 보수적인 5 포크지만, RAM이 많다면 병렬성을 높이기 위해 50 같은 값으로 쉽게 설정할 수 있어요.
정규화된 컬렉션 이름 (Fully Qualified Collection Name, FQCN)
컬렉션 안에서 호스팅되는 모듈·플러그인·롤의 완전한 정의로, <namespace.collection.content_name> 형태예요. 플레이북이 특정 원천의 특정 모듈·플러그인을 모호함 없이 참조하게 해줘요. 예: community.grafana.grafana_dashboard. FQCN은 플러그인의 정확한 원천을 지정하고 싶을 때 필요해요. 예를 들어 여러 컬렉션에 user라는 모듈 플러그인이 있다면, FQCN이 주어진 태스크에 어느 것을 사용할지 지정해요. 여러 컬렉션을 설치했을 때 FQCN은 각 태스크에 올바른 플러그인을 검색할 컬렉션을 알려주는 명시적이며 권위 있는 표시기예요.
팩트 수집 (Gather Facts, 불리언)
팩트는 위에서 언급했어요. 다중 play 플레이북을 실행할 때, 어떤 play가 이 값들을 전혀 활용하지 않는다면 팩트 연산에 신경 쓰지 않는 것이 바람직할 때가 있어요. 플레이북에서 gather_facts: False를 설정하면 이 암묵적인 팩트 수집을 건너뛸 수 있어요.
글로빙 (Globbing)
호스트 이름이나 속한 그룹 이름이 아니라 와일드카드를 기반으로 여러 호스트를 선택하는 방법이에요. 예를 들어 www*로 www로 시작하는 모든 호스트를 매칭할 수 있어요. 이 개념은 Ansible 창립자 중 한 명인 Michael DeHaan의 초기 프로젝트인 Func에서 직접 가져온 것이에요. 기본 글로빙 외에도 '이 그룹에 있지만 저 그룹에는 없는 호스트' 같은 다양한 집합 연산도 가능해요.
그룹 (Group)
함께 편리하게 대상으로 삼을 수 있는 풀(pool)에 할당된 여러 호스트로 구성되며, 공통으로 공유하는 변수를 부여받을 수 있어요.
그룹 변수 (Group Vars)
group_vars/ 파일은 인벤토리 파일 옆 디렉토리에 있으며 각 그룹 이름을 딴 선택적 파일 이름을 가져요. 주어진 그룹에 제공되는 변수, 특히 복잡한 데이터 구조를 두기에 편리한 곳이에요. 그래서 그 변수들을 인벤토리 파일이나 플레이북에 포함하지 않아도 돼요.
핸들러 (Handlers)
핸들러는 Ansible 플레이북의 일반 태스크(태스크 참고)와 같지만, 태스크가 notify 키워드를 포함하면서 무언가 변경했다는 것을 나타낼 때만 실행돼요. 예를 들어 설정 파일이 변경되면 설정 파일 템플릿 작업을 참조하는 태스크가 서비스 재시작 핸들러를 알릴(notify) 수 있어요. 이는 서비스를 재시작해야 할 때만 재시작한다는 뜻이에요. 핸들러는 서비스 재시작 외의 것에도 쓸 수 있지만, 서비스 재시작이 가장 흔한 용법이에요.
호스트 (Host)
호스트는 간단히 Ansible이 관리하는 원격 머신이에요. 개별 변수를 할당받을 수 있고 그룹으로도 조직될 수 있어요. 모든 호스트는 도달할 수 있는 이름(IP 주소 또는 도메인 이름)과, 기본 SSH 포트로 접근하지 않는다면 선택적으로 포트 번호를 가져요.
호스트 지정자 (Host Specifier)
Ansible의 각 Play는 일련의 태스크(시스템의 롤·목적·순서를 정의)를 시스템 집합에 매핑해요. 각 play의 hosts: 키워드를 흔히 호스트 지정자(hosts specifier)라고 불러요. 하나의 시스템, 많은 시스템, 하나 이상의 그룹, 또는 어떤 그룹에 있지만 다른 그룹에는 명시적으로 없는 호스트들을 선택할 수 있어요.
호스트 변수 (Host Vars)
그룹 변수와 마찬가지로, 인벤토리 파일 옆의 host_vars/ 디렉토리가 인벤토리 파일의 각 호스트 이름을 딴 YAML 형식 파일을 담을 수 있어요. 인벤토리 파일에 포함하지 않고 호스트에 변수를 할당하기에 편리한 곳이에요. 호스트 변수 파일은 인벤토리 파일에서 표현할 수 없는 복잡한 데이터 구조를 정의하는 데도 쓸 수 있어요.
멱등성 (Idempotency)
어떤 연산을 한 번 수행한 결과가 중간 조치 없이 반복적으로 수행한 결과와 정확히 같다면 그 연산은 멱등적(idempotent)이에요.
인클루드 (Includes)
플레이북 파일(본질적으로 play의 목록일 뿐)이 다른 play 목록을 포함할 수 있고, 태스크 목록이 다른 파일의 태스크 목록을 외부화할 수 있으며, 핸들러도 마찬가지라는 개념이에요. 인클루드는 매개변수화할 수 있는데, 이는 로드된 파일이 변수를 전달할 수 있다는 뜻이에요. 예를 들어 WordPress 블로그를 설정하기 위한 포함된 play가 user라는 매개변수를 받을 수 있고, 그 play를 여러 번 포함해 alice와 bob 양쪽의 블로그를 만들 수 있어요.
인벤토리 (Inventory)
Ansible의 호스트와 그룹을 설명하는 파일(기본적으로 Ansible은 간단한 INI 형식을 사용)이에요. 인벤토리는 인벤토리 스크립트(때로 '외부 인벤토리 스크립트'라고도 함)를 통해서도 제공될 수 있어요.
인벤토리 스크립트 (Inventory Script)
SQL 데이터베이스, CMDB 솔루션 또는 LDAP 같은 외부 리소스에서 호스트, 호스트의 그룹 멤버십, 변수 정보를 조회하는 아주 간단한(또는 복잡한) 프로그램이에요. 이 개념은 Puppet에서 가져온 것으로('외부 노드 분류기'라고 불림), 거의 똑같은 방식으로 동작해요.
Jinja2
Jinja2는 Ansible의 template 모듈이 선호하는 템플릿 언어예요. 일반적으로 읽을 수 있고 작성하기 쉬운 매우 간단한 Python 템플릿 언어예요.
JSON
Ansible은 원격 모듈의 반환 데이터에 JSON을 사용해요. 이는 모듈을 Python뿐만 아니라 어떤 언어로든 작성할 수 있게 해줘요.
키워드 (Keyword)
Ansible을 구성하는 주요 표현으로, 플레이북 객체(Play, Block, Role, Task)에 적용돼요. 예를 들어 'vars:'는 적용된 플레이북 객체의 범위에서 변수를 정의하게 해주는 키워드예요.
지연 평가 (Lazy Evaluation)
일반적으로 Ansible은 플레이북 콘텐츠의 변수를 가능한 마지막 순간에 평가해요. 이는 데이터 구조를 정의하면 그 구조 자체가 그 안에 변수 값을 정의할 수 있고, 모든 것이 기대한 대로 '그냥 동작'한다는 뜻이에요. 또한 변수 문자열이 그 안에 다른 변수를 포함할 수 있다는 뜻이기도 해요.
라이브러리 (Library)
/usr/bin/ansible 또는 Ansible 플레이북에서 사용할 수 있게 된 모듈의 모음이에요.
그룹 제한 (Limit Groups)
ansible 또는 ansible-playbook에 --limit somegroup을 전달하면 명령을 호스트의 일부로 제한할 수 있어요. 예를 들어 보통 전체 서버 집합을 대상으로 하는 플레이북을 특정 서버 하나에서 실행하는 데 쓸 수 있어요.
로컬 액션 (Local Action)
이 키워드는 delegate_to: localhost의 별칭이에요. 액션을 원격에서 컨트롤 노드 자체에서 실행하도록 리다이렉트하고 싶을 때 사용해요.
로컬 연결 (Local Connection)
플레이북에서 connection: local을 쓰거나 /usr/bin/ansible에 -c local을 전달하면 원격 머신 대신 로컬 포크를 실행한다는 뜻이에요. 이는 실행 컨텍스트의 다른 부분을 바꾸지 않고 연결만 바꾸므로, 아마 local_action이나 delegate_to: localhost를 쓰고 싶을 거예요.
룩업 플러그인 (Lookup Plugin)
룩업 플러그인은 외부 세계에서 Ansible로 데이터를 가져오는 방법이에요. 룩업 플러그인은 Jinja2의 확장이며 템플릿에서 접근할 수 있어요. 예: {{ lookup('file','/path/to/file') }}. with_items 같은 것이 이런 식으로 구현되어요. 파일에서 데이터를 로드하는 file 같은 룩업 플러그인과 환경 변수, DNS 텍스트 레코드, 키-값 저장소를 쿼리하는 룩업 플러그인도 있어요.
루프 (Loops)
일반적으로 Ansible은 프로그래밍 언어가 아니에요. 더 선언적이기를 선호하지만, loop 같은 다양한 구조로 특정 태스크를 목록의 여러 항목에 대해 반복할 수 있어요. yum, apt 같은 일부 모듈은 실제로 목록을 직접 받아 단일 트랜잭션에서 그 목록에 주어진 모든 패키지를 설치할 수 있어 전체 구성 시간을 크게 단축하므로, 루프 없이 사용할 수 있어요.
모듈 (Modules)
모듈은 Ansible이 원격 머신으로 보내는 작업 단위예요. 모듈은 /usr/bin/ansible 또는 /usr/bin/ansible-playbook(여기서 여러 태스크가 여러 다른 모듈을 함께 사용)에 의해 시작돼요. 모듈은 Perl, Bash, Ruby를 포함한 어떤 언어로도 구현될 수 있지만, Python으로 작성하면 유용한 공용 라이브러리 코드를 활용할 수 있어요. 모듈은 JSON을 반환하기만 하면 돼요. 원격 머신에서 실행된 후에는 제거되므로 오래 실행되는 데몬을 사용하지 않아요. Ansible은 사용 가능한 모듈의 집합을 라이브러리라고 부르기도 해요.
멀티 티어 (Multi-Tier)
IT 시스템이 한 번에 하나씩 관리되는 것이 아니라, 잘 정의된 순서로 여러 시스템과 시스템 그룹 간의 상호작용으로 관리된다는 개념이에요. 예를 들어 웹 서버는 데이터베이스 서버보다 먼저 업데이트되어야 할 수 있고, 웹 서버의 일부는 그 데이터베이스 서버 이후에 업데이트되어야 하며, 다양한 로드 밸런서와 모니터링 서버에도 연락해야 할 수 있어요. Ansible은 '한 번에 하나의 시스템' 관점이 아니라 전체 IT 토폴로지와 워크플로우를 모델링해요.
네임스페이스 (Namespace)
정규화된 컬렉션 이름의 첫 번째 부분으로, 보통 기능적 콘텐츠 카테고리를 반영해요. 예: cisco.ios.ios_config에서 cisco가 네임스페이스예요. 네임스페이스는 Red Hat이 자체 재량으로 예약·배포해요. 많은(전부는 아니지만) 네임스페이스가 벤더 이름과 대응돼요. 네임스페이스 요구 사항은 Galaxy 문서 사이트의 Galaxy namespaces를 참고하세요.
Notify (알림)
태스크가 변경 이벤트를 등록하고, play 끝에 다른 액션을 실행해야 한다고 핸들러 태스크에 알리는 행위예요. 여러 태스크가 핸들러에 알리더라도 핸들러는 한 번만 실행돼요. 핸들러는 알림받은 순서가 아니라 나열된 순서로 실행돼요.
오케스트레이션 (Orchestration)
많은 소프트웨어 자동화 시스템이 이 단어를 서로 다른 의미로 사용해요. Ansible은 지휘자가 오케스트라를 지휘하듯 사용해요. 데이터센터나 클라우드 아키텍처는 많은 역할을 연주하는 많은 시스템으로 가득해요 – 웹 서버, 데이터베이스 서버, 어쩌면 로드 밸런서, 모니터링 시스템, 지속적 통합 시스템 등. 어떤 프로세스를 수행하려면 롤링 업데이트를 시뮬레이션하거나 소프트웨어를 올바르게 배포하기 위해 특정 순서로 시스템을 접촉해야 하는 경우가 많아요. 어떤 시스템이 몇 가지 단계를 수행하고, 그다음 다른 시스템들, 그러고 나서 이미 처리된 이전 시스템이 더 많은 단계를 수행해야 할 수도 있어요. 그 과정에서 이메일을 보내거나 웹 서비스에 연락해야 할 수도 있어요. Ansible 오케스트레이션은 바로 그런 종류의 프로세스를 모델링하는 것입니다.
paramiko
Ansible은 paramiko라는 Python SSH 구현을 사용할 수 있어요. paramiko 라이브러리는 일반적으로 빠르고 관리하기 쉬워요. paramiko를 사용하려면 플레이북에서 연결 타입을 지정하거나 -c paramiko 플래그를 사용해야 해요.
플레이북 (Playbooks)
플레이북은 Ansible이 시스템을 오케스트레이션·구성·관리·배포하는 언어예요. 부분적으로는 스포츠 비유이기 때문에, 그리고 사용하기에 재미있어야 한다고 생각하기 때문에 플레이북이라고 불러요. 워크북이 아니에요 :)
플레이 (Plays)
플레이북은 play의 목록이에요. play는 최소한 호스트 지정자(보통 그룹으로 선택되지만 때로 호스트 이름 글로브로 선택)가 선택한 호스트 집합과, 그 시스템들이 수행할 롤을 정의하기 위해 그 호스트들에서 실행되는 태스크 사이의 매핑이에요. 플레이북에는 하나 또는 여러 개의 play가 있을 수 있어요.
풀 모드 (Pull Mode)
기본적으로 Ansible은 푸시 모드로 실행되며, 각 시스템과 통신하는 시기를 매우 세밀하게 제어할 수 있어요. 풀 모드는 노드들이 특정 일정에 따라 매 N분마다 체크인하게 하고 싶을 때 제공돼요. ansible-pull이라는 프로그램을 사용하며 푸시 모드 플레이북으로도 설정(또는 재구성)할 수 있어요. 대부분의 Ansible 사용자는 푸시 모드를 사용하지만, 풀 모드는 선택의 여지가 있도록 포함되어 있어요.
ansible-pull은 crontab의 Git에서 구성 순서를 체크아웃한 다음 로컬 연결 플러그인을 사용해 머신을 로컬에서 관리하는 방식으로 동작해요.
Pulp 3 Galaxy
GalaxyNG 코드베이스를 기반으로 한 자체 호스팅 배포 서버로, Pulp 버전 3에 기반해요. 자신이 큐레이션한 콘텐츠 집합을 찾고 공유하는 데 사용해요. ansible-galaxy collection 명령으로 콘텐츠에 접근할 수 있어요.
푸시 모드 (Push Mode)
푸시 모드는 Ansible의 기본 모드예요. 사실 이것은 모드라기보다는 Ansible에 대해 생각하지 않을 때 Ansible이 동작하는 방식 그 자체예요. 푸시 모드는 Ansible이 세밀하게 동작하고, 노드가 체크인하기를 기다리지 않고 복잡한 오케스트레이션 프로세스로 노드를 이끌 수 있게 해줘요.
레지스터 변수 (Register Variable)
Ansible에서 어떤 태스크를 실행한 결과를 변수에 저장해 템플릿이나 조건문에서 사용할 수 있어요. 변수를 정의하는 데 쓰는 키워드는 register로, 어셈블리 프로그래밍의 레지스터 개념에서 이름을 따왔어요(Ansible이 어셈블리 프로그래밍처럼 느껴지진 않겠지만요). 등록에 쓸 수 있는 변수 이름은 무한히 많아요.
리소스 모델 (Resource Model)
Ansible 모듈은 리소스 단위로 동작해요. 예를 들어 file 모듈은 특정 파일을 선택해 그 리소스의 속성이 특정 모델과 일치하도록 보장해요. 예를 들어 /etc/motd의 소유자를 아직 root가 아니라면 root로 바꾸거나, 모드를 아직 0644가 아니라면 0644로 설정하고 싶을 수 있어요. 리소스 모델은 멱등적이라 변경 명령이 필요할 때만 실행되고, Ansible은 시스템을 원하는 상태로 되돌리며 실제 상태를 알 필요가 없어요. 그 상태에 어떻게 도달할지 말할 필요가 없죠.
롤 (Roles)
롤은 Ansible에서 조직의 단위예요. 호스트 그룹(또는 그룹 집합, 호스트 패턴 등)에 롤을 할당하면 그들이 특정 동작을 구현해야 한다는 뜻이에요. 롤은 특정 변수 값, 특정 태스크, 특정 핸들러를 적용하는 것을 포함할 수 있고, 그중 하나 이상만 포함할 수도 있어요. 롤과 연관된 파일 구조 덕분에 롤은 플레이북 간에, 심지어 다른 사용자와도 동작을 공유할 수 있는 재배포 가능한 단위가 돼요.
롤링 업데이트 (Rolling Update)
그룹의 노드 여러 개를 한 번에 N개씩 처리해서 모두 동시에 업데이트해 시스템을 오프라인 상태로 만드는 것을 피하는 행위예요. 예를 들어 매우 큰 트래픽을 처리하는 500개 노드의 웹 토폴로지에서 한 번에 1020대씩 업데이트하고 완료되면 다음 1020대로 넘어가는 것이 합리적일 수 있어요. Ansible 플레이북의 serial: 키워드가 롤링 업데이트 풀의 크기를 제어해요. 기본값은 배치 크기를 모두 한 번에 처리하는 것이므로, 이는 명시적으로 선택해야 해요. OS 구성(설정 파일이 올바른지 확인하는 것 같은)은 보통 롤링 업데이트 모델을 쓸 필요가 없지만, 원한다면 쓸 수 있어요.
Serial (시리얼)
롤링 업데이트 문서를 참고하세요.
Sudo
Ansible은 루트 로그인을 요구하지 않으며, 데몬이 없기 때문에 확실히 루트 레벨 데몬(민감한 환경에서 보안 우려가 될 수 있음)을 요구하지 않아요. Ansible은 로그인해 sudo 명령으로 감싼 많은 작업을 수행할 수 있고, 암호 없는 sudo와 암호 기반 sudo 모두와 동작해요. sudo와 함께 보통 동작하지 않는 일부 작업(예: scp 파일 전송)은 sudo 모드에서 실행하면서 Ansible의 copy, template, fetch 모듈로 달성할 수 있어요.
SSH (네이티브)
Ansible 전송으로서의 네이티브 OpenSSH는 -c ssh(또는 설정 파일, 플레이북 키워드)로 지정하며, Kerberized SSH로 로그인하거나 SSH 점프 호스트를 쓰고 싶을 때 유용해요. 1.2.1에서 컨트롤 머신의 OpenSSH 바이너리가 충분히 새 버전이라면 ssh가 기본으로 사용돼요. 이전에는 Ansible이 paramiko를 기본으로 선택했어요. 최대 성능을 위해 ControlMaster와 ControlPersist를 지원하는 클라이언트를 쓰는 것이 권장돼요. 그게 없고 Kerberos, 점프 호스트 같은 기능이 필요 없다면 paramiko가 좋은 선택이에요. Ansible은 ControlMaster/ControlPersist 기능을 감지하지 못하면 경고할 거예요.
태그 (Tags)
Ansible은 플레이북의 리소스에 임의의 키워드로 태그를 달고, 그 키워드에 해당하는 플레이북 부분만 실행하게 할 수 있어요. 예를 들어 전체 OS 구성을 가지면서 특정 단계에 ntp라고 레이블을 붙이고, ntp 단계만 실행해 원격 호스트의 시간 서버 정보를 재구성할 수 있어요.
태스크 (Task)
플레이북은 태스크를 실행하기 위해 존재해요. 태스크는 액션(모듈과 그 인자)을 이름과 결합하고, 선택적으로 루프 키워드 같은 다른 키워드와 결합해요. 핸들러도 태스크지만, 태스크가 원격 시스템의 근본적인 변경을 보고할 때 이름으로 알림받지 않으면 실행되지 않는 특별한 종류의 태스크예요.
Tasks (태스크 목록)
태스크(Task)의 목록이에요.
템플릿 (Templates)
Ansible은 파일을 원격 시스템으로 쉽게 전송할 수 있지만, 다른 파일에서 변수를 치환하는 것이 바람직할 때가 많아요. 변수는 인벤토리 파일, 호스트 변수, 그룹 변수 또는 팩트에서 올 수 있어요. 템플릿은 Jinja2 템플릿 엔진을 사용하며 루프와 if 문 같은 논리 구조도 포함할 수 있어요.
전송 (Transport)
Ansible은 연결 플러그인을 사용해 사용 가능한 전송 유형을 정의해요. 이것은 Ansible이 관리 시스템에 어떻게 연락할지에 불과해요. 포함된 전송은 paramiko, ssh(OpenSSH 사용), local이에요.
When
태스크에 붙는 선택적 조건문으로, 태스크를 실행할지 여부를 결정하는 데 사용돼요. when: 키워드 뒤의 표현식이 false로 평가되면 태스크는 무시돼요.
Vars (변수)
팩트와 달리 변수는 값의 이름이에요(정수, 불리언, 문자열 같은 단순 스칼라 값이거나, 딕셔너리/해시, 목록 같은 복잡한 값). 템플릿과 플레이북에서 사용할 수 있어요. 변수는 선언된 것이며, 원격 시스템의 현재 상태나 본성에서 추론된 것이 아니에요(그것이 팩트예요).
YAML
Ansible은 사람들이 인프라를 자동화하기 위해 프로그래밍 언어 코드를 작성하도록 강요하고 싶지 않아서, YAML을 사용해 플레이북 구성 언어와 변수 파일을 정의해요. YAML은 문법이 최소이고 매우 깨끗하며 사람이 훑어보기 쉬워서 좋아요. 설정 파일과 사람에게 좋은 데이터 형식이지만 기계도 읽을 수 있어요. Ansible의 YAML 사용은 Michael DeHaan이 2006년경 Cobbler 안에서 처음 사용한 것에서 비롯됐어요. YAML은 동적 언어 커뮤니티에서 꽤 인기 있고, 많은 언어(Python, Perl, Ruby 등)에 직렬화 라이브러리가 있는 형식이에요.
더 알아보기 (Learn more)
- 자주 묻는 질문은 FAQ 문서를 확인해요.
- 플레이북에 대한 소개는 플레이북 다루기 문서를 확인해요.
- 플레이북 팁과 요령은 Ansible 팁과 요령 문서를 확인해요.
- 질문이나 도움이 필요하면 Ansible 커뮤니케이션 가이드를 방문해 보세요.