Nie je to tak dávno, čo som potreboval napísať niekoľko Ansible playbookov, aby som pripravil server na nasadenie aplikácie Rails. A prekvapivo som nenašiel jednoduchý návod krok za krokom. Nechcel som kopírovať učebnicu niekoho iného bez toho, aby som pochopil, čo sa deje, a nakoniec som si musel prečítať dokumentáciu a všetko zhromaždiť sám. Možno pomôžem niekomu urýchliť tento proces pomocou tohto článku.
Prvá vec, ktorú treba pochopiť, je, že ansible vám poskytuje pohodlné rozhranie na vykonávanie vopred definovaného zoznamu akcií na vzdialenom serveri (serveroch) cez SSH. Nie je tu žiadna mágia, nemôžete nainštalovať plugin a získať nulový výpadok nasadenia vašej aplikácie s dockerom, monitorovaním a ďalšími vychytávkami hneď po vybalení. Aby ste mohli napísať playbook, musíte vedieť, čo presne chcete robiť a ako to urobiť. Preto nie som spokojný s hotovými playbookmi z GitHubu alebo článkami typu: „Skopíruj a spustite, bude to fungovať.“
Čo potrebujeme?
Ako som už povedal, na to, aby ste mohli napísať knihu, musíte vedieť, čo chcete robiť a ako to robiť. Rozhodnime sa, čo potrebujeme. Pre aplikáciu Rails budeme potrebovať niekoľko systémových balíkov: nginx, postgresql (redis, atď.). Okrem toho potrebujeme špecifickú verziu rubínu. Najlepšie je nainštalovať cez rbenv (rvm, asdf...). Spúšťať toto všetko ako používateľ root je vždy zlý nápad, takže musíte vytvoriť samostatného používateľa a nakonfigurovať jeho práva. Potom musíte nahrať náš kód na server, skopírovať konfigurácie pre nginx, postgres atď. a spustiť všetky tieto služby.
V dôsledku toho je postupnosť akcií nasledovná:
- Prihláste sa ako root
- nainštalovať systémové balíky
- vytvoriť nového používateľa, nakonfigurovať práva, kľúč ssh
- nakonfigurujte systémové balíky (nginx atď.) a spustite ich
- Vytvoríme používateľa v databáze (databázu môžete vytvoriť okamžite)
- Prihláste sa ako nový používateľ
- Nainštalujte rbenv a ruby
- Inštalácia zväzovača
- Nahrávanie kódu aplikácie
- Spustenie servera Puma
Navyše, posledné fázy je možné vykonať pomocou capistrano, aspoň po vybalení dokáže skopírovať kód do adresárov vydania, prepnúť vydanie pomocou symbolického odkazu po úspešnom nasadení, skopírovať konfigurácie zo zdieľaného adresára, reštartovať pumu atď. To všetko sa dá urobiť pomocou Ansible, ale prečo?
Štruktúra súboru
Ansible má prísny
Jednoduchá príručka
Playbook je súbor yml, ktorý pomocou špeciálnej syntaxe popisuje, čo má Ansible robiť a ako. Poďme vytvoriť prvú príručku, ktorá nič nerobí:
---
- name: Simple playbook
hosts: all
Tu jednoducho povieme, že náš playbook sa volá Simple Playbook
a že jeho obsah by sa mal spustiť pre všetkých hostiteľov. Môžeme ho uložiť do adresára /ansible s názvom playbook.yml
a skús spustiť:
ansible-playbook ./playbook.yml
PLAY [Simple Playbook] ************************************************************************************************************************************
skipping: no hosts matched
Ansible hovorí, že nepozná žiadnych hostiteľov, ktorí zodpovedajú zoznamu všetkých. Musia byť uvedené v osobitnom
Vytvorme ho v rovnakom adresári ansible:
123.123.123.123
Takto jednoducho určíme hostiteľa (ideálne hostiteľa nášho VPS na testovanie, alebo si môžete zaregistrovať localhost) a uložíme ho pod názvom inventory
.
Môžete skúsiť spustiť ansible so súborom inventára:
ansible-playbook ./playbook.yml -i inventory
PLAY [Simple Playbook] ************************************************************************************************************************************
TASK [Gathering Facts] ************************************************************************************************************************************
PLAY RECAP ************************************************************************************************************************************
Ak máte ssh prístup k určenému hostiteľovi, potom sa ansible pripojí a zhromaždí informácie o vzdialenom systéme. (predvolená ÚLOHA [Gathering Facts]), po ktorej vydá krátku správu o vykonaní (PLAY RECAP).
Štandardne sa pri pripojení používa používateľské meno, pod ktorým ste prihlásený do systému. S najväčšou pravdepodobnosťou to nebude na hostiteľovi. V súbore playbook môžete pomocou direktívy remote_user určiť, ktorý používateľ sa má použiť na pripojenie. Informácie o vzdialenom systéme môžu byť pre vás často zbytočné a nemali by ste strácať čas ich zhromažďovaním. Túto úlohu možno tiež deaktivovať:
---
- name: Simple playbook
hosts: all
remote_user: root
become: true
gather_facts: no
Skúste znova spustiť príručku a uistite sa, že pripojenie funguje. (Ak ste zadali užívateľa typu root, musíte zadať aj príkaz stať: true, aby ste získali zvýšené práva. Ako je napísané v dokumentácii: become set to ‘true’/’yes’ to activate privilege escalation.
aj keď nie je celkom jasné prečo).
Možno dostanete chybu spôsobenú skutočnosťou, že ansible nemôže určiť interpret Pythonu, potom ho môžete zadať ručne:
ansible_python_interpreter: /usr/bin/python3
Pomocou príkazu zistíte, kde máte python whereis python
.
Inštalácia systémových balíkov
Štandardná distribúcia Ansible obsahuje mnoho modulov pre prácu s rôznymi systémovými balíkmi, takže nemusíme z akéhokoľvek dôvodu písať bash skripty. Teraz potrebujeme jeden z týchto modulov na aktualizáciu systému a inštaláciu systémových balíkov. Na svojom VPS mám Ubuntu Linux, takže na inštaláciu balíkov používam apt-get
и
Doplňme našu príručku o prvé úlohy:
---
- name: Simple playbook
hosts: all
remote_user: root
become: true
gather_facts: no
tasks:
- name: Update system
apt: update_cache=yes
- name: Install system dependencies
apt:
name: git,nginx,redis,postgresql,postgresql-contrib
state: present
Úloha je presne tá úloha, ktorú Ansible vykoná na vzdialených serveroch. Úlohe dáme názov, aby sme mohli sledovať jej vykonanie v protokole. A pomocou syntaxe konkrétneho modulu popíšeme, čo má robiť. V tomto prípade apt: update_cache=yes
- hovorí o aktualizácii systémových balíkov pomocou modulu apt. Druhý príkaz je trochu komplikovanejší. Odovzdáme modul apt zoznam balíkov a povieme, že sú state
by sa mal stať present
, to znamená, že nainštalujte tieto balíky. Podobným spôsobom im môžeme povedať, aby ich vymazali, alebo ich jednoduchou zmenou aktualizovali state
. Upozorňujeme, že na to, aby koľajnice fungovali s postgresql, potrebujeme balík postgresql-contrib, ktorý práve inštalujeme. Opäť to musíte vedieť a urobiť to; ansible to sám o sebe neurobí.
Skúste znova spustiť príručku a skontrolujte, či sú balíky nainštalované.
Vytváranie nových používateľov.
Pre prácu s používateľmi má Ansible aj modul – používateľ. Pridajme ešte jednu úlohu (už známe časti playbooku som schoval za komentáre, aby som ho zakaždým nekopíroval celý):
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: my_user
shell: /bin/bash
password: "{{ 123qweasd | password_hash('sha512') }}"
Vytvoríme nového užívateľa, nastavíme mu schému a heslo. A potom narazíme na niekoľko problémov. Čo ak sa musia používateľské mená pre rôznych hostiteľov líšiť? A ukladanie hesla v čistom texte v playbooku je veľmi zlý nápad. Na začiatok dáme používateľské meno a heslo do premenných a na konci článku ukážem, ako heslo zašifrovať.
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
Premenné sú nastavené v zošitoch pomocou dvojitých zložených zátvoriek.
Hodnoty premenných uvedieme v inventárnom súbore:
123.123.123.123
[all:vars]
user=my_user
user_password=123qweasd
Vezmite prosím na vedomie smernicu [all:vars]
- hovorí, že ďalším blokom textu sú premenné (vars) a sú použiteľné pre všetkých hostiteľov (všetky).
Zaujímavý je aj dizajn "{{ user_password | password_hash('sha512') }}"
. Ide o to, že ansible nenainštaluje užívateľa cez user_add
ako by ste to robili ručne. A všetky dáta ukladá priamo, preto musíme heslo vopred previesť na hash, čo robí tento príkaz.
Pridajme nášho používateľa do skupiny sudo. Predtým sa však musíme uistiť, že takáto skupina existuje, pretože to za nás nikto neurobí:
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Ensure a 'sudo' group
group:
name: sudo
state: present
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
groups: "sudo"
Všetko je celkom jednoduché, máme tu aj skupinový modul na vytváranie skupín, so syntaxou veľmi podobnou apt. Potom už stačí túto skupinu používateľovi zaregistrovať (groups: "sudo"
).
Je tiež užitočné pridať tomuto používateľovi kľúč ssh, aby sme sa pomocou neho mohli prihlásiť bez hesla:
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Ensure a 'sudo' group
group:
name: sudo
state: present
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
groups: "sudo"
- name: Deploy SSH Key
authorized_key:
user: "{{ user }}"
key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
state: present
V tomto prípade je zaujímavý dizajn "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
— skopíruje obsah súboru id_rsa.pub (vaše meno sa môže líšiť), teda verejnú časť kľúča ssh a nahrá ho do zoznamu autorizovaných kľúčov pre používateľa na serveri.
role
Všetky tri úlohy na vytváranie použitia sa dajú jednoducho zaradiť do jednej skupiny úloh a túto skupinu by bolo dobré uložiť oddelene od hlavného playbooku, aby sa príliš nezväčšila. Na tento účel má Ansible
Podľa štruktúry súborov uvedenej na úplnom začiatku musia byť role umiestnené v samostatnom adresári rolí, pre každú rolu existuje samostatný adresár s rovnakým názvom, v adresári úloh, súborov, šablón atď.
Vytvorme štruktúru súboru: ./ansible/roles/user/tasks/main.yml
(main je hlavný súbor, ktorý sa načíta a spustí, keď je rola pripojená k playbooku; možno k nemu pripojiť ďalšie súbory rolí). Teraz môžete do tohto súboru preniesť všetky úlohy súvisiace s používateľom:
# Create user and add him to groups
- name: Ensure a 'sudo' group
group:
name: sudo
state: present
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
groups: "sudo"
- name: Deploy SSH Key
authorized_key:
user: "{{ user }}"
key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
state: present
V hlavnej príručke musíte zadať, aby ste použili rolu používateľa:
---
- name: Simple playbook
hosts: all
remote_user: root
gather_facts: no
tasks:
- name: Update system
apt: update_cache=yes
- name: Install system dependencies
apt:
name: git,nginx,redis,postgresql,postgresql-contrib
state: present
roles:
- user
Tiež môže mať zmysel aktualizovať systém pred všetkými ostatnými úlohami; na tento účel môžete premenovať blok tasks
v ktorom sú definované v pre_tasks
.
Nastavenie nginx
Nginx by sme už mali mať nainštalovaný, musíme ho nakonfigurovať a spustiť. Urobme to hneď v úlohe. Vytvorme štruktúru súboru:
- ansible
- roles
- nginx
- files
- tasks
- main.yml
- templates
Teraz potrebujeme súbory a šablóny. Rozdiel medzi nimi je v tom, že ansible kopíruje súbory priamo, tak ako je. Šablóny musia mať príponu j2 a môžu používať premenné hodnoty pomocou rovnakých dvojitých zložených zátvoriek.
Povoľme nginx in main.yml
súbor. Na to máme systémový modul:
# Copy nginx configs and start it
- name: enable service nginx and start
systemd:
name: nginx
state: started
enabled: yes
Tu nielen hovoríme, že nginx musí byť spustený (to znamená, že ho spustíme), ale hneď hovoríme, že musí byť povolený.
Teraz skopírujeme konfiguračné súbory:
# Copy nginx configs and start it
- name: enable service nginx and start
systemd:
name: nginx
state: started
enabled: yes
- name: Copy the nginx.conf
copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: '0644'
backup: yes
- name: Copy template my_app.conf
template:
src: my_app_conf.j2
dest: /etc/nginx/sites-available/my_app.conf
owner: root
group: root
mode: '0644'
Vytvárame hlavný konfiguračný súbor nginx (môžete ho prevziať priamo zo servera alebo si ho napísať sami). A tiež konfiguračný súbor pre našu aplikáciu v adresári sites_available (nie je to potrebné, ale užitočné). V prvom prípade použijeme na kopírovanie súborov modul kopírovania (súbor musí byť v /ansible/roles/nginx/files/nginx.conf
). V druhom skopírujeme šablónu a nahradíme hodnoty premenných. Šablóna by mala byť in /ansible/roles/nginx/templates/my_app.j2
). A môže to vyzerať nejako takto:
upstream {{ app_name }} {
server unix:{{ app_path }}/shared/tmp/sockets/puma.sock;
}
server {
listen 80;
server_name {{ server_name }} {{ inventory_hostname }};
root {{ app_path }}/current/public;
try_files $uri/index.html $uri.html $uri @{{ app_name }};
....
}
Venujte pozornosť vložkám {{ app_name }}
, {{ app_path }}
, {{ server_name }}
, {{ inventory_hostname }}
— toto sú všetky premenné, ktorých hodnoty Ansible pred kopírovaním nahradí do šablóny. Je to užitočné, ak používate príručku pre rôzne skupiny hostiteľov. Napríklad môžeme pridať náš inventárny súbor:
[production]
123.123.123.123
[staging]
231.231.231.231
[all:vars]
user=my_user
user_password=123qweasd
[production:vars]
server_name=production
app_path=/home/www/my_app
app_name=my_app
[staging:vars]
server_name=staging
app_path=/home/www/my_stage
app_name=my_stage_app
Ak teraz spustíme našu príručku, vykoná zadané úlohy pre oboch hostiteľov. Zároveň sa však pre hostiteľa inscenácie budú premenné líšiť od produkčných, a to nielen v rolách a playbookoch, ale aj v konfiguráciách nginx. {{ inventory_hostname }}
nemusia byť uvedené v inventárnom spise - toto
Ak chcete mať súbor inventára pre niekoľko hostiteľov, ale spustiť iba pre jednu skupinu, môžete to urobiť pomocou nasledujúceho príkazu:
ansible-playbook -i inventory ./playbook.yml -l "staging"
Ďalšou možnosťou je mať samostatné súbory inventára pre rôzne skupiny. Alebo môžete tieto dva prístupy skombinovať, ak máte veľa rôznych hostiteľov.
Vráťme sa k nastaveniu nginx. Po skopírovaní konfiguračných súborov musíme v sitetest_enabled vytvoriť symbolický odkaz na my_app.conf z lokality sites_available. A reštartujte nginx.
... # old code in mail.yml
- name: Create symlink to sites-enabled
file:
src: /etc/nginx/sites-available/my_app.conf
dest: /etc/nginx/sites-enabled/my_app.conf
state: link
- name: restart nginx
service:
name: nginx
state: restarted
Všetko je tu jednoduché - opäť ansible moduly s pomerne štandardnou syntaxou. Ale je tu jeden bod. Nemá zmysel zakaždým reštartovať nginx. Všimli ste si, že nepíšeme príkazy ako: „urob to takto“, syntax vyzerá skôr ako „toto by malo mať tento stav“. A najčastejšie presne takto funguje ansible. Ak skupina už existuje alebo je už nainštalovaný systémový balík, ansible to skontroluje a preskočí úlohu. Súbory sa tiež neskopírujú, ak sa úplne zhodujú s tým, čo je už na serveri. Môžeme to využiť a reštartovať nginx iba v prípade, že boli zmenené konfiguračné súbory. Na to existuje smernica o registri:
# Copy nginx configs and start it
- name: enable service nginx and start
systemd:
name: nginx
state: started
enabled: yes
- name: Copy the nginx.conf
copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: '0644'
backup: yes
register: restart_nginx
- name: Copy template my_app.conf
template:
src: my_app_conf.j2
dest: /etc/nginx/sites-available/my_app.conf
owner: root
group: root
mode: '0644'
register: restart_nginx
- name: Create symlink to sites-enabled
file:
src: /etc/nginx/sites-available/my_app.conf
dest: /etc/nginx/sites-enabled/my_app.conf
state: link
- name: restart nginx
service:
name: nginx
state: restarted
when: restart_nginx.changed
Ak sa zmení jeden z konfiguračných súborov, vytvorí sa kópia a premenná sa zaregistruje restart_nginx
. A iba ak bola táto premenná zaregistrovaná, služba sa reštartuje.
A, samozrejme, musíte pridať rolu nginx do hlavnej príručky.
Nastavenie postgresql
Musíme povoliť postgresql pomocou systemd rovnakým spôsobom, ako sme to urobili s nginx, a tiež vytvoriť používateľa, ktorého budeme používať na prístup k databáze a samotnej databáze.
Vytvorme rolu /ansible/roles/postgresql/tasks/main.yml
:
# Create user in postgresql
- name: enable postgresql and start
systemd:
name: postgresql
state: started
enabled: yes
- name: Create database user
become_user: postgres
postgresql_user:
name: "{{ db_user }}"
password: "{{ db_password }}"
role_attr_flags: SUPERUSER
- name: Create database
become_user: postgres
postgresql_db:
name: "{{ db_name }}"
encoding: UTF-8
owner: "{{ db_user }}"
Nebudem popisovať, ako pridať premenné do inventára, to už bolo urobené veľakrát, rovnako ako syntax modulov postgresql_db a postgresql_user. Viac informácií nájdete v dokumentácii. Tu je najzaujímavejšia smernica become_user: postgres
. Faktom je, že štandardne má prístup k databáze postgresql iba používateľ postgres a iba lokálne. Táto smernica nám umožňuje vykonávať príkazy v mene tohto používateľa (samozrejme, ak máme prístup).
Možno budete musieť pridať riadok do pg_hba.conf, aby ste umožnili novému používateľovi prístup k databáze. Dá sa to urobiť rovnakým spôsobom, ako sme zmenili konfiguráciu nginx.
A samozrejme, musíte pridať postgresql úlohu do hlavnej príručky.
Inštalácia ruby cez rbenv
Ansible nemá moduly na prácu s rbenv, ale inštaluje sa naklonovaním git repozitára. Preto sa tento problém stáva najneštandardnejším. Vytvorme pre ňu rolu /ansible/roles/ruby_rbenv/main.yml
a začneme ho vypĺňať:
# Install rbenv and ruby
- name: Install rbenv
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv
Opäť používame direktívu stať sa_užívateľom, aby sme fungovali pod používateľom, ktorého sme na tieto účely vytvorili. Keďže rbenv je nainštalovaný vo svojom domovskom adresári, a nie globálne. A tiež používame modul git na klonovanie úložiska, pričom špecifikujeme repo a dest.
Ďalej musíme zaregistrovať rbenv init v bashrc a tam pridať rbenv do PATH. Na to máme modul lineinfile:
- name: Add rbenv to PATH
become_user: "{{ user }}"
lineinfile:
path: ~/.bashrc
state: present
line: 'export PATH="${HOME}/.rbenv/bin:${PATH}"'
- name: Add rbenv init to bashrc
become_user: "{{ user }}"
lineinfile:
path: ~/.bashrc
state: present
line: 'eval "$(rbenv init -)"'
Potom musíte nainštalovať ruby_build:
- name: Install ruby-build
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build
A nakoniec nainštalujte ruby. To sa deje prostredníctvom rbenv, teda jednoducho pomocou príkazu bash:
- name: Install ruby
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
rbenv install {{ ruby_version }}
args:
executable: /bin/bash
Hovoríme, ktorý príkaz vykonať a čím. Tu však narážame na fakt, že ansible pred spustením príkazov nespustí kód obsiahnutý v bashrc. To znamená, že rbenv bude musieť byť definovaný priamo v tom istom skripte.
Ďalší problém je spôsobený skutočnosťou, že príkaz shell nemá z ansible hľadiska žiadny stav. To znamená, že nebude automatická kontrola, či je táto verzia ruby nainštalovaná alebo nie. Môžeme to urobiť sami:
- name: Install ruby
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
if ! rbenv versions | grep -q {{ ruby_version }}
then rbenv install {{ ruby_version }} && rbenv global {{ ruby_version }}
fi
args:
executable: /bin/bash
Zostáva len nainštalovať bundler:
- name: Install bundler
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
gem install bundler
A opäť pridajte našu rolu ruby_rbenv do hlavnej príručky.
Zdieľané súbory.
Vo všeobecnosti tu môžete dokončiť nastavenie. Ďalej už zostáva len spustiť capistrano a to si sám skopíruje kód, vytvorí potrebné adresáre a spustí aplikáciu (ak je všetko správne nakonfigurované). Capistrano však často vyžaduje dodatočné konfiguračné súbory, ako napr database.yml
alebo .env
Dajú sa skopírovať rovnako ako súbory a šablóny pre nginx. Je tu len jedna jemnosť. Pred kopírovaním súborov musíte pre ne vytvoriť adresárovú štruktúru, napríklad:
# Copy shared files for deploy
- name: Ensure shared dir
become_user: "{{ user }}"
file:
path: "{{ app_path }}/shared/config"
state: directory
zadáme iba jeden adresár a ansible v prípade potreby automaticky vytvorí nadradený.
Ansible Vault
Už sme sa stretli s tým, že premenné môžu obsahovať tajné údaje, ako napríklad heslo používateľa. Ak ste vytvorili .env
súbor k žiadosti a database.yml
potom musí byť takýchto kritických údajov ešte viac. Bolo by dobré ich skryť pred zvedavými očami. Na tento účel sa používa
Vytvorme súbor pre premenné /ansible/vars/all.yml
(tu môžete vytvoriť rôzne súbory pre rôzne skupiny hostiteľov, rovnako ako v súbore inventára: production.yml, staging.yml atď.).
Všetky premenné, ktoré musia byť zašifrované, musia byť prenesené do tohto súboru pomocou štandardnej syntaxe yml:
# System vars
user_password: 123qweasd
db_password: 123qweasd
# ENV vars
aws_access_key_id: xxxxx
aws_secret_access_key: xxxxxx
aws_bucket: bucket_name
rails_secret_key_base: very_secret_key_base
Potom je možné tento súbor zašifrovať príkazom:
ansible-vault encrypt ./vars/all.yml
Pri šifrovaní budete samozrejme musieť nastaviť heslo na dešifrovanie. Po zavolaní tohto príkazu môžete vidieť, čo bude v súbore.
Prostredníctvom ansible-vault decrypt
súbor je možné dešifrovať, upraviť a potom znova zašifrovať.
Aby ste mohli pracovať, nemusíte súbor dešifrovať. Uložíte ho zašifrovaný a spustíte playbook s argumentom --ask-vault-pass
. Ansible požiada o heslo, získa premenné a vykoná úlohy. Všetky dáta zostanú zašifrované.
Kompletný príkaz pre niekoľko skupín hostiteľov a ansible vault bude vyzerať asi takto:
ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass
Ale nedám vám celý text zošitov a rolí, napíšte si to sami. Pretože ansible je taký - ak nerozumiete tomu, čo je potrebné urobiť, neurobí to za vás.
Zdroj: hab.com