728x90
반응형
앤서블 이란?
오픈소스 기반 Provisioning & Configuration management Tools And IT Automation Tool
Ansible은 IT 자동화를 위한 오픈소스 기반 도구이며,
풍부한 모듈을 바탕으로 보다 손쉽고 빠르게 목표하는 일 또는 업무를 자동화할 수 있는 수단을 제공한다.
아래의 기능들을 중앙 서버에서 원격 조작 & 자동화 가능함.
특징
Provisioning : 요구에 맞게 시스템 자원을 할당/배치 해두어 즉시 사용할 수 있는 상태로 준비
- Package/SW 설치
- 구성/설정 변경
- File 전송, 배포
Configuration : 구성,적용
- 보안 적용, 패치
- Service 시작과 종료, 각종 Service와 Demon 관리
- 상태 파악과 확인
- Batch 처리
- Update 실행
Orchestration : Provisiong, Configuration 을 다 얹어서 한번에 주는것을 뜻함.
- 서버, 네트워크, 서비스, 로드 밸런스, 방화벽 설정 및 배포, 작업 등을 자동화
- Server / Router / Switch / FW / Load Balancer / Storage / Database / Cloud etc…
Monitoring
Reporting
Gathering (시스템 정보 모으기)
Ansible Architecture
하나의 제어 노드(Server)에서 여러 관리 노드(Client) 를 관리하는 구조
Managed Node와의 통신은 SSH (Secure Shell)을 통해서 이루어진다.
- 제어 노드 (Control Node)
Ansible이 설치된 모든 머신을 뜻한다.
Python이 설치된 모든 컴퓨터를 제어 머신으로 사용 가능하며, 여러 개의 제어노드 가질 수 있다.
명령어나 Playbook 실행 가능하다.
/usr/bin/ansible 또는 /usr/bin/ansible-playbook를 호출하여 실행한다. - 관리 노드 (Managed Node)
Ansible로 관리하는 장치들이다.
| 항목 | 설명 |
| Inventory | 자동화 대상 (Managed Node) 목록을 작성하는 곳이다. |
| Playbook | 자동화 코드 Set 을 의미한다. 순서가 있는 작업 목록을 반복적으로 실행 가능하다. |
| Module | 자동화 기능 내장 패키지로 하나의 완전한 단위 기능 제공한다. |
| API | Ansible python API 를 사용하여 노드를 제어하고, Ansible 을 확장 하여 다양한 Python 이벤트에 응답하고, 다양한 플러그인을 작성할 수 있으며, 플러그를 연결가능 |
| Plugin | Ansible의 핵심 기능 을 보강하는 코드 조각이다. Ansible 은 플러그인 아키텍처를 사용하여 풍부하고 유연하며 확장 가능한 기능 세트를 활성화 |
Design Goals
- Minimal In Nature
관리 시스템은 환경에 대한 추가 종속성을 부과해서는 안됩니다. - Consistent
Ansible을 사용하면 일관된 환경을 만들 수 있어야합니다. - Secure
Ansible은 에이전트를 노드에 배포하지 않습니다. 오직 OpenSSH와 파이썬만 관리 노드에 필요합니다.
→ (Agentless) - Highly Reliable
Ansible 플레이 북은 멱등성을 가지므로 관리되는 시스템에서 예기치 않은 부작용을 방지 할 수 있습니다
물론 멱등적일 수 있게 코드를 짜야 멱등성 보장이 됩니다!! - Minimal learning required
배우기 쉽다!!!
플레이 북은 YAML 및 Jinja 템플릿을 기반으로 한 쉽고 설명적인 언어를 사용합니다 .
Ansible 설치 요구사항
- 제어 노드 (Control Node)
OS 요구사항 Linux/Unix Host (Ubuntu, CentOS,SUSE, Redhat, Debian, macOS, BSD, AIX, Oracle Solaris, HPUX 등)
Python2 (2.7이상) or Python 3 (3.5이상)
SSH (22포트)
서버 방화벽 또는 ACL Rule 허용Window 최소 PowerShell 4.0이상 & .NetFramwork 4.0 이상
(3.0버전은 winRM memory hotfix 적용 필요)
WinRM (5986 포트)
서버 방화벽 또는 ACL Rule 허용
Windows 2008 R2 SP1 이상
WinRM 활성화 - 관리 노드 (Managed Node)
OS 요구사항 Linux Python2 (2.6이상) or Python 3 (3.5이상) Unix-like Python 2.4 이상
Python 2.5이전 버전 사용하는 경우 python-simplejson 필요
SSH 인 통신 방법이 필요. 기본적으로 SFTP를 사용합니다.
사용할 수없는 경우 ansible.cfg 에서 SCP로 전환 가능.Window 1.7 버전부터 Ansible로 관리하는 것은 가능,
Window에 Ansible을 설치해서 다른 OS 관리하는 것은 불가능
| 물리 장비 | 서버 | |
| 스토리지 | ||
| 네트워크 | ||
| Cloud | AWX, OpenStack, Azure VMWare, k8s, docker Ansible은 Amazon Web Services , Atomic, CenturyLink , Cloudscale, CloudStack , DigitalOcean , Dimension Data , Docker , Google Cloud Platform , KVM , Linode , LXC , LXD, Microsoft Azure , OpenStack , Oracle Cloud , OVH , oVirt , Packet, Profitbricks, PubNub , Rackspace , Scaleway ,SmartOS , SoftLayer , Univention , VMware , Webfaction 및 XenServer 를 포함한 베어 메탈 호스트, 가상화 된 시스템 및 클라우드 환경에 배포 할 수 있습니다. |
|
| Network | ||
| Applicatoin | ||
Ansible 도입 기대효과
□ 안전성 향상
- 휴먼 에러 방지
- 인력 의존성 탈피
- 모든 변경 이력 관리 가능
- 작업 계획과 운영 환경의 차이 감소
□ 작업 효율 향상
- 대상 서버 수와 상관없이 구축가능, 병렬 실행
- 장시간 작업, 야간 작업에 대한 인력의존성 탈피
- 신속한 릴리즈 작업
□ 다른 툴과 통합하여 자동화와 효율성 향상
- 버전 관리툴(git…)에 의한 순서/설정 관리
- 자동 테스트 툴에 의한 환경 테스트 (serverspec 등)
- 각종 CI(Continuos Integration)툴과의 자동 연계 (Jenkins 등)
- 모니터링 도구와 연계된 장애 대응 자동화 (zabbix, nagios 등)
- Slack 등과 연계해 채팅 베이스에서의 운용 작업 실행
Configuration Management Tool 비교
| Puppet | Chef | Salt | Ansible | |
| 개발사 | Puppet Labs | Opscode | SaltStack | AnsibleWorks |
| 등장 | 2005.08 | 2009.01 | 2011.03 | 2012.03 |
| 개발언어 | Ruby | Ruby(Client) Erlang(Server) |
Python | Python |
| 도입고객 | Google, ebay, Disney... | Facebook Acestry.com.. | Linkedin, HP Cloud... | Evernotes, Rackspace... |
| 정보량 | 많음 | 많음 | 적음 | 보통 |
| 사용량 | 많음 | 많음 | 적음 | 많음 |
| 코드 베이스 | 많음 Puppet Forge |
많음 Chef Supermarket |
적음 Salt-Formula(GIT 베이스) |
보통 Ansible Galaxy |
| Web UI | 많음 Puppet Enterprise |
많음 Chef Manage |
보통 SaltStack Enterprise |
보통 Ansible Tower(유료) AWX (무료, 오픈소스) |
| 정의파일 | 독자DSL 내장 Ruby |
독자DSL (Domain-Specific Language) (Ruby베이스) |
YAML 독자DSL (Python 베이스) |
YAML |
| 통신 방법 | HTTP SSL | REST/STOMP | YAML/JSON | |
| Agent설치 | 필요 | 필요 | 필요or불필요(선택) | 불필요 |
| 간편도 (학습, 저 운용 코스트) |
어려움 | 어려움 | 어려움 | 쉬움 |
| 라이센싱 | 2.7v 이전 GPLv2 이후 Apache-2 |
Apache-2 | Apache-2 | GPLv3 |
기존 관리 방식과 차이점
Push vs Pull Based Configuration Management
| Push Based | Pull Based | |
| 작동 방법 | 서버에서 구성 정보를 노드에 전달하는 방식 | 노드에 설치된 전용Agent가 서버에 접근하여 정보를 가져가는 방식 Agent는 다음을 수행 1. 정기적으로 서버에서 구성 가져 오기 2. 서버에서받은 구성을 노드의 현재 구성과 비교 3. 일치하지 않는 경우 노드 구성을 서버에서 받은 구성과 일치시키는 데 필요한 단계를 수행 |
| 통신 주체 | 서버 | 노드(Client)에 설치된 전용 Agent 혹은 노드 |
| 대표 Tool | Ansible, Salt(대신에 Agent 설치) | Puppet, Chef |
| 장점 | 전체 시스템 제어 더 많은 노드를 제어 가능 즉시 문제 확인하고 수정 가능 사용 편의성 Client에 Agent 설치가 필요없으므로 초기 구성이 매우 편하고 빠름 노드가 서버에서 정보를 가져오지 않기 때문에 노드에서 무언가 실수하는 것을 방지 |
새 노드를 더 쉽게 부트스트랩 노드가 준비되면 즉시 노드에서 실행되는 Agent가 서버에서 정보 가져오므로, 노드를 구성할 준비가 되었는지 확인할 필요가 없다. 더 쉬운 확장성 - 노드는 다른 노드와 독립적으로 부트스트랩 되므로 구성 확장이 훨씬 쉽다. |
| 단점 | 병렬 처리를 한다고는 하나, 병목 현상 발생 가능성 존재 | 각 클라이언트마다 Agent 설치/관리 해주어야 하므로 인프라가 복잡해짐 |
※ 물론 필요하다면 Push ↔ Pull 방식을 바꿔서 구성도 가능하다.
멱등성
□ 멱등성 이란?
- 여러번 적용해도 결과는 바뀌지 않는다.
- 바뀌는 것이 없으면 당연히 배포도어도 바뀌지 않는다.
- 바뀌는 부분이 있으면 그 부분만 반영된다.
□ 반드시 항상 모든 스크립트가 멱등성 제공한다는 뜻이 아님에 주의!!
- 기본 제공하는 ansible 모듈은 대부분 멱등성를 제공하나,
우리가 만든 ansible 스크립트는 멱등성를 제공하지 못할 수 있으므로 멱등성 깨지지 않게 주의
→ shell, command, file module은 멱등성 제공하지 않는 모듈
- Non-Idempotent Bash 예시
echo“127.0.0.1 localhost”>> /etc/hosts
→ /etc/hosts에 항상 내용을 추가함. - Idempotent Bash 예시
If (! grep -q 127.0.0.1 /etc/hosts); then echo“127.0.0.1 localhost”>> /etc/hosts; fi
→ /etc/hosts에 내용이 있으면 추가하지 않음. - linefile 모듈을 사용하여 멱등성 보장하는 예시 (SSH daemon listen on IP Address 1.2.3.4)
name: Listen on 1.2.3.4
lineinfile: dest=/etc/ssh/sshd_config
line=”ListenAddress 1.2.3.4″
insertafter=”^#?AddressFamily”
→ 목표는 SSH 데몬이 우리가 지정한 IP 주소에서만 수신하도록 만드는 것
1) ListenAddrtess 1.2.3.4를 읽지 않는 모든 ListenAddress 항목 제거
2) 그런 다음 특정 위치에 ListenAddress 1.2.3.4 줄을 추가
인벤토리 (Inventory)
| 항목 | 설명 |
| 인벤토리 란? | 관리 노드의 목록을 기술하는 파일 |
| 파일 | 기본 파일 : /etc/ansible/hosts 기본 파일 변경 : ansible-playbook 커맨드의 I 옵션으로 지정 $ ansible-playbook I inventory_file playbook.yml 두개 이상의 인벤토리 파일 사용 : -i 옵션으로 붙인다. ansible-playbook get_logs.yml -i staging -i production |
| 작성 형식 | 인벤토리 플러그인에 따라 여러가지 형식으로 작성될 수 있음. 기본적으로는 INI 또는 YAML 형식으로 쓰인다. INI 형식 : [webservers] foo.example.com bar.example.com YAML 형식 : all: hosts: mail.example.com: children: webservers: hosts: foo.example.com: bar.example.com: |
| Grouping | 그룹을 만들어 관리노드를 묶어줄 수 있다. 하나의 host를 여러 그룹에 포함시킬 수 있으며, 그룹단위로 명령을 내릴 수도 있다. 기본적으로 모든 host는 ‘all’ 이라는 그룹에 모두 포함되며, all을 제외하고 아무 그룹에도 속하지 않는 host는 ‘ungrouped’ 그룹에 속한다. [cisco] rtr1 ansible_host=18.12.12.12 private_ip=172.1.1.1 [arista] rtr2 ansible_host=18.12.12.13 private_ip=172.1.1.1 |
| nested | [routers:children] cisco arista |
| 인벤토리 변수 | Group 변수는 Group 내 모든 Device에 적용된다. [cisco:vars] ansible_user=ec2-user ansible_network_os=ios |
| IP 명시 방법 |
|
변수와 그룹
| 설명 | INI | YAML |
| 호스트 변수 단일 변수에 할당 후 나중에 플레이북에서 사용가능 |
INI host1 http_port=80 maxRequestsPerChild=808 |
... hosts: jumper: ansible_port: 5555 ansible_host: 192.0.2.50 |
| 그룹 변수 Group 내 모든 Device에 적용된다. vars 접미사를 붙여서 만든다. |
[atlanta] host1 host2 [atlanta:vars] ntp_server=ntp.atlanta.example.com proxy=proxy.atlanta.example.com |
atlanta: hosts: host1: host2: vars: ntp_server: ntp.atlanta.example.com proxy: proxy.atlanta.example.com |
| 호스트/그룹 변수 파일 인벤토리에 파일에 작성하지 않고 이러한 파일에 따로 작성해도 된다. /etc/ansible/host_vars/호스트명 /etc/ansible/group_vars/그룹명 /etc/ansible/group_vars/그룹명/하위폴더명 |
사용불가 | --- ntp_server: acme.example.org database_server: storage.example.org |
| 그룹의 그룹 그룹을 다시 그룹으로 묶을 수 있다. children 접미사를 붙여서 만든다. |
[atlanta] host1 host2 [raleigh] host2 host3 [southeast:children] atlanta raleigh [southeast:vars] halon_system_timeout=30 self_destruct_countdown=60 [usa:children] southeast northeast |
all: children: usa: children: southeast: children: atlanta: hosts: host1: host2: raleigh: hosts: host2: host3: vars: halon_system_timeout:30 self_destruct_countdown: 60 northeast: |
모듈 (Module)
| 항목 | 설명 |
| 모듈 이란? | Ansible이 실행하는 코드 단위이다. 자동화 기능 내장 패키지로 하나의 완전한 단위 기능 제공 또한 Ansible은 내장함수가 매우 풍부한 것이 장점 (20년 7월 기준 약 1652개) |
| 실행 방법 | ansible 명령을 사용해서 단일 모듈을 호출 가능 ansible-playbooks 명령을 통해서 여러 모듈 호출 가능 |
| 개발 언어 | 모든 언어를 사용하여 개발 가능 |
| I/O | 입력 : Attributes 로 입력을 전달 받음 출력 : JSON Format을 표준출력(STDOUT)으로 사용 → 단순히 I/O에 국한하지 않고 외부 시스템과의 연동과 같이 Side-Effect 발생시키는 것도 가능. |
| 구현 과정 | 개발환경 구축 1) Ansible Module 이 저장될 library 디렉토리 생성 2) Ansible 프로젝트를 Git 저장소로부터 복제한다. 쉘 환경변수를 import 한다. 모듈 명세 작성 1) 모듈의 속성을 정의하고 속성의 데이터 타입, 필수 여부, 허용 가능한 값, 기본 값 등을 정의합니다. 2) 모듈이 반환할 수 있는 모든 상태 코드를 정의 합니다. 정상 코드 이외의 모든 에러 코드를 반환하는 경우에는 모듈이 수행하기 전과 후의 환경이 동일해야 합니다. (멱등성) 3) 모듈에 입력 받은 속성에 따라 비즈니스 로직을 구현하고, 처리 결과를 JSON Format 생성합니다. 4) 모듈의 모든 처리가 완료되면, exit_json (정상) 혹은 fail_json (실패) 중에 하나를 반환해야 합니다. 테스트 수행 1) test-module cli 툴을 사용하여 모듈을 테스트할 수 있다. |
공식 내장 모듈
쉘스크립트로 작성하면 복잡한 절차가 필요하지만,
Ansible에 내장된 모듈은 사용자가 의식하지 않고도 안전하고 적절한 처리를 실행할 수 있도록 함.
| 기능 | 설명 |
| 파일 처리 | file : 파일 작업 copy, template : 파일 배포 fetch : 파일 수집 lineinfile : 기존 파일을 행 단위로 수정 |
| 서비스 제어 | service : 서비스 시작/정지 등 |
| 패키지 관리 | yum, apt : 지정/의존 패키지 설치 |
| 명령어 실행 모듈 | command, sell : 외부 커맨드 실행과 출력 결과 보고 등 |
Index of all Modules — Ansible Documentation
cisco.aci.aci_domain – Manage physical, virtual, bridged, routed or FC domain profiles (phys:DomP, vmm:DomP, l2ext:DomP, l3ext:DomP, fc:DomP)
docs.ansible.com
플레이북 (Playbook)
| 항목 | 설명 |
| 플레이북 이란? | 반복해서 실행하고자 해당 작업을 실행 순서대로 저장해 놓은 정렬된 작업 리스트 순서가 있는 작업 목록을 반복적으로 실행 가능 Ansible의 환경 설정, 배포가 가능케 함 변수와 작업이 포함될 수 있음. |
| 구성 | 하나 이상의 Play 들로 이루어져 있다. - plays : 서버(그룹)에 대해 정의된 role 들을 실행 시키는 것. 여러 개의 tasks로 이루어짐. - tasks : ansible의 작업 단위 (ad-hoc 명령을 사용하여 단일 작업을 한 번 실행할 수 있다.) - Modules  |
| 정의파일 | YAML 형식으로 작성된다. |
| 기능 | - 반복 (with_item, with nested, until …) - 조건 분기 (when, register, …) - 다른 playbook 참조 (include, role, …) - 외부 정보 참조 - 환경 변수, 파일 등 (environment, lookup, vars_prompt,…) - 커스텀 모듈을 이용한 확장 |
YAML
| 항목 | 설명 |
| YAML이란? | 사람이 쉽게 읽을 수 있는 데이터 직렬화 양식 마크업 보다 구조화 된 데이터 표현을 위한 텍스트 형식의 포맷 |
| 이름의 뜻 | YAML 이라는 이름은 ‘YAML ain’t Markup Language’ (YAML은 마크업 언어가 아니다.) 라는 재귀적인 이름에서 유래되었으나, ‘Yet Another Markup Language’ (또 다른 마크업 언어) 이 현재 공식적인 약자 |
| 확장자 | .yml |
| Json | YAML |
| ‘[ “apple”, { “size”:[“a”,”b”,1] } ]’ |
- apple - size: - a - b - 1 |
YAML Syntax — Ansible Documentation
This page provides a basic overview of correct YAML syntax, which is how Ansible playbooks (our configuration management language) are expressed. We use YAML because it is easier for humans to read and write than other common data formats like XML or JSON.
docs.ansible.com
Ansible 참고 사이트/Tool
□ Ansible Galaxy
Playbook 공유 Hub
코드가 아니라 Playbook을 공유하고, 재사용 & 참고에 매우 유용하다.
TIP
왠만한 기능들은 다 구현되어 있으므로, 새 기능을 만들때 가장 먼저 이곳에서 유사한 Playbook을 들고온 뒤
나에게 필요한 부분을 얹는 방식으로 개발하면 아주 빠르고 신뢰성 있게 개발이 가능함.
Ansible host에서 바로 명령어로 끌어다 사용 가능
Ansible Galaxy
galaxy.ansible.com
□ AWX vs Ansible Tower
- 공통점 : 결론적으로 둘은 동일한 기능을 함
- 차이점 : Ansible Tower가 먼저 상용버전으로 사용되어왔고, AWX는 오픈소스로 풀린지 3년 정도밖에 안됨.
(보통... 벤더사에서 유지보수 비용이 많이 들면 오픈소스로 푼다고한다.
여기서 비용이란? → 많은 Bug들을 Fix하는 등에 드는 비용을 말함.)
 |
Redhat 사에서 제공하는 GUI기반 Ansible 자동화 도구 ‘상용판’ |
 |
오픈소스 GUI 기반 Ansible 자동화 도구 (Free) |
반응형
'인프라 > Ansible' 카테고리의 다른 글
| Infra IT 자동화 Tool - 앤서블(Ansible) 문법 (0) | 2021.05.25 |
|---|