Z rodiny configuration management nástrojů jako jsou Puppet, Chef, Ansible a Salt Stack mám Ansible osobně nejraději - nebojím se totiž mezer, takže YAML a Python mi vyhovují (pokud jste typ složených závorek či jiných na odsazení nezávislých zápisech, asi půjdete spíše do Chef a JSON :) ). Víte ale, že z Red Hat Ansible můžete nejen automatizovat instalaci aplikačního prostředí i aplikací a udržovat OS, ale i provisionovat zdroje v Azure? Podívejme se jak na to.
Připravíme si prostředí
Co budete potřebovat? Já použiji Linux stroj, na něm Python, Ansible, dále potřebujeme Azure Python SDK. Pro zjednodušení jsem si připravil Docker image, abych to na svém Windows 10 notebooku mohl řešit jednoduše a efektivně (s Docker for Windows). Spouštím ho tak, aby trvale běžel (proces tail) a pak teprve vyvolám bash (takže když se odpojím, kontejner jede dál).
docker run --name ansible -d tkubica/ansibleazure tail -f /dev/null docker exec -it ansible bash
Dnes budu přes Ansible ovládat pouze Azure a Linux VMka v něm, pokud ale budete Ansiblem instalovat komponenty ve Windows OS (což si zkusíme někdy příště), budete v případě Linux hostitele potřebovat ještě pár dalších dependencies (WinRM pro Python, Kerberos).
Jak se Ansible napojí do vaší Azure subscription? Možností je několik, ale pokud stejně jako já máte dvoufaktorové ověření, je rozhodně nejjednoduší vytvořit service principála. Nejrychlejší cesta k tomu vede přes Azure CLI, ale můžete použít i GUI nebo PowerShell.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/vase-subscription-id"
{
"appId": "blabla1",
"displayName": "azure-cli-2017-02-19-08-27-11",
"name": "http://azure-cli-2017-02-19-08-27-11",
"password": "blabla2",
"tenant": "blabla3"
}
Není vhodné mít jakákoli hesla přímo součástí playbooků, tedy samotných Ansible předpisů. Důvodem je, že ty chcete obvykle dát do version control systému a sdílet je, což je opak toho, co chcete udělat s hesly. Můžete zvolit jiné soubory, zapsat to do Ansible inventáře, já ale nejraději environmentální proměnné. V rámci mé session tedy stačí udělat tohle:
export AZURE_TENANT=blabla3 export AZURE_CLIENT_ID=blabla1 export AZURE_SECRET=blabla2 export AZURE_SUBSCRIPTION_ID=vase-subscription-is
Vytváříme VM v Azure z Ansible
Všechny příklady jsem uložil na GitHub: https://github.com/tkubica12/ansible-azure/tree/master
Náš playbook (infrastrukturní předpis) je v souboru web-servers.yaml (jak uvidíte později používám z něj ještě vnořený web-server.yaml playbook). Prohlédněme si ho postupně.
- name: Ensure we have one Linux server with tags apache and nginx
hosts: localhost
connection: local
gather_facts: False
vars:
group: "{{ lookup('env', 'AZURE_RESOURCE_GROUPS') }}"
vms:
- name: mujApache1
tag: apache
- name: mujApache2
tag: apache
- name: mujApache3
tag: apache
- name: mujNGINX
tag: nginx
Tohle je popis a vstupní podmínky playbooku. Zaměříme se na vars, tedy proměnné (v praxi bych je asi dal do samostatného souboru, ale nechtěl jsem to komplikovat). Group použijeme později jako název Resource Group v Azure a v playbooku jej beru z proměnné prostředí (místo přímého zápisu zde... ostatně při spuštění můžete také všechno přepsat parametrem -e group=mojeskupina). Dále jsem si vymyslel vms, což je pole objektů, kde každý objekt reprezentuje jednu VM a má atributy name a tag. Tohle použijeme později ve skriptu. Proč i tag? Jde o metadata, kteráuložíme v Azure a později je použijeme k rozhodnutí, co na VM nainstalovat.
Podívejme se na sekci tasků.
tasks:
- name: Ensure resource group exists
azure_rm_resourcegroup:
name: "{{ group }}"
location: westeurope
- name: Ensure virtual network exists
azure_rm_virtualnetwork:
resource_group: "{{ group }}"
name: mynet
address_prefixes: "10.10.0.0/16"
- name: Ensure subnet exists
azure_rm_subnet:
name: mysub
virtual_network_name: mynet
resource_group: "{{ group }}"
address_prefix_cidr: "10.10.1.0/24"
- name: Ensure Linux VMs exists
include: web-server.yaml
with_items: "{{ vms }}"
V prvních třech úkolech se ujistíme, že resource group existuje, že v ní je vnet a subnet tak, jak potřebuji. Čtvrtý krok je smyčka, která projde všechy objekty pole vms (tedy všechna požadovaná VMka) a pro každý vyvolá vnořený playbook web-server.yaml. V něm už se budou provádět úkony specifické pro samotné VM.
Tohle je web-server.yaml:
- name: Make sure VM exist
azure_rm_virtualmachine:
resource_group: "{{ group }}"
name: "{{ item.name }}"
vm_size: Standard_A0
admin_username: tomas
ssh_password_enabled: false
ssh_public_keys:
- path: /home/tomas/.ssh/authorized_keys
key_data: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFhm1FUhzt/9roX7SmT/dI+vkpyQVZp3Oo5HC23YkUVtpmTdHje5oBV0LMLBB1Q5oSNMCWiJpdfD4VxURC31yet4mQxX2DFYz8oEUh0Vpv+9YWwkEhyDy4AVmVKVoISo5rAsl3JLbcOkSqSO8FaEfO5KIIeJXB6yGI3UQOoL1owMR9STEnI2TGPZzvk/BdRE73gJxqqY0joyPSWOMAQ75Xr9ddWHul+v//hKjibFuQF9AFzaEwNbW5HxDsQj8gvdG/5d6mt66SfaY+UWkKldM4vRiZ1w11WlyxRJn5yZNTeOxIYU4WLrDtvlBklCMgB7oF0QfiqahauOEo6m5Di2Ex"
os_type: Linux
image:
offer: UbuntuServer
publisher: Canonical
sku: "14.04.4-LTS"
version: latest
open_ports:
- 22
- 80
tags:
ansiblegroup: "{{ item.tag }}"
register: mojelinuxvm
- name: Print IP
debug: msg="Access your Linux VM at {{ mojelinuxvm.ansible_facts.azure_vm.properties.networkProfile.networkInterfaces[0].properties.ipConfigurations[0].properties.publicIPAddress.properties.ipAddress}}"
První úloha vytvoří VM o konkrétní velikosti, jménu, SSH klíči a OS. Definuji otevřené porty (NSG) a přiřazuji tag (všimněte si, jak Ansible umí dosazovat proměnné, ať už přímo jednoduše group nebo to z konkrétní iteraci smyčky nad vms). Tato úloha vrátí obrovský JSON výstupů, který registruji do proměnné mojelinuxvm. V druhé úloze právě z toho výstupu vytisknu jednu jedinou věc - veřejnou IP adresu (pokud chcete pro studijní účely vidět všechno, dejte debug: var=mojelinuxvm.
Vyzkoušejme si automatizovat poskládání infrastruktury v Azure
Otestujeme si teď tento playbook. Nezapomeňte vyexportovat jméno groupy a jedeme.
export AZURE_RESOURCE_GROUPS=ansible
ansible-playbook web-servers.yaml
[WARNING]: Host file not found: /etc/ansible/hosts
[WARNING]: provided hosts list is empty, only localhost is available
PLAY [Ensure we have one Linux server with tags apache and nginx] **************
TASK [Ensure resource group exists] ********************************************
changed: [localhost]
TASK [Ensure virtual network exists] *******************************************
changed: [localhost]
TASK [Ensure subnet exists] ****************************************************
changed: [localhost]
TASK [Ensure Linux VMs exists] *************************************************
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
TASK [Make sure VM exist] ******************************************************
changed: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 13.94.130.144"
}
TASK [Make sure VM exist] ******************************************************
changed: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 52.166.204.184"
}
TASK [Make sure VM exist] ******************************************************
changed: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 13.81.113.13"
}
TASK [Make sure VM exist] ******************************************************
changed: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 40.118.101.66"
}
PLAY RECAP *********************************************************************
localhost : ok=15 changed=7 unreachable=0 failed=0
Ověřte v GUI, že se toho docela hodně stalo.
V mém případě bylo u všech kroků napsáno changed, tedy Ansible došel k závěru, že skutečný stav neodpovídá požadovanému a musel zasáhnout (což je logické, moje resource group vůbec neexistovala). Udělejme teď to, že jednu (pouze jednu) z VM smažu ručně z portálu a spustím playbook znova. Co myslíte, že se bude dít? Všechno pojede mnohem rychleji a v okamžiku, kdy Ansible zjistí rozpor požadovaného a skutečného stavu, vyřeší to.
ansible-playbook web-servers.yaml
[WARNING]: Host file not found: /etc/ansible/hosts
[WARNING]: provided hosts list is empty, only localhost is available
PLAY [Ensure we have one Linux server with tags apache and nginx] **************
TASK [Ensure resource group exists] ********************************************
ok: [localhost]
TASK [Ensure virtual network exists] *******************************************
ok: [localhost]
TASK [Ensure subnet exists] ****************************************************
ok: [localhost]
TASK [Ensure Linux VMs exists] *************************************************
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
included: /ansible-azure/web-server.yaml for localhost
TASK [Make sure VM exist] ******************************************************
changed: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 13.94.130.144"
}
TASK [Make sure VM exist] ******************************************************
ok: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 52.166.204.184"
}
TASK [Make sure VM exist] ******************************************************
ok: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 13.81.113.13"
}
TASK [Make sure VM exist] ******************************************************
ok: [localhost]
TASK [Print IP] ****************************************************************
ok: [localhost] => {
"msg": "Access your Linux VM at 40.118.101.66"
}
PLAY RECAP *********************************************************************
localhost : ok=15 changed=1 unreachable=0 failed=0
Konfigurace OS a dynamický Azure inventář
Jak už jsem říkal - Ansible mám rád a mám k tomu dva hlavní důvody. První je ten, že playbooky jsou v YAMLu (já se mezer nebojím), který je lidsky čitelný a neprogramátory neděsí (nebo alespoň méně, než JSON nebo Chef cookook v Ruby). Ten druhý je ale důležitější - Ansible nevyžaduje žádného agenta v OS. Nemusíte řešit, jak ho tam nainstalovat, jak je bezpečně propojit a tohle celé automatizovat (takže odpadají komplikace typu Chef extension v Azure nebo Chef Knife pro provisioning). Stačí vám jen SSH přístup a Python v OS (standardní výbava dnes už každé Linux distribuce) - v případě Windows se používá WinRM, ale o tom jindy.
Co tedy potřebujeme je v zásadě seznam IP adres rozřazených do skupin podle typu serveru (pokud vás teď napadlo co když VM v Azure nebude mít public IP a vy nechcete mít Ansible server nainstalovaný v Azure, tak vězte, že je možné použít jednu VM ve stejném VNet jako SSH proxy). To je co chceme. Na základě výstupu předchozího tasku si to můžu opsat a vytvořit ručně. Ale co by to pak bylo za automatizaci. Ansible podporuje dynamický inventář pro Azure. V zásadě jde o "očuchávátko". Namíříte na vaši subscription či resource group a ono to stáhne názvy VM, přihlašovací jména do nich a z tagů vytvoří automaticky různé skupiny. V našem případě tedy rozhodně získáme skupinu ansiblegroup_apache a ansiblegroup_nginx a to je přesně to, co nám stačí pro instalaci správného web serveru na tu kterou VM v Azure.
Takhle vypadá můj playbook hydrate.yaml (slovo vychází z termínu, kdy prázdnou VM jako květináč ze semínkem zalijete a ono vyroste to, co potřebujete).
- name: Make sure apache is installed on correct system
hosts: ansiblegroup_apache
gather_facts: no
remote_user: tomas
become: true
tasks:
- name: Make sure Apache2 is installed
apt: name=apache2 update_cache=yes state=latest
- name: Enabled mod_rewrite
apache2_module: name=rewrite state=present
notify:
- Restart apache2
- name: Make sure Apache2 is started
service:
name: apache2
state: started
handlers:
- name: Restart apache2
service:
name: apache2
state: restarted
- name: Make sure nginx is installed on correct system
hosts: ansiblegroup_nginx
gather_facts: no
remote_user: tomas
become: true
tasks:
- name: Make sure nginx is installed
apt: name=nginx update_cache=yes state=latest
- name: Make sure nginx is started
service:
name: nginx
state: started
Co v něm dělám? Jsou to dva playbooky v jednom souboru - jeden se spouští na serverech, které jsou ve skupině ansiblegroup_apache (tedy tag, který jsme jim dali na začátku) a druhé pro ansiblegroup_nginx. Apache nainstalujeme package managerem (pokud je to potřeba), zapneme apache module (je-li to potřeba a v takovém případě ještě handlerem zrestartujeme službu) a ujistíme se, že je služba spuštěná. U NGINX postupuji podobně, ale jen nainstaluji a ujistím se, že je služba nahoře. Je to jen drobná ukázka - v praxi bychom provedli veškerá potřebná nastavení, rozjeli virtuální servery, vytvořili certifikáty a zapnuli HTTPS, nakopírovali naší webovou aplikaci z Gitu a tak podobně.
Vyzkoušíme si to. Všimněte si přepínače -i, který definuje inventář. Ale místo statického souboru je to azure_rm.py skript, který Ansible oficiálně vytvořil pro automatickou inventarizaci Azure (autentizace do Azure je stejná jako výše, takže vámi vyexportované údaje stačí). Ještě jedna věc - očekávám, že vaše stanice se může k VM připojit bez hesla (tzn. privátní klíč je v mašině). Můžete použít i různé jiné postupy, ale SSH klíče a password-less autentizace jsou rozhodně best practice. Ještě vypneme cacheování public klíčů, aby nás to neobtěžovalo (správný postup by byl veřejné klíče cílových serverů nějakým způsobem přenést k vám a uložit do autorizovaných klíčů).
export ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook -i "azure_rm.py" hydrate.yaml PLAY [Make sure apache is installed on correct system] ************************* TASK [Make sure Apache2 is installed] ****************************************** changed: [mujApache2] changed: [mujApache1] changed: [mujApache3] TASK [Enabled mod_rewrite] ***************************************************** changed: [mujApache1] changed: [mujApache2] changed: [mujApache3] TASK [Make sure Apache2 is started] ******************************************** ok: [mujApache1] ok: [mujApache2] ok: [mujApache3] RUNNING HANDLER [Restart apache2] ********************************************** changed: [mujApache2] changed: [mujApache1] changed: [mujApache3] PLAY [Make sure nginx is installed on correct system] ************************** TASK [Make sure nginx is installed] ******************************************** changed: [mujNGINX] TASK [Make sure nginx is started] ********************************************** ok: [mujNGINX] PLAY RECAP ********************************************************************* mujApache1 : ok=4 changed=3 unreachable=0 failed=0 mujApache2 : ok=4 changed=3 unreachable=0 failed=0 mujApache3 : ok=4 changed=3 unreachable=0 failed=0 mujNGINX : ok=2 changed=1 unreachable=0 failed=0
Klidně si teď vyzkoušejte, že servery skutečně reagují.
Red Hat Ansible je sice původně nástroj pro configuration management, tedy správu "vnitřku vašich VM", ale v poslední době se velmi rozšířil co do možností automatizovat i hodně dalších věcí včetně provisioningu Azure infrastruktury. Někdo půjde cestou ARM šablon (pokud automatizujete jen Azure, jasná volba) a k nim nějaký configuration management. Jiný bude preferovat univerzálnější provisioning infrastruktury různých typu (Azure, VMware, AWS, OpenStack) a půjde do Terraform (to by byla moje volba pro takový scénář) nebo CloudForms a k nim configuration management. Třetí přístup je vzít configuration management, třeba Ansible, a tím udělat všechno od infra až po běžící aplikaci. Volba je na vás.