Ansible - Automatyzacja zadań IT
81
WRUG 10.12.2014 Ansible Automatyzacja zadań IT Kamil Grabowski [email protected] @y3ti PKO Bank Polski Rebased Whitestream
-
Upload
kamil-grabowski -
Category
Software
-
view
509 -
download
2
Transcript of Ansible - Automatyzacja zadań IT
WRUG 10.12.2014
AnsibleAutomatyzacja zadań IT
Kamil Grabowski [email protected]
@y3tiPKO 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
WRUG 10.12.2014
Instalacja poprzez apt-get
Warianty instalacji
WRUG 10.12.2014
# apt-get install ansible Instalacja poprzez apt-get
Warianty instalacji
WRUG 10.12.2014
Instalacja poprzez managera paczek pip
# apt-get install ansible Instalacja poprzez apt-get
Warianty instalacji
# apt-get install python-pip # pip install ansible
WRUG 10.12.2014
Instalacja poprzez managera paczek pip
# apt-get install ansible Instalacja poprzez apt-get
Warianty instalacji
# apt-get install python-pip # pip install ansible
WRUG 10.12.2014
Instalacja poprzez managera paczek pip
# apt-get install ansible Instalacja poprzez apt-get
„Hacking directory tools” dostarczony z ansible
Warianty instalacji
# apt-get install python-pip # pip install ansible
WRUG 10.12.2014
Instalacja poprzez managera paczek pip
# apt-get install ansible Instalacja poprzez apt-get
# git clone https://github.com/ansible/ansible.git # cd ansible; source hacking/env-set
„Hacking directory tools” dostarczony z ansible
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$ 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 2
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 2 3
Mnogość dostępnych opcji
WRUG 10.12.2014
Mnogość dostępnych opcji
WRUG 10.12.2014
Tylko jeden host lub grupa hostów
Mnogość dostępnych opcji
WRUG 10.12.2014
$ ansible -i hosts.ini -m ping app01 $ ansible -i hosts.ini -m ping application
Tylko jeden host lub grupa hostów
Mnogość dostępnych opcji
WRUG 10.12.2014
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping app01 $ ansible -i hosts.ini -m ping application
Tylko jeden host lub grupa hostów
Mnogość dostępnych opcji
$ ansible -i hosts.ini -m ping all -k
WRUG 10.12.2014
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping app01 $ ansible -i hosts.ini -m ping application
Tylko jeden host lub grupa hostów
Mnogość dostępnych opcji
$ ansible -i hosts.ini -m ping all -k
WRUG 10.12.2014
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping app01 $ ansible -i hosts.ini -m ping application
Tylko jeden host lub grupa hostów
Customowy klucz SSH
Mnogość dostępnych opcji
$ ansible -i hosts.ini -m ping all -k
WRUG 10.12.2014
Gdy nie mamy dodanego klucza SSH na serwerze
$ ansible -i hosts.ini -m ping app01 $ ansible -i hosts.ini -m ping application
Tylko jeden host lub grupa hostów
$ ansible -i hosts.ini -m ping all --private-key ~/.vagrant.d/insecure_private_key
Customowy klucz SSH
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$ 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
1
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
1 2
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
1 2 3
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
1 2 3
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$ 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 2
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 2
3
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 2
3
4
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 2
3
4
5
Playbook - directory layoutproduction.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 layoutproduction.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/
WRUG 10.12.2014
roles/ postgresql/ defaults/ main.yml files/ some_tools.tgz handlers/ main.yml library/ role-module/ meta/ main.yml tasks/ main.yml templates/ 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?
WRUG 10.12.2014
Dziękuję za uwagę
Kamil Grabowski [email protected]
@y3tiPKO Bank Polski
Rebased Whitestream
