Mitte kaua aega tagasi oli mul vaja kirjutada mitu Ansible'i mänguraamatut, et valmistada server ette Railsi rakenduse juurutamiseks. Ja üllataval kombel ei leidnud ma lihtsat samm-sammult käsiraamatut. Ma ei tahtnud kopeerida kellegi teise mänguraamatut, mõistmata, mis toimub, ja lõpuks pidin lugema dokumentatsiooni, kogudes kõik ise kokku. Võib-olla saan aidata kellelgi selle artikli abil seda protsessi kiirendada.
Esimene asi, mida tuleb mõista, on see, et ansible pakub teile mugavat liidest, mille abil saate SSH-i kaudu kaugserveris(t)es teha eelmääratletud toimingute loendi. Siin pole mingit maagiat, te ei saa installida pistikprogrammi ega saada oma rakendust ilma seisakuta koos doki, seire ja muude hüvedega karbist välja. Mänguraamatu kirjutamiseks peate teadma, mida täpselt soovite teha ja kuidas seda teha. Seetõttu ei ole ma rahul GitHubi valmis juhendite ega artiklitega nagu "Kopeeri ja käivita, see töötab."
Mida me vajame?
Nagu ma juba ütlesin, peate mänguraamatu kirjutamiseks teadma, mida soovite teha ja kuidas seda teha. Otsustame, mida vajame. Railsi rakenduse jaoks vajame mitut süsteemipaketti: nginx, postgresql (redis jne). Lisaks vajame rubiini spetsiifilist versiooni. Kõige parem on see installida rbenv kaudu (rvm, asdf...). Kõige selle juurkasutajana käitamine on alati halb mõte, seega tuleb luua eraldi kasutaja ja seadistada tema õigused. Pärast seda peate meie koodi serverisse üles laadima, kopeerima nginxi, postgresi jne konfiguratsioonid ja käivitama kõik need teenused.
Selle tulemusena on toimingute jada järgmine:
- Logi sisse administraatorina
- installige süsteemipaketid
- loo uus kasutaja, seadista õigused, ssh-võti
- konfigureerige süsteemipaketid (nginx jne) ja käivitage need
- Loome andmebaasis kasutaja (andmebaasi saate kohe luua)
- Logi sisse uue kasutajana
- Installige rbenv ja ruby
- Kimpu paigaldamine
- Rakenduse koodi üleslaadimine
- Puma serveri käivitamine
Veelgi enam, viimaseid etappe saab teha capistrano abil, vähemalt karbist välja võttes saab see kopeerida koodi väljalaskekataloogidesse, vahetada väljalaske edukal juurutamisel symlinkiga, kopeerida konfiguratsioone jagatud kataloogist, taaskäivitada puma jne. Seda kõike saab teha Ansible abil, aga miks?
Faili struktuur
Ansible on range
Lihtne mänguraamat
Playbook on yml-fail, mis spetsiaalse süntaksi abil kirjeldab, mida ja kuidas Ansible peaks tegema. Loome esimese mänguraamatu, mis ei tee midagi:
---
- name: Simple playbook
hosts: all
Siin ütleme lihtsalt, et meie mänguraamat on nn Simple Playbook
ja et selle sisu tuleks käivitada kõigi hostide jaoks. Saame selle nimega salvestada kataloogi /ansible playbook.yml
ja proovige joosta:
ansible-playbook ./playbook.yml
PLAY [Simple Playbook] ************************************************************************************************************************************
skipping: no hosts matched
Ansible ütleb, et ta ei tea ühtegi hosti, mis vastaks kõigi loendile. Need peavad olema eriloendis loetletud
Loome selle samasse võimalikku kataloogi:
123.123.123.123
Nii me lihtsalt määrame hosti (ideaaljuhul meie VPS-i hosti testimiseks või võite registreerida kohaliku hosti) ja salvestame selle nime alla inventory
.
Võite proovida käivitada ansible koos inventuurifailiga:
ansible-playbook ./playbook.yml -i inventory
PLAY [Simple Playbook] ************************************************************************************************************************************
TASK [Gathering Facts] ************************************************************************************************************************************
PLAY RECAP ************************************************************************************************************************************
Kui teil on määratud hostile ssh-juurdepääs, loob ansible ühenduse ja kogub teavet kaugsüsteemi kohta. (vaikeülesanne [Faktide kogumine]), misjärel esitab see täitmise kohta lühikese aruande (PLAY RECAP).
Vaikimisi kasutab ühendus kasutajanime, mille all olete süsteemi sisse logitud. Tõenäoliselt ei ole see hostis. Mänguraamatu failis saate määrata, millist kasutajat kasutada ühenduse loomiseks, kasutades käskkirja remote_user. Samuti võib teave kaugsüsteemi kohta sageli olla teile ebavajalik ja te ei tohiks selle kogumisele aega raisata. Selle ülesande saab ka keelata:
---
- name: Simple playbook
hosts: all
remote_user: root
become: true
gather_facts: no
Proovige mänguraamatut uuesti käivitada ja veenduge, et ühendus töötab. (Kui määrasite juurkasutaja, siis peate kõrgendatud õiguste saamiseks määrama ka käsu muutuda: true. Nagu dokumentatsioonis kirjas: become set to ‘true’/’yes’ to activate privilege escalation.
kuigi pole täiesti selge, miks).
Võib-olla kuvatakse teile tõrketeade, mille põhjuseks on asjaolu, et ansible ei suuda Pythoni tõlgendajat määrata, siis saate selle käsitsi määrata:
ansible_python_interpreter: /usr/bin/python3
Käsuga saate teada, kus teil python on whereis python
.
Süsteemipakettide installimine
Ansible standarddistributsioon sisaldab palju mooduleid erinevate süsteemipakettidega töötamiseks, nii et me ei pea mingil põhjusel bash-skripte kirjutama. Nüüd vajame ühte neist moodulitest süsteemi värskendamiseks ja süsteemipakettide installimiseks. Minu VPS-is on Ubuntu Linux, seega kasutan pakettide installimiseks apt-get
и
Täiendame oma mänguraamatut esimeste ülesannetega:
---
- 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
Ülesanne on täpselt see ülesanne, mida Ansible kaugserverites täidab. Anname ülesandele nime, et saaksime selle täitmist logis jälgida. Ja me kirjeldame konkreetse mooduli süntaksi abil, mida see tegema peab. Sel juhul apt: update_cache=yes
- ütleb süsteemipakettide värskendamiseks apt mooduli abil. Teine käsk on veidi keerulisem. Edastame pakettide loendi apt-moodulile ja ütleme, et need on nii state
peaks saama present
, see tähendab, et installige need paketid. Samamoodi saame käskida neil need kustutada või lihtsalt muutes värskendada state
. Pange tähele, et rööbaste töötamiseks postgresql-iga vajame paketti postgresql-contrib, mida me praegu installime. Jällegi peate seda teadma ja tegema; ansible üksi seda ei tee.
Proovige mänguraamatut uuesti käivitada ja kontrollige, kas paketid on installitud.
Uute kasutajate loomine.
Kasutajatega töötamiseks on Ansiblel ka moodul – kasutaja. Lisame veel ühe ülesande (peitsin mänguraamatu juba teadaolevad osad kommentaaride taha, et mitte iga kord tervenisti kopeerida):
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: my_user
shell: /bin/bash
password: "{{ 123qweasd | password_hash('sha512') }}"
Loome uue kasutaja, määrame sellele shelli ja parooli. Ja siis puutume kokku mitme probleemiga. Mis siis, kui erinevate hostide kasutajanimed peavad olema erinevad? Ja parooli salvestamine selge tekstina mänguraamatusse on väga halb mõte. Alustuseks paneme kasutajanime ja parooli muutujateks ning artikli lõpupoole näitan, kuidas parooli krüptida.
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
Muutujad määratakse mänguraamatutes topeltkõverate sulgude abil.
Näitame inventuurifailis muutujate väärtused:
123.123.123.123
[all:vars]
user=my_user
user_password=123qweasd
Pange tähele direktiivi [all:vars]
- see ütleb, et järgmine tekstiplokk on muutujad (vars) ja need on rakendatavad kõikidele hostidele (kõikidele).
Disain on ka huvitav "{{ user_password | password_hash('sha512') }}"
. Asi on selles, et ansible ei installi kasutajat selle kaudu user_add
nagu teeksite seda käsitsi. Ja see salvestab kõik andmed otse, mistõttu peame ka parooli eelnevalt räsi muutma, mida see käsk teeb.
Lisame oma kasutaja sudo gruppi. Kuid enne seda peame veenduma, et selline rühm on olemas, sest keegi ei tee seda meie eest:
---
- 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"
Kõik on üsna lihtne, meil on rühmade loomiseks ka grupimoodul, mille süntaks on väga sarnane apt-le. Siis piisab selle grupi registreerimisest kasutajale (groups: "sudo"
).
Samuti on kasulik lisada sellele kasutajale ssh-võti, et saaksime seda kasutades sisse logida ilma paroolita:
---
- 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
Sel juhul on disain huvitav "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
— kopeerib faili id_rsa.pub sisu (teie nimi võib olla erinev), st ssh-võtme avaliku osa ja laadib selle üles serveris kasutaja jaoks volitatud võtmete loendisse.
Rollid
Kõik kolm kasutuse loomise ülesannet saab hõlpsasti liigitada ühte ülesannete rühma ja see rühm oleks hea salvestada põhimänguraamatust eraldi, et see liiga suureks ei kasvaks. Selleks on Ansible
Vastavalt kohe alguses märgitud failistruktuurile tuleb rollid paigutada eraldi rollide kataloogi, iga rolli jaoks on eraldi samanimeline kataloog ülesannete, failide, mallide jne kataloogis
Loome failistruktuuri: ./ansible/roles/user/tasks/main.yml
(main on peamine fail, mis laaditakse ja käivitatakse, kui roll on mänguraamatuga ühendatud; sellega saab ühendada muid rollifaile). Nüüd saate kõik kasutajaga seotud ülesanded sellesse faili üle kanda:
# 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
Peamises mänguraamatus peate kasutajarolli kasutamiseks määrama:
---
- 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
Samuti võib olla mõttekas värskendada süsteemi enne kõiki muid toiminguid; selleks saate ploki ümber nimetada tasks
milles need on määratletud pre_tasks
.
Nginxi seadistamine
Meil peaks olema juba installitud Nginx; peame selle konfigureerima ja käivitama. Teeme seda kohe rollis. Loome failistruktuuri:
- ansible
- roles
- nginx
- files
- tasks
- main.yml
- templates
Nüüd vajame faile ja malle. Nende erinevus seisneb selles, et ansible kopeerib failid otse, nagu on. Ja mallidel peab olema laiend j2 ja nad saavad kasutada muutuvaid väärtusi, kasutades samu topeltkõveraid sulgusid.
Lubame nginxi sisse main.yml
faili. Selleks on meil süsteemne moodul:
# Copy nginx configs and start it
- name: enable service nginx and start
systemd:
name: nginx
state: started
enabled: yes
Siin me mitte ainult ei ütle, et nginx tuleb käivitada (st käivitame selle), vaid ütleme kohe, et see peab olema lubatud.
Nüüd kopeerime konfiguratsioonifailid:
# 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'
Loome peamise nginxi konfiguratsioonifaili (saate selle otse serverist võtta või ise kirjutada). Ja ka meie rakenduse konfiguratsioonifail kataloogis sites_available (see pole vajalik, kuid kasulik). Esimesel juhul kasutame failide kopeerimiseks kopeerimismoodulit (fail peab olema sees /ansible/roles/nginx/files/nginx.conf
). Teises kopeerime malli, asendades muutujate väärtused. Mall peaks sees olema /ansible/roles/nginx/templates/my_app.j2
). Ja see võib välja näha umbes selline:
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 }};
....
}
Pöörake tähelepanu sisestustele {{ app_name }}
, {{ app_path }}
, {{ server_name }}
, {{ inventory_hostname }}
— need on kõik muutujad, mille väärtused Ansible asendavad malli enne kopeerimist. See on kasulik, kui kasutate erinevate võõrustajate rühmade jaoks mänguraamatut. Näiteks saame lisada oma laofaili:
[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
Kui käivitame nüüd oma mänguraamatu, täidab see mõlema hosti jaoks määratud ülesandeid. Kuid samal ajal on lavastusjuhi jaoks muutujad tootmisomadustest erinevad ja mitte ainult rollides ja mänguraamatutes, vaid ka nginxi konfiguratsioonides. {{ inventory_hostname }}
ei pea inventuurifailis täpsustama – see
Kui soovite andmefaili mitme hosti jaoks, kuid soovite töötada ainult ühe rühma jaoks, saate seda teha järgmise käsuga:
ansible-playbook -i inventory ./playbook.yml -l "staging"
Teine võimalus on eri rühmade jaoks eraldi laofailid. Või võite need kaks lähenemisviisi kombineerida, kui teil on palju erinevaid hoste.
Läheme tagasi nginxi seadistamise juurde. Pärast konfiguratsioonifailide kopeerimist peame failis sitest_enabled looma saidilt sites_available faili my_app.conf sümlingi. Ja taaskäivitage 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
Siin on kõik lihtne - jällegi võimalikud moodulid üsna standardse süntaksiga. Kuid on üks punkt. Pole mõtet nginxi iga kord taaskäivitada. Kas olete märganud, et me ei kirjuta selliseid käske nagu: "tee seda nii", süntaks näeb pigem välja selline: "sellel peaks olema selline olek". Ja enamasti töötab ansible täpselt nii. Kui rühm on juba olemas või süsteemipakett on juba installitud, kontrollib ansible seda ja jätab ülesande vahele. Samuti ei kopeerita faile, kui need vastavad täielikult serveris juba olevale. Saame seda ära kasutada ja nginxi taaskäivitada ainult siis, kui konfiguratsioonifaile on muudetud. Selle jaoks on olemas registri käskkiri:
# 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
Kui üks konfiguratsioonifailidest muutub, tehakse koopia ja muutuja registreeritakse restart_nginx
. Ja ainult siis, kui see muutuja on registreeritud, taaskäivitatakse teenus.
Ja loomulikult peate nginxi rolli lisama põhijuhendisse.
Postgresql seadistamine
Peame lubama postgresqli, kasutades systemd samamoodi nagu nginxi puhul, ning looma ka kasutaja, mida kasutame andmebaasile ja andmebaasile juurdepääsuks.
Loome rolli /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 }}"
Ma ei hakka kirjeldama, kuidas varudesse muutujaid lisada, seda on juba korduvalt tehtud, nagu ka postgresql_db ja postgresql_user moodulite süntaksit. Lisateavet leiate dokumentatsioonist. Kõige huvitavam direktiiv on siin become_user: postgres
. Fakt on see, et vaikimisi on postgresql-i andmebaasile juurdepääs ainult postgresi kasutajal ja ainult lokaalselt. See direktiiv võimaldab meil selle kasutaja nimel käske täita (muidugi juhul, kui meil on juurdepääs).
Samuti peate võib-olla lisama faili pg_hba.conf rea, et võimaldada uuel kasutajal andmebaasile juurdepääs. Seda saab teha samamoodi nagu me muutsime nginxi konfiguratsiooni.
Ja loomulikult peate põhijuhendisse lisama postgresqli rolli.
Rubiini paigaldamine rbenv kaudu
Ansiblel pole rbenv-ga töötamiseks mooduleid, kuid see installitakse git-hoidla kloonimise teel. Seetõttu muutub see probleem kõige ebastandardsemaks. Loome talle rolli /ansible/roles/ruby_rbenv/main.yml
ja hakkame seda täitma:
# Install rbenv and ruby
- name: Install rbenv
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv
Me kasutame jällegi käskkirja "muutu_kasutaja", et töötada selle kasutaja all, mille me nendel eesmärkidel lõime. Kuna rbenv on installitud selle kodukataloogi, mitte globaalselt. Samuti kasutame hoidla kloonimiseks git-moodulit, määrates repo ja sihtpunkti.
Järgmiseks peame registreerima rbenv init kataloogis bashrc ja lisama rbenv sinna PATH-i. Selleks on meil lineinfile moodul:
- 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 -)"'
Seejärel peate installima ruby_build:
- name: Install ruby-build
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build
Ja lõpuks installige rubiin. Seda tehakse rbenv kaudu, st lihtsalt käsuga 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
Me ütleme, millist käsku täita ja millega. Siin puutume aga kokku tõsiasjaga, et ansible ei käivita enne käskude käivitamist bashrc-is sisalduvat koodi. See tähendab, et rbenv tuleb määratleda otse samas skriptis.
Järgmine probleem on tingitud asjaolust, et shelli käsul puudub olek mõistlikust vaatepunktist. See tähendab, et automaatset kontrolli ei toimu, kas see rubiini versioon on installitud või mitte. Seda saame ise teha:
- 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
Jääb üle vaid komplekteerija installida:
- name: Install bundler
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
gem install bundler
Ja jälle lisage meie roll ruby_rbenv põhijuhendisse.
Jagatud failid.
Üldiselt võiks siin seadistamise lõpule viia. Järgmiseks jääb üle vaid käivitada capistrano ja see kopeerib ise koodi, loob vajalikud kataloogid ja käivitab rakenduse (kui kõik on õigesti seadistatud). Capistrano nõuab aga sageli täiendavaid konfiguratsioonifaile, nt database.yml
või .env
Neid saab kopeerida nagu nginxi faile ja malle. On ainult üks peensus. Enne failide kopeerimist peate looma nende jaoks kataloogistruktuuri, mis on umbes selline:
# Copy shared files for deploy
- name: Ensure shared dir
become_user: "{{ user }}"
file:
path: "{{ app_path }}/shared/config"
state: directory
me määrame ainult ühe kataloogi ja ansible loob vajadusel automaatselt vanemad kataloogid.
Ansible Vault
Oleme juba kohanud tõsiasja, et muutujad võivad sisaldada salajasi andmeid, näiteks kasutaja parooli. Kui olete loonud .env
taotluse faili ja database.yml
siis peab selliseid kriitilisi andmeid veelgi rohkem olema. Hea oleks neid võõraste pilkude eest varjata. Sel eesmärgil kasutatakse seda
Loome muutujate jaoks faili /ansible/vars/all.yml
(siin saab luua erinevaid faile erinevatele hostirühmadele, täpselt nagu laofailis: production.yml, staging.yml jne).
Kõik muutujad, mis tuleb krüpteerida, tuleb sellesse faili üle kanda standardse ymli süntaksi abil:
# 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
Pärast seda saab selle faili krüpteerida käsuga:
ansible-vault encrypt ./vars/all.yml
Loomulikult peate krüptimisel määrama dekrüpteerimiseks parooli. Pärast selle käsu kutsumist näete, mis faili sees on.
Abil ansible-vault decrypt
faili saab dekrüpteerida, muuta ja seejärel uuesti krüptida.
Töötamiseks ei pea te faili dekrüpteerima. Salvestate selle krüpteeritult ja käivitate selle argumendiga mänguraamatu --ask-vault-pass
. Ansible küsib parooli, hangib muutujad ja täidab ülesandeid. Kõik andmed jäävad krüpteerituks.
Mitme hostirühma ja ansible varahoidla täielik käsk näeb välja umbes selline:
ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass
Kuid ma ei anna teile näidendiraamatute ja rollide täisteksti, kirjutage see ise. Sest ansible on selline – kui sa ei saa aru, mida teha tuleb, siis ta seda sinu eest ei tee.
Allikas: www.habr.com