Wstęp do narzędzia ansible, dzięki któremu możemy automatyzować nasze zadania w IT.

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

2. Potrzeba automatyzacji
WRUG 10.12.2014

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

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

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

6. 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

7. Narzędzia do automatyzacji
WRUG 10.12.2014

8. Narzędzia do automatyzacji
WRUG 10.12.2014

9. Narzędzia do automatyzacji
WRUG 10.12.2014

10. Narzędzia do automatyzacji
WRUG 10.12.2014

11. Narzędzia do automatyzacji
WRUG 10.12.2014

12. Narzędzia do automatyzacji
WRUG 10.12.2014

13. Dlaczego Ansible?
WRUG 10.12.2014

14. Dlaczego Ansible?
• Dokumentacja
WRUG 10.12.2014

15. Dlaczego Ansible?
• Dokumentacja
• Agentless
WRUG 10.12.2014

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

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

18. 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

19. 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

20. Warianty instalacji
WRUG 10.12.2014

21. Warianty instalacji
Instalacja poprzez apt-get
WRUG 10.12.2014

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

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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. Mnogość dostępnych opcji
WRUG 10.12.2014

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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. Przykładowe moduły
WRUG 10.12.2014

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

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

47. 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

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

54. Playbooks
WRUG 10.12.2014

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

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

57. 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

58. 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

59. 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

60. 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

61. 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

62. 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

63. 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

64. 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

65. 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

66. 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

67. 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

68. 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

69. 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

70. 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

71. O czym jeszcze warto
wspomieć?
WRUG 10.12.2014

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

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

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

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

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

77. 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

78. 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

79. 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

80. Czy macie jakieś
pytania?

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