Ansible
Automatyzacja zadań IT
Kamil Grabowski
kamil.grabowski@gmail.com
WRUG 10.12.2014
@y3ti
PKO Bank Polski
Rebased
Whitestream

Potrzeba automatyzacji
WRUG 10.12.2014

Potrzeba automatyzacji
• Duża infrastruktura i problem skali
WRUG 10.12.2014

Potrzeba automatyzacji
• Duża infrastruktura i problem skali
• Skomplikowany proces instalacji i konfiguracji
środowiska
WRUG 10.12.2014

Potrzeba automatyzacji
• Duża infrastruktura i problem skali
• Skomplikowany proces instalacji i konfiguracji
środowiska
• Disaster recovery
WRUG 10.12.2014

Potrzeba automatyzacji
• Duża infrastruktura i problem skali
• Skomplikowany proces instalacji i konfiguracji
środowiska
• Disaster recovery
• Usługi w chmurze / OnDemand
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Narzędzia do automatyzacji
WRUG 10.12.2014

Dlaczego Ansible?
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
• Agentless
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
• Agentless
• Minimum zależności:
• management: python 2.6
• node: python 2.4
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
• Agentless
• Minimum zależności:
• management: python 2.6
• node: python 2.4
• Filozofia
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
• Agentless
• Minimum zależności:
• management: python 2.6
• node: python 2.4
• Filozofia
• Bogate repozytorium modułów
WRUG 10.12.2014

Dlaczego Ansible?
• Dokumentacja
• Agentless
• Minimum zależności:
• management: python 2.6
• node: python 2.4
• Filozofia
• Bogate repozytorium modułów
• Support
WRUG 10.12.2014

Warianty instalacji
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
# apt-get install ansible
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
# apt-get install ansible
Instalacja poprzez managera paczek pip
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
# apt-get install ansible
Instalacja poprzez managera paczek pip
# apt-get install python-pip
# pip install ansible
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
# apt-get install ansible
Instalacja poprzez managera paczek pip
# apt-get install python-pip
# pip install ansible
„Hacking directory tools” dostarczony z ansible
WRUG 10.12.2014

Warianty instalacji
Instalacja poprzez apt-get
# apt-get install ansible
Instalacja poprzez managera paczek pip
# apt-get install python-pip
# pip install ansible
„Hacking directory tools” dostarczony z ansible
# git clone https://github.com/ansible/
ansible.git
# cd ansible; source hacking/env-set
WRUG 10.12.2014

Pierwszy krok - inventory
$ cat hosts.ini
[application]
app01 ansible_ssh_host=10.0.0.11
app02 ansible_ssh_host=10.0.0.12
[database]
db01 ansible_ssh_host=10.0.0.21
[all:vars]
ansible_ssh_user=ubuntu
WRUG 10.12.2014

Przykład: test połączenia
$ ansible -i hosts.ini -m ping all
app02 | success >> {
"changed": false,
"ping": "pong"
}
app01 | success >> {
"changed": false,
"ping": "pong"
}
db01 | success >> {
"changed": false,
"ping": "pong"
}
WRUG 10.12.2014

Przykład: test połączenia
$ ansible -i hosts.ini -m ping all
app02 | success >> {
"changed": false,
"ping": "pong"
}
app01 | success >> {
"changed": false,
"ping": "pong"
}
db01 | success >> {
"changed": false,
"ping": "pong"
}
WRUG 10.12.2014
1

Przykład: test połączenia
1 2
$ ansible -i hosts.ini -m ping all
app02 | success >> {
"changed": false,
"ping": "pong"
}
app01 | success >> {
"changed": false,
"ping": "pong"
}
db01 | success >> {
"changed": false,
"ping": "pong"
}
WRUG 10.12.2014

Przykład: test połączenia
1 2 3
$ ansible -i hosts.ini -m ping all
app02 | success >> {
"changed": false,
"ping": "pong"
}
app01 | success >> {
"changed": false,
"ping": "pong"
}
db01 | success >> {
"changed": false,
"ping": "pong"
}
WRUG 10.12.2014

Mnogość dostępnych opcji
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping app01
$ ansible -i hosts.ini -m ping application
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping app01
$ ansible -i hosts.ini -m ping application
Gdy nie mamy dodanego klucza SSH na serwerze
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping app01
$ ansible -i hosts.ini -m ping application
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping all -k
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping app01
$ ansible -i hosts.ini -m ping application
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping all -k
Customowy klucz SSH
WRUG 10.12.2014

Mnogość dostępnych opcji
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping app01
$ ansible -i hosts.ini -m ping application
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping all -k
Customowy klucz SSH
$ ansible -i hosts.ini -m ping all --private-key
~/.vagrant.d/insecure_private_key
WRUG 10.12.2014

Przykład: instalacja vim
$ ansible -i hosts.ini -m apt -a "name=vim state=present" all -s
app02 | success >> {
"changed": true,
"stderr": "",
"stdout": "Reading package lists...nBuilding dependency [ciach]”
}
app01 | success >> {
"changed": false
}
db01 | success >> {
"changed": false
}
WRUG 10.12.2014

Przykład: instalacja vim
1
$ ansible -i hosts.ini -m apt -a "name=vim state=present" all -s
app02 | success >> {
"changed": true,
"stderr": "",
"stdout": "Reading package lists...nBuilding dependency [ciach]”
}
app01 | success >> {
"changed": false
}
db01 | success >> {
"changed": false
}
WRUG 10.12.2014

Przykład: instalacja vim
1 2
$ ansible -i hosts.ini -m apt -a "name=vim state=present" all -s
app02 | success >> {
"changed": true,
"stderr": "",
"stdout": "Reading package lists...nBuilding dependency [ciach]”
}
app01 | success >> {
"changed": false
}
db01 | success >> {
"changed": false
}
WRUG 10.12.2014

Przykład: instalacja vim
1 2 3
$ ansible -i hosts.ini -m apt -a "name=vim state=present" all -s
app02 | success >> {
"changed": true,
"stderr": "",
"stdout": "Reading package lists...nBuilding dependency [ciach]”
}
app01 | success >> {
"changed": false
}
db01 | success >> {
"changed": false
}
WRUG 10.12.2014

Przykład: instalacja vim
1 2 3
$ ansible -i hosts.ini -m apt -a "name=vim state=present" all -s
app02 | success >> {
"changed": true,
"stderr": "",
"stdout": "Reading package lists...nBuilding dependency [ciach]”
}
app01 | success >> {
"changed": false
}
db01 | success >> {
"changed": false
}
WRUG 10.12.2014
4

Przykładowe moduły
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
• monitoring: nagios, monit, zabbix
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
• monitoring: nagios, monit, zabbix
• packaging: apt, gem, homebrew, macports, npm, pip, yum itd.
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
• monitoring: nagios, monit, zabbix
• packaging: apt, gem, homebrew, macports, npm, pip, yum itd.
• source control: bzr, git, subversion
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
• monitoring: nagios, monit, zabbix
• packaging: apt, gem, homebrew, macports, npm, pip, yum itd.
• source control: bzr, git, subversion
• system: cron, filesystem, group, mount, service, user
WRUG 10.12.2014

Przykładowe moduły
• commands: command, raw, script, shell
• cloud: azure, digital_ocean, docker, ec2, rax
• database: (mysql|postgres)_(db|user), redis
• files: copy, fetch, file, lineinfile, template, unarchive
• monitoring: nagios, monit, zabbix
• packaging: apt, gem, homebrew, macports, npm, pip, yum itd.
• source control: bzr, git, subversion
• system: cron, filesystem, group, mount, service, user
• i wiele wiele innych, plus bardzo łatwo pisać swoje moduły
WRUG 10.12.2014

Playbooks
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
• Odpowiednik cookbook z chef
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
• Odpowiednik cookbook z chef
• Pliki w formacie YAML, „human-readable”
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
• Odpowiednik cookbook z chef
• Pliki w formacie YAML, „human-readable”
• Możemy korzystać z pythonowego systemu szablonów Jinja2
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
• Odpowiednik cookbook z chef
• Pliki w formacie YAML, „human-readable”
• Możemy korzystać z pythonowego systemu szablonów Jinja2
• Wiele sposobów na ich organizację, dzięki czemu służą w
prostych oraz skomplikowanych środowiskach
WRUG 10.12.2014

Playbooks
• Struktura opisująca konfigurację oraz pożądany stan hostów,
którymi zarządzamy
• Odpowiednik cookbook z chef
• Pliki w formacie YAML, „human-readable”
• Możemy korzystać z pythonowego systemu szablonów Jinja2
• Wiele sposobów na ich organizację, dzięki czemu służą w
prostych oraz skomplikowanych środowiskach
• To właśnie tu możemy zobaczyć całe piękno i filozofię ansible!
WRUG 10.12.2014

Przykład: prosty playbook
$ cat application.yml
---
- name: Deploy application servers
hosts: application
sudo: yes
tasks:
- name: Install some packages
apt: name=„{{ item }}” state=present
with_items:
- build-essential
- vim
WRUG 10.12.2014

Przykład: prosty playbook
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014

Przykład: prosty playbook
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014
1

Przykład: prosty playbook
1 2
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014

Przykład: prosty playbook
1 2
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014
3

Przykład: prosty playbook
1 2
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014
3
4

Przykład: prosty playbook
1 2
$ ansible-playbook -i hosts.ini application.yml
PLAY [Install some packages] **************************************************
GATHERING FACTS ***************************************************************
ok: [app01]
ok: [app02]
TASK: [Install some packages] *************************************************
ok: [app01] => (item=build-essential,vim)
changed: [app02] => (item=build-essential,vim)
PLAY RECAP ********************************************************************
app01 : ok=2 changed=0 unreachable=0 failed=0
app02 : ok=2 changed=1 unreachable=0 failed=0
WRUG 10.12.2014
3
4
5

Playbook - directory layout
production.ini - Nasze inventory dla środowiska produkcyjnego
stage.ini oraz testowego (stage)
group_vars/ - Zmienne dla całych grup hostów. W naszym
application przypadku dla grup application oraz database
database
host_vars/ - Zmienne zdefiniowane tylko dla konkretnego
app01 hosta
library/ - Jeśli korzystamy z własnych modułów to jest
my-module/ to idealny katalog na ich umieszczenie
site.yml - Nasze playbooki
application.yml
database.yml
roles/ - Katalog, w którym będziemy przechowywać nasze
chruby/ wszystkie role. Poprzez rolę możemy tu rozumieć
nginx/ funkcje jakie będzie posiadał nasz serwer.
our-application/ Dla przykładu serwer może mieć funkcje bazy
postgresql/ danych postgresql lub serwer www nginx.
ruby-install/
WRUG 10.12.2014

Playbook - directory layout
production.ini
stage.ini
group_vars/
application
database
host_vars/
app01
library/
my-module/
site.yml
application.yml
database.yml
roles/
chruby/
nginx/
our-application/
postgresql/
ruby-install/
roles/
postgresql/
defaults/
main.yml
files/
some_tools.tgz
handlers/
main.yml
library/
role-module/
meta/
main.yml
tasks/
main.yml
templates/
WRUG 10.12.2014
postgresql.conf.j2
vars/
main.yml

Przykład: playbook
application.yml - wersja 2
$ cat application.yml
---
- name: Deploy application servers
hosts: application
sudo: yes
roles:
- ruby-install
- chruby
- { role: nginx, server_name: example.com }
- { role: our-application, sudo_user: ubuntu }
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Ansible Vault
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Ansible Vault
• Asynchronous Actions and Polling
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Ansible Vault
• Asynchronous Actions and Polling
• Rolling Update, Maximum Failure Percentage, Deletation, Run Once
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Ansible Vault
• Asynchronous Actions and Polling
• Rolling Update, Maximum Failure Percentage, Deletation, Run Once
• Var Promts
WRUG 10.12.2014

O czym jeszcze warto
wspomieć?
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Ansible Vault
• Asynchronous Actions and Polling
• Rolling Update, Maximum Failure Percentage, Deletation, Run Once
• Var Promts
• Ansible Galaxy
WRUG 10.12.2014

Czy macie jakieś
pytania?

Dziękuję za uwagę
Kamil Grabowski
kamil.grabowski@gmail.com
WRUG 10.12.2014
@y3ti
PKO Bank Polski
Rebased
Whitestream