Micca tantu tempu, avia bisognu di scrive parechji libri di ghjocu ansible per preparà u servitore per implementà una applicazione rails. E, sorprendentemente, ùn aghju micca trovu un manuale simplice passu à passu. Ùn vulia micca copià u librettu di l'altru senza capisce ciò chì passava, è in u risultatu, aghju avutu à leghje a ducumentazione, cullendu tuttu per mè stessu. Forsi possu aiutà à qualchissia per accelerà stu prucessu cù l'aiutu di stu articulu.
A prima cosa da capisce hè chì ansible vi furnisce una interfaccia còmuda per realizà una lista predefinita di l'azzioni nantu à un servitore (s) remoto via SSH. Ùn ci hè micca magia quì, ùn pudete micca installà un plugin è uttene una implementazione zero downtime di a vostra applicazione cù docker, monitoraghju è altri boni fora di a scatula. Per scrive un playbook, avete bisognu di sapè esattamente ciò chì vulete fà è cumu fà. Dunque, ùn sò micca cuntentu di playbooks pronti da github, o articuli cum'è: "Copia è eseguite, funzionerà".
Chì avemu bisognu?
Comu dissi, per scrive un libru di ghjocu, avete bisognu di sapè ciò chì vulete fà è cumu fà. Decidemu ciò chì avemu bisognu. Per una applicazione Rails, avemu bisognu di parechji pacchetti di sistema: nginx, postgresql (redis, etc.). Inoltre, avemu bisognu di ruby di una certa versione. Hè megliu installallu cù rbenv (rvm, asdf...). Eseguisce tuttu questu cum'è un utilizatore root hè sempre una mala idea, cusì avete bisognu di creà un utilizatore separatu è stabilisce permessi per ellu. Dopu quì, avete bisognu di cullà u nostru codice à u servitore, copià a cunfigurazione per nginx, postgres, etc. è principià tutti questi servizii.
In u risultatu, a sequenza di l'azzioni hè a siguenti:
- Login sottu root
- installà i pacchetti di sistema
- creà un novu utilizatore, cunfigurà i diritti, chjave ssh
- cunfigurà i pacchetti di sistema (nginx etc.) è eseguite
- Crea un utilizatore in a basa di dati (pudete immediatamente creà una basa di dati)
- Login cum'è un novu utilizatore
- Installazione di rbenv è ruby
- Installazione di u bundler
- Caricà u codice di l'applicazione
- Cumincià u Puma Server
Inoltre, l'ultimi passi ponu esse fatti cù capistrano, almenu pò copià u codice per liberà i cartulari fora di a scatula, cambia a liberazione cù un ligame simbolicu dopu a implementazione successu, copià e cunfigurazioni da u cartulare spartutu, riavvia puma, etc. Tuttu chistu pò esse fattu cù Ansible, ma perchè?
Struttura di u schedariu
Ansible hà un strettu
libru di ghjocu simplice
Un playbook hè un schedariu yml chì descrive, utilizendu una sintassi speciale, ciò chì è cumu ansible deve fà. Creemu u primu playbook chì ùn faci nunda:
---
- name: Simple playbook
hosts: all
Quì dicemu solu chì u nostru playbook hè chjamatu Simple Playbook
è chì u so cuntenutu deve esse currettu per tutti l'ospiti. Pudemu almacenà in u cartulare / ansible chjamatu playbook.yml
è pruvate à curriri:
ansible-playbook ./playbook.yml
PLAY [Simple Playbook] ************************************************************************************************************************************
skipping: no hosts matched
Ansible dice chì ùn cunnosci micca alcun host chì currisponde à a lista di tutti. Anu deve esse listatu in un speciale
Creemu in u stessu annuariu ansible:
123.123.123.123
Hè cusì chì simpricimenti specifichi l'ospite (idealmente, l'ospite di u nostru VPS per i testi, o pudete registrà u locale host) è salvate sottu u nome inventory
.
Pudete pruvà à eseguisce ansible cù un schedariu d'inventariu:
ansible-playbook ./playbook.yml -i inventory
PLAY [Simple Playbook] ************************************************************************************************************************************
TASK [Gathering Facts] ************************************************************************************************************************************
PLAY RECAP ************************************************************************************************************************************
Sì avete accessu ssh à l'ospitu specificatu, allora ansible si cunnetta è raccoglie infurmazioni nantu à u sistema remoto. (TASK predeterminatu [Gathering Facts] ) dopu chì darà un riassuntu di l'esekzione (PLAY RECAP).
Per automaticamente, a cunnessione usa u nome d'utilizatore sottu à quale site cunnessu in u sistema. Hè assai prubabile, ùn serà micca nantu à l'ospite. In u schedariu di playbook, pudete specificà quale utilizatore per utilizà per cunnette cù a direttiva remote_user. Inoltre, l'infurmazioni nantu à un sistema remotu pò esse spessu innecessariu per voi è ùn avete micca perdi u tempu à cullà. Stu compitu pò ancu esse disattivatu:
---
- name: Simple playbook
hosts: all
remote_user: root
become: true
gather_facts: no
Pruvate torna u playbook è verificate chì a cunnessione funziona. (Se avete specificatu l'utilizatore root, allora avete bisognu di specificà u diventatu: vera direttiva per ottene diritti elevati. Cumu hè scrittu in a documentazione: become set to ‘true’/’yes’ to activate privilege escalation.
ancu s'ellu ùn hè micca chjaru perchè).
Forse vi uttene un errore causatu da u fattu chì ansible ùn pò micca determinà l'interprete python, allora pudete specificà manualmente:
ansible_python_interpreter: /usr/bin/python3
induve avete python, pudete truvà fora cù u cumandamentu whereis python
.
Installazione di pacchetti di sistema
A distribuzione standard di Ansible include assai moduli per travaglià cù diversi pacchetti di sistema, per quessa, ùn avemu micca bisognu di scrive script bash per qualsiasi ragione. Avà avemu bisognu di unu di sti moduli per aghjurnà u sistema è installà i pacchetti di sistema. Aghju Ubuntu Linux nantu à u mo VPS, cusì aghju utilizatu apt-get
и
Cumpitemu u nostru libru di ghjocu cù i primi compiti:
---
- 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
Task hè solu u compitu chì ansible farà nantu à i servitori remoti. Demu à u compitu un nome per seguità a so esecuzione in u log. E discrimu, utilizendu a sintassi di un modulu particulari, ciò chì deve fà. In stu casu apt: update_cache=yes
- dice di aghjurnà i pacchetti di u sistema utilizendu u modulu apt. U sicondu cumandamentu hè un pocu più cumplicatu. Passemu una lista di pacchetti à u modulu apt, è dicemu chì elli state
deve diventà present
, vale à dì, dicemu installate questi pacchetti. In listessu modu, pudemu dì à elli à sguassà, o aghjurnà, da solu cambià state
. Nota chì per i rails per travaglià cù postgresql, avemu bisognu di u pacchettu postgresql-contrib, chì avemu installatu attualmente. In novu, avete bisognu di sapè è fà questu, ansible da ellu stessu ùn farà micca questu.
Pruvate torna u playbook è verificate chì i pacchetti installati.
Creazione di novi utilizatori.
Per travaglià cù l'utilizatori, Ansible hà ancu un modulu - user. Aghjunghjite un compitu più (aghju ammucciatu e parti digià cunnisciute di u playbook daretu à i cumenti per ùn copià micca sanu sanu ogni volta):
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: my_user
shell: /bin/bash
password: "{{ 123qweasd | password_hash('sha512') }}"
Creemu un novu utilizatore, stabilisce una cunchiglia è una password per ellu. È dopu avemu incuntrà parechji prublemi. E se i nomi d'utilizatore duveranu esse sfarenti per diversi hosts? Iè, è almacenà a password in testu chjaru in u playbook hè una idea assai mala. Per principià, avemu da piglià u nome d'utilizatore è a password in variàbili, è versu a fine di l'articulu vi mustraraghju cumu si cripta a password.
---
- name: Simple playbook
# ...
tasks:
# ...
- name: Add a new user
user:
name: "{{ user }}"
shell: /bin/bash
password: "{{ user_password | password_hash('sha512') }}"
E variabili sò stabilite aduprendu parentesi doppia curly in playbooks.
Avemu da specificà i valori di e variàbili in u schedariu d'inventariu:
123.123.123.123
[all:vars]
user=my_user
user_password=123qweasd
Attenti à a direttiva [all:vars]
- ella dice chì u prossimu bloccu di testu hè variàbili (vars) è sò appiicati à tutti l'ospiti (tutti).
Ancu un disignu interessante "{{ user_password | password_hash('sha512') }}"
. U puntu hè chì ansible ùn stabilisce micca l'utilizatori via user_add
cum'è avete fattu manualmente. È salva tutti i dati direttamente, chì hè per quessa chì avemu ancu bisognu di cunvertisce a password in un hash in anticipu, chì questu cumanda faci.
Aghjunghjemu u nostru utilizatore à u gruppu sudo. Tuttavia, prima di quessa, avete bisognu di assicurà chì un tali gruppu esiste perchè nimu hà da fà questu per noi:
---
- 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"
Hè abbastanza simplice, avemu ancu un modulu di gruppu per creà gruppi, cù una sintassi assai simili à apt. Dopu questu, hè abbastanza per registrà stu gruppu à l'utilizatore (groups: "sudo"
).
Hè ancu utile per aghjunghje una chjave ssh à questu utilizatore in modu chì pudemu login senza password:
---
- 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
In questu casu, a custruzzione "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
- copia u cuntenutu di u schedariu id_rsa.pub (u vostru nome pò esse diversu), vale à dì, a parte publica di a chjave ssh è a carica in a lista di chjavi autorizati per l'utilizatore nantu à u servitore.
Ruoli
Tutti i trè compiti per creà l'usu pò esse facilmente attribuiti à u stessu gruppu di travagliu, è saria bellu di mantene stu gruppu separatu da u playbook principale per ùn cresce micca troppu. Per questu, ansible hà
Sicondu a struttura di u schedariu indicata à u principiu, i roli devenu esse posti in un repertoriu di roli separati, per ogni rolu ci hè un repertoriu separatu cù u stessu nome, in u repertoriu di funzioni, schedari, mudelli, etc.
Creemu una struttura di file: ./ansible/roles/user/tasks/main.yml
(principale hè u schedariu principale chì serà caricatu è eseguitu quandu u rolu hè cunnessu à u playbook, altri schedarii di rolu ponu esse cunnessi in questu). Avà vi ponu trasfiriri tutti i compiti riguardanti lu utilizatori à stu schedariu:
# 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
In u playbook principale, duvete specificà per utilizà u rolu d'utilizatore:
---
- 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
Inoltre, pò esse sensu per aghjurnà u sistema prima di tutti l'altri travaglii, per questu pudete rinominà u bloccu tasks
in quale sò definiti in pre_tasks
.
Configurazione di nginx
Avemu digià avè installatu Nginx, avemu bisognu di cunfigurà è eseguisce. Facemu subitu in u rolu. Crea una struttura di file:
- ansible
- roles
- nginx
- files
- tasks
- main.yml
- templates
Avà avemu bisognu di schedari è mudelli. A diffarenza trà elli hè chì ansible copia direttamente i schedari, cum'è. È i mudelli anu da avè l'estensione j2 è pudete aduprà i valori di variàbili in elli usendu i stessi doppi ricci.
Abilitemu nginx in main.yml
schedariu. Per questu avemu u modulu systemd:
# Copy nginx configs and start it
- name: enable service nginx and start
systemd:
name: nginx
state: started
enabled: yes
Quì ùn dicemu micca solu chì nginx deve esse iniziatu (vale à dì, avemu principiatu), ma immediatamente dicemu chì deve esse attivatu.
Avà copiemu i schedarii di cunfigurazione:
# 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'
Creemu u schedariu principale di cunfigurazione nginx (pudete piglià direttamente da u servitore, o scrivite sè stessu). È ancu u schedariu di cunfigurazione per a nostra applicazione in u repertoriu sites_available (questu ùn hè micca necessariu ma utile). In u primu casu, usemu u modulu di copia per copià i schedari (u schedariu deve esse in /ansible/roles/nginx/files/nginx.conf
). In u sicondu, copiamu u mudellu, sustituendu i valori di e variàbili. U mudellu deve esse in /ansible/roles/nginx/templates/my_app.j2
). È pò esse simile à questu:
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 }};
....
}
Prestate attenzione à l'inserzioni {{ app_name }}
, {{ app_path }}
, {{ server_name }}
, {{ inventory_hostname }}
sò tutte e variàbili chì i valori chì anu da rimpiazzà in u mudellu prima di cupià. Questu hè utile se utilizate un libru di ghjocu per diversi gruppi di ospiti. Per esempiu, pudemu aghjunghje à u nostru schedariu d'inventariu:
[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
Se eseguimu u nostru playbook avà, eseguirà i travaglii specificati per i dui ospiti. Ma à u stessu tempu, per l'ospitu di staging, i variàbili seranu diffirenti da quelli di pruduzzione, è micca solu in roli è playbooks, ma ancu in nginx configs. {{ inventory_hostname }}
ùn deve esse specificatu in u schedariu d'inventariu - questu
Se vulete avè un schedariu d'inventariu per parechji ospiti, ma eseguite solu per un gruppu, pudete fà cusì cù u cumandimu seguente:
ansible-playbook -i inventory ./playbook.yml -l "staging"
un'altra opzione hè di avè schedarii d'inventariu separati per i diversi gruppi. O pudete cumminà i dui approcci si avete parechji ospiti diffirenti.
Riturnemu à a stallazione di nginx. Dopu avè copiatu i schedarii di cunfigurazione, avemu bisognu di creà un ligame simbolicu in sitest_enabled à my_app.conf da sites_available. È riavvia 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
Tuttu hè simplice quì - dinò moduli ansible cù una sintassi abbastanza standard. Ma ci hè un mumentu. Riavvià nginx ogni volta ùn hà micca sensu. Avete nutatu chì ùn scrivemu micca cumandamenti cum'è: "fate questu cusì", a sintassi s'assumiglia più "questu deve avè un statu cusì". È più spessu questu hè cumu funziona ansible. Se u gruppu esiste digià, o u pacchettu di u sistema hè digià stallatu, allora ansible verificarà questu è salta u compitu. Inoltre, i schedari ùn saranu micca copiati s'ellu currispondenu cumplettamente ciò chì hè digià in u servitore. Pudemu prufittà di questu è riavvia nginx solu se i schedarii di cunfigurazione anu cambiatu. Ci hè una direttiva di registru per questu:
# 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
Se unu di i schedarii di cunfigurazione cambia, allora una copia serà fatta è una variabile serà registrata restart_nginx
. È solu se sta variabile hè stata registrata, u serviziu serà riavviatu.
E, sicuru, avete bisognu di aghjunghje u rolu nginx à u playbook principale.
installazione di postgresql
Avemu bisognu di attivà postgresql cù systemd cum'è avemu fattu cù nginx, è ancu creà un utilizatore chì avemu aduprà per accede à a basa di dati è a basa di dati stessu.
Creemu un 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 }}"
Ùn scriveraghju micca cumu aghjunghje variàbili à l'inventariu, questu hè digià fattu parechje volte, è ancu a sintassi di i moduli postgresql_db è postgresql_user. Più infurmazione pò esse truvata in a documentazione. Eccu a direttiva più interessante become_user: postgres
. U fattu hè chì per automaticamente, solu l'utilizatore di postgres hà accessu à a basa di dati postgresql è solu in u locu. Questa direttiva ci permette di eseguisce cumandamenti in nome di questu utilizatore (se avemu accessu, sicuru).
Inoltre, pudete avè bisognu di aghjunghje una linea à pg_hba.conf per permette un novu accessu d'utilizatori à a basa di dati. Questu pò esse fattu da a listessa manera chì avemu cambiatu a cunfigurazione nginx.
E sicuru, avete bisognu di aghjunghje u rolu di postgresql à u playbook principale.
Installazione di ruby via rbenv
Ansible ùn hà micca moduli per travaglià cù rbenv, ma hè stallatu clonendu u repository git. Per quessa, stu compitu diventa u più micca standard. Creemu un rolu per ella /ansible/roles/ruby_rbenv/main.yml
è cuminciate à riempie:
# Install rbenv and ruby
- name: Install rbenv
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv
Avemu dinò aduprà a direttiva di diventà_utente per travaglià sottu à l'utilizatore chì avemu creatu per questu scopu. Perchè rbenv hè stallatu in u so cartulare di casa, micca in u mondu. È avemu ancu aduprà u modulu git per clone u repository specificendu repo è dest.
Dopu, avemu bisognu di aghjunghje rbenv init à bashrc è aghjunghje rbenv à PATH in u stessu locu. Per questu avemu u modulu 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 -)"'
Allora avete bisognu di stallà ruby_build:
- name: Install ruby-build
become_user: "{{ user }}"
git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build
È infine stallà ruby. Questu hè fattu attraversu rbenv, vale à dì basta bash cù u cumandimu:
- name: Install ruby
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
rbenv install {{ ruby_version }}
args:
executable: /bin/bash
Dicemu quale cumandamentu per eseguisce è cun quale. In ogni casu, quì sbatteremu nantu à u fattu chì ansible ùn eseguisce micca u codice cuntenutu in bashrc prima di eseguisce cumandamenti. Questu significa chì rbenv duverà esse definitu direttamente in u stessu script.
U prossimu prublema hè chì u cumandamentu di shell hè senza statu da u puntu di vista di ansible. Questu hè, ùn ci sarà micca un cuntrollu automaticu se sta versione di ruby hè installata o micca. Pudemu fà noi stessi:
- 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
È resta à stallà u bundler:
- name: Install bundler
become_user: "{{ user }}"
shell: |
export PATH="${HOME}/.rbenv/bin:${PATH}"
eval "$(rbenv init -)"
gem install bundler
È torna aghjunghje u nostru rolu ruby_rbenv à u playbook principale.
I schedarii spartuti.
In generale, stu paràmetru pò esse cumpletu. Tandu resta à eseguisce capistrano è copià u codice stessu, creà i cartulari necessarii è lanciari l'applicazione (se tuttu hè cunfiguratu bè). Tuttavia, capistrano spessu bisognu di schedarii di cunfigurazione supplementari, cum'è database.yml
o .env
Puderanu esse copiati cum'è i schedari è mudelli per nginx. Ci hè solu una suttilità. Prima di cupià i schedari, avete bisognu di creà una struttura di cartulare per elli, qualcosa cum'è questu:
# Copy shared files for deploy
- name: Ensure shared dir
become_user: "{{ user }}"
file:
path: "{{ app_path }}/shared/config"
state: directory
specifiemu solu un repertoriu è ansible creerà automaticamente u genitore se necessariu.
Ansible Vault
Avemu digià stumbled in u fattu chì e variàbili ponu cuntene dati secreti cum'è a password di l'utilizatore. Sì avete creatu .env
u schedariu di l'applicazione, è database.yml
tandu ci deve esse ancu di più di tali dati critichi. Saria bellu piattà li da l'occhi indiscreti. Per questu, hè utilizatu
Crea un schedariu per variàbili /ansible/vars/all.yml
(quì pudete creà diversi schedarii per diversi gruppi di ospiti, cum'è in u schedariu d'inventariu: production.yml, staging.yml, etc.).
Tutte e variàbili devenu esse trasferite à stu schedariu, chì deve esse criptatu cù a sintassi standard 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
Dopu questu, stu schedariu pò esse criptatu cù u cumandimu:
ansible-vault encrypt ./vars/all.yml
Naturalmente, quandu cifrate, avete bisognu di stabilisce una password per a decryption. Pudete vede ciò chì serà in u schedariu dopu avè chjamatu stu cumandamentu.
Cù l'aiutu di ansible-vault decrypt
u schedariu pò esse decriptatu, mudificatu è poi criptatu novu.
Ùn avete bisognu di decrypt u schedariu per travaglià. L'avete criptatu è eseguite u playbook cù l'argumentu --ask-vault-pass
. Ansible dumandarà a password, uttene e variàbili, è eseguisce i travaglii. Tutti i dati restanu criptati.
U cumandamentu cumpletu per parechji gruppi d'ospiti è ansible vault parerebbe cusì cusì:
ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass
È ùn vi daraghju u testu sanu di i playbooks è i roli, scrivite sè stessu. Perchè l'ansible hè una tale cosa - sè ùn avete micca capitu ciò chì deve esse fattu, allora ùn vi farà micca.
Source: www.habr.com