Ansible w praktyce
28
-
Upload
kamil-grabowski -
Category
Software
-
view
200 -
download
6
Transcript of Ansible w praktyce
Potrzeba automatyzacji
• Duża infrastruktura i problem skali
• Skomplikowany proces instalacji i konfiguracji środowiska
• Disaster recovery
• Usługi w chmurze / OnDemand
UW@IT 21.01.2015
Narzędzia do automatyzacji
UW@IT 21.01.2015
Dlaczego Ansible?• Dokumentacja
• Agentless
• Minimum zależności:
• management: python 2.6
• node: python 2.4
• Filozofia
• Bogate repozytorium modułów
• Support
UW@IT 21.01.2015
Warianty instalacji
# apt-get install python-pip # pip install ansible
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
UW@IT 21.01.2015
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
UW@IT 21.01.2015
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" }
1 2 3
UW@IT 21.01.2015
Mnogość dostępnych opcji
$ ansible -i hosts.ini -m ping all -kGdy 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
UW@IT 21.01.2015
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 }
1 2 3
4
UW@IT 21.01.2015
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
UW@IT 21.01.2015
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!
UW@IT 21.01.2015
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
UW@IT 21.01.2015
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
1 2
3
4
5
UW@IT 21.01.2015
Playbooks - keywords• playbooks
• inventory (hostgroup, hostgroup variables)
• host_vars
• group_vars
• facts
• libraries
• roles (defaults/vars, templates/files, tasks, handlers, meta)
UW@IT 21.01.2015
Playbook - directory layoutproduction.ini - Nasze inventory dla środowiska produkcyjnego staging.ini oraz testowego (staging)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/
UW@IT 21.01.2015
Role - 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/
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
UW@IT 21.01.2015
Przykład: nowe inventory$ cat production.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 stage=production
UW@IT 21.01.2015
Przykład: playbook application.yml
$ cat application.yml --- - name: Deploy application servers hosts: application sudo: yes roles: - setup - memcached - { role: nginx, server_name: example.com } - { role: deploy, deploy_to: "/data" }
UW@IT 21.01.2015
Przykład: group_vars/application
$ cat group_vars/application deploy_git_repo: [email protected]:y3ti/app.git deploy_git_branch: "{{ stage }}" setup_apt_packages: - build-essential - git-core - ntp - postgresql-client-9.3 - postgresql-server-dev—9.3
UW@IT 21.01.2015
Przykład: group_vars/all$ cat group_vars/all postgresql_database: "myapp_{{ stage }}" postgresql_username: myapp postgresql_password: qwe135 setup_ntp_servers: - ntp.icm.edu.pl - ntp.myserver.com
UW@IT 21.01.2015
Przykład: group_vars/all$ cat group_vars/all postgresql_database: "myapp_{{ stage }}" postgresql_username: myapp postgresql_password: qwe135 setup_ntp_servers: - ntp.icm.edu.pl - ntp.myserver.com
UW@IT 21.01.2015
SECURITY !!!
Przykład: credentials/production.yml
$ cat credentials/production.yml deploy_private_key: | -----BEGIN DSA PRIVATE KEY----- ... ... postgresql_username: myapp postgresql_password: qwe135
UW@IT 21.01.2015
Ansible Vault$ ansible-vault encrypt credentials/production.yml Vault password: ********* Confirm Vault password: ********* Encryption successful $ cat credentials/production.yml $ANSIBLE_VAULT;1.1;AES256 373930656139623263396436356130633… … …
UW@IT 21.01.2015
Przykład: playbook application.yml
$ cat application.yml --- - name: Deploy application servers hosts: application sudo: yes vars_files: - "credentials/{{ stage }}.yml" roles: - setup - memcached - { role: nginx, server_name: example.com } - { role: deploy, deploy_to: "/data" }
UW@IT 21.01.2015
Przykład: playbook application.yml
$ ansible-playbook -i production.ini application.yml --ask-vault-pass Vault password: *******
UW@IT 21.01.2015
O czym jeszcze warto wspomieć?
• Var Promts
• Variables, Loops, Conditionals, Jinja2
• Tags
• Facts Caching
• Asynchronous Actions and Polling
• Rolling Update, Maximum Failure Percentage, Delegation, Run Once
• Ansible Galaxy
UW@IT 21.01.2015
Czy macie jakieś pytania?
