SlideShare a Scribd company logo
1 of 81
Download to read offline
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

More Related Content

What's hot

Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018Amazon Web Services Korea
 
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...Amazon Web Services
 
Docker 101 - Getting started
Docker 101 - Getting startedDocker 101 - Getting started
Docker 101 - Getting startedMatheus Marabesi
 
Zero Downtime using Blue Green Deployments in AWS
Zero Downtime using Blue Green Deployments in AWSZero Downtime using Blue Green Deployments in AWS
Zero Downtime using Blue Green Deployments in AWSRubén Rubio Rey
 
K8s in 3h - Kubernetes Fundamentals Training
K8s in 3h - Kubernetes Fundamentals TrainingK8s in 3h - Kubernetes Fundamentals Training
K8s in 3h - Kubernetes Fundamentals TrainingPiotr Perzyna
 
An introduction to terraform
An introduction to terraformAn introduction to terraform
An introduction to terraformJulien Pivotto
 
Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker, Inc.
 
What is Docker Architecture | Edureka
What is Docker Architecture | EdurekaWhat is Docker Architecture | Edureka
What is Docker Architecture | EdurekaEdureka!
 
Azure 仮想マシンとRemoteAppの超概要
Azure 仮想マシンとRemoteAppの超概要Azure 仮想マシンとRemoteAppの超概要
Azure 仮想マシンとRemoteAppの超概要Daiyu Hatakeyama
 
Minio ♥ Go
Minio ♥ GoMinio ♥ Go
Minio ♥ GoMinio
 
Terraform modules and (some of) best practices
Terraform modules and (some of) best practicesTerraform modules and (some of) best practices
Terraform modules and (some of) best practicesAnton Babenko
 
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017Amazon Web Services Korea
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Samir Hammoudi
 
Apache Spark on K8S and HDFS Security with Ilan Flonenko
Apache Spark on K8S and HDFS Security with Ilan FlonenkoApache Spark on K8S and HDFS Security with Ilan Flonenko
Apache Spark on K8S and HDFS Security with Ilan FlonenkoDatabricks
 
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요Jo Hoon
 
Terraform -- Infrastructure as Code
Terraform -- Infrastructure as CodeTerraform -- Infrastructure as Code
Terraform -- Infrastructure as CodeMartin Schütte
 

What's hot (20)

Dockerizing react app
Dockerizing react appDockerizing react app
Dockerizing react app
 
Swoole Love PHP
Swoole Love PHPSwoole Love PHP
Swoole Love PHP
 
Intro to Terraform
Intro to TerraformIntro to Terraform
Intro to Terraform
 
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...
Tinder and DynamoDB: It's a Match! Massive Data Migration, Zero Down Time - D...
 
Docker 101 - Getting started
Docker 101 - Getting startedDocker 101 - Getting started
Docker 101 - Getting started
 
Zero Downtime using Blue Green Deployments in AWS
Zero Downtime using Blue Green Deployments in AWSZero Downtime using Blue Green Deployments in AWS
Zero Downtime using Blue Green Deployments in AWS
 
K8s in 3h - Kubernetes Fundamentals Training
K8s in 3h - Kubernetes Fundamentals TrainingK8s in 3h - Kubernetes Fundamentals Training
K8s in 3h - Kubernetes Fundamentals Training
 
An introduction to terraform
An introduction to terraformAn introduction to terraform
An introduction to terraform
 
Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker 101 - Nov 2016
Docker 101 - Nov 2016
 
What is Docker Architecture | Edureka
What is Docker Architecture | EdurekaWhat is Docker Architecture | Edureka
What is Docker Architecture | Edureka
 
Azure 仮想マシンとRemoteAppの超概要
Azure 仮想マシンとRemoteAppの超概要Azure 仮想マシンとRemoteAppの超概要
Azure 仮想マシンとRemoteAppの超概要
 
Minio ♥ Go
Minio ♥ GoMinio ♥ Go
Minio ♥ Go
 
Terraform modules and (some of) best practices
Terraform modules and (some of) best practicesTerraform modules and (some of) best practices
Terraform modules and (some of) best practices
 
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
 
AWS Amplify 入門
AWS Amplify 入門AWS Amplify 入門
AWS Amplify 入門
 
Apache Spark on K8S and HDFS Security with Ilan Flonenko
Apache Spark on K8S and HDFS Security with Ilan FlonenkoApache Spark on K8S and HDFS Security with Ilan Flonenko
Apache Spark on K8S and HDFS Security with Ilan Flonenko
 
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
[네전따] 네트워크 엔지니어에게 쿠버네티스는 어떤 의미일까요
 
Terraform -- Infrastructure as Code
Terraform -- Infrastructure as CodeTerraform -- Infrastructure as Code
Terraform -- Infrastructure as Code
 

Similar to Ansible - Automatyzacja zadań IT

Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobami
Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobamiElasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobami
Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobamiEnterprise Search Warsaw Meetup
 
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPROIDEA
 
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...The Software House
 
Vagrant - RuPy Tuesday
Vagrant - RuPy TuesdayVagrant - RuPy Tuesday
Vagrant - RuPy TuesdayGaldoMedia
 
Deployment kodu z Capistrano
Deployment kodu z CapistranoDeployment kodu z Capistrano
Deployment kodu z CapistranoMichał Szajbe
 
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...PROIDEA
 
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...HighSolutions Sp. z o.o.
 
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'a
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'aUruchomienie i praca z laravel w wirtualnym kontenerze docker'a
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'aLaravel Poland MeetUp
 
Krytyczne błędy konfiguracji
Krytyczne błędy konfiguracjiKrytyczne błędy konfiguracji
Krytyczne błędy konfiguracjiLogicaltrust pl
 
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16Krzysztof Synak
 
Service workers - bądź online, nawet kiedy jesteś offline!
Service workers - bądź online, nawet kiedy jesteś offline!Service workers - bądź online, nawet kiedy jesteś offline!
Service workers - bądź online, nawet kiedy jesteś offline!The Software House
 
Sekrety magicznego ogrodu Docker
Sekrety magicznego ogrodu DockerSekrety magicznego ogrodu Docker
Sekrety magicznego ogrodu DockerKamil Grabowski
 
Podstawy AngularJS
Podstawy AngularJSPodstawy AngularJS
Podstawy AngularJSSages
 
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...Future Processing
 
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PROIDEA
 
Debugowanie skryptow php za pomoca xdebug
Debugowanie skryptow php za pomoca xdebugDebugowanie skryptow php za pomoca xdebug
Debugowanie skryptow php za pomoca xdebugXSolve
 
Automatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPAutomatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPLaravel Poland MeetUp
 

Similar to Ansible - Automatyzacja zadań IT (20)

Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobami
Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobamiElasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobami
Elasticsearch i Docker - skalowalność, wysoka dostępność i zarządzanie zasobami
 
Ansible w praktyce
Ansible w praktyceAnsible w praktyce
Ansible w praktyce
 
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOpsPLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
PLNOG 22 - Krzysztof Załęski - Praktyczne zastosowanie narzędzi NetDevOps
 
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...
 
Vagrant - RuPy Tuesday
Vagrant - RuPy TuesdayVagrant - RuPy Tuesday
Vagrant - RuPy Tuesday
 
Deployment kodu z Capistrano
Deployment kodu z CapistranoDeployment kodu z Capistrano
Deployment kodu z Capistrano
 
Platforma Kontentowa
Platforma KontentowaPlatforma Kontentowa
Platforma Kontentowa
 
Rundeck & Ansible
Rundeck & AnsibleRundeck & Ansible
Rundeck & Ansible
 
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...
PLNOG22 - Piotr Stolarek - Bezpieczeństwo użytkowania platform usługowych Tel...
 
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...
Laravel Poznań Meetup #3 - Uruchomienie i praca z Laravel w wirtualnym konten...
 
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'a
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'aUruchomienie i praca z laravel w wirtualnym kontenerze docker'a
Uruchomienie i praca z laravel w wirtualnym kontenerze docker'a
 
Krytyczne błędy konfiguracji
Krytyczne błędy konfiguracjiKrytyczne błędy konfiguracji
Krytyczne błędy konfiguracji
 
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16
Integracja środowiska testowego z użyciem Robot Framework, TrojQA 2014-12-16
 
Service workers - bądź online, nawet kiedy jesteś offline!
Service workers - bądź online, nawet kiedy jesteś offline!Service workers - bądź online, nawet kiedy jesteś offline!
Service workers - bądź online, nawet kiedy jesteś offline!
 
Sekrety magicznego ogrodu Docker
Sekrety magicznego ogrodu DockerSekrety magicznego ogrodu Docker
Sekrety magicznego ogrodu Docker
 
Podstawy AngularJS
Podstawy AngularJSPodstawy AngularJS
Podstawy AngularJS
 
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...
[Quality Meetup #9] TestOps, QAOps - czy ktoś taki istnieje? - Aleksandra Kor...
 
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
PLNOG 6: Łukasz Jagiełło - Wdrożenie skalowalnego systemu plików GlusterFS w ...
 
Debugowanie skryptow php za pomoca xdebug
Debugowanie skryptow php za pomoca xdebugDebugowanie skryptow php za pomoca xdebug
Debugowanie skryptow php za pomoca xdebug
 
Automatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHPAutomatyzacja utrzymania jakości w środowisku PHP
Automatyzacja utrzymania jakości w środowisku PHP
 

More from Kamil Grabowski

Jak wygrać Igrzyska Chmury
Jak wygrać Igrzyska ChmuryJak wygrać Igrzyska Chmury
Jak wygrać Igrzyska ChmuryKamil Grabowski
 
Porażka nie wchodzi w grę, czyli o niezawodności
Porażka nie wchodzi w grę, czyli o niezawodnościPorażka nie wchodzi w grę, czyli o niezawodności
Porażka nie wchodzi w grę, czyli o niezawodnościKamil Grabowski
 
RRDTool + RUBY DSL = RRD-FFI
RRDTool + RUBY DSL = RRD-FFIRRDTool + RUBY DSL = RRD-FFI
RRDTool + RUBY DSL = RRD-FFIKamil Grabowski
 
Jak wyglada monitoring w PLIX
Jak wyglada monitoring w PLIXJak wyglada monitoring w PLIX
Jak wyglada monitoring w PLIXKamil Grabowski
 
Sprzetowe i programowe aspekty punktu wymiany ruchu
Sprzetowe i programowe aspekty punktu wymiany ruchuSprzetowe i programowe aspekty punktu wymiany ruchu
Sprzetowe i programowe aspekty punktu wymiany ruchuKamil Grabowski
 
How to create effective NOC in Poland
How to create effective NOC in PolandHow to create effective NOC in Poland
How to create effective NOC in PolandKamil Grabowski
 

More from Kamil Grabowski (9)

Jak wygrać Igrzyska Chmury
Jak wygrać Igrzyska ChmuryJak wygrać Igrzyska Chmury
Jak wygrać Igrzyska Chmury
 
Porażka nie wchodzi w grę, czyli o niezawodności
Porażka nie wchodzi w grę, czyli o niezawodnościPorażka nie wchodzi w grę, czyli o niezawodności
Porażka nie wchodzi w grę, czyli o niezawodności
 
Infrastructure As Code
Infrastructure As CodeInfrastructure As Code
Infrastructure As Code
 
Docker
DockerDocker
Docker
 
RRDTool + RUBY DSL = RRD-FFI
RRDTool + RUBY DSL = RRD-FFIRRDTool + RUBY DSL = RRD-FFI
RRDTool + RUBY DSL = RRD-FFI
 
Jak wyglada monitoring w PLIX
Jak wyglada monitoring w PLIXJak wyglada monitoring w PLIX
Jak wyglada monitoring w PLIX
 
Monitoring sieci
Monitoring sieciMonitoring sieci
Monitoring sieci
 
Sprzetowe i programowe aspekty punktu wymiany ruchu
Sprzetowe i programowe aspekty punktu wymiany ruchuSprzetowe i programowe aspekty punktu wymiany ruchu
Sprzetowe i programowe aspekty punktu wymiany ruchu
 
How to create effective NOC in Poland
How to create effective NOC in PolandHow to create effective NOC in Poland
How to create effective NOC in Poland
 

Ansible - Automatyzacja zadań IT

  • 1. Ansible Automatyzacja zadań IT Kamil Grabowski kamil.grabowski@gmail.com WRUG 10.12.2014 @y3ti PKO Bank Polski Rebased Whitestream
  • 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
  • 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
  • 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
  • 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
  • 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