Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Ansible w praktyce
Similar to Ansible w praktyce (20)
More from Kamil Grabowski
Ansible w praktyce
- 1. UW@IT 21.01.2015 Ansible w praktyce Kamil Grabowski kamil.grabowski@gmail.com @y3ti Rebased Whitestream
- 2. 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
- 3. Narzędzia do automatyzacji UW@IT 21.01.2015
- 4. 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
- 5. 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
- 6. 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
- 7. 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
- 8. Mnogość dostępnych opcji $ ansible -i hosts.ini -m ping all -k 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 UW@IT 21.01.2015
- 9. 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
- 10. 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
- 11. 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
- 12. 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
- 13. 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
- 14. 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
- 15. Playbook - directory layout production.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
- 16. Role - 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/ postgresql.conf.j2 vars/ main.yml UW@IT 21.01.2015
- 17. 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
- 18. 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
- 19. Przykład: group_vars/ application $ cat group_vars/application deploy_git_repo: git@github.com: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
- 20. 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
- 21. 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 !!!
- 22. 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
- 23. 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
- 24. 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
- 25. Przykład: playbook application.yml $ ansible-playbook -i production.ini application.yml --ask-vault-pass Vault password: ******* UW@IT 21.01.2015
- 26. 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
- 28. Dziękuję za uwagę Kamil Grabowski kamil.grabowski@gmail.com @y3ti Rebased Whitestream UW@IT 21.01.2015