ProHoster > Блог > Administracija > Konfiguriranje servera za postavljanje Rails aplikacije koristeći Ansible

Konfiguriranje servera za postavljanje Rails aplikacije koristeći Ansible

Nedavno sam morao da napišem nekoliko Ansible playbookova da pripremim server za postavljanje Rails aplikacije. I, iznenađujuće, nisam pronašao jednostavan priručnik korak po korak. Nisam želeo da kopiram tuđu knjigu a da ne razumem šta se dešava, a na kraju sam morao da čitam dokumentaciju i sve sam sakupio. Možda mogu pomoći nekome da ubrza ovaj proces uz pomoć ovog članka.

Prva stvar koju treba shvatiti je da vam ansible pruža zgodan interfejs za izvođenje unapred definisane liste akcija na udaljenim serverima putem SSH-a. Nema tu nikakve magije, ne možete instalirati dodatak i dobiti nultu implementaciju vaše aplikacije sa dockerom, nadzorom i drugim dobrotama iz kutije. Da biste napisali knjigu igranja, morate znati šta tačno želite da radite i kako to da uradite. Zato nisam zadovoljan gotovim priručnicima sa GitHub-a ili člancima poput: “Kopiraj i pokreni, radit će.”

Šta nam treba?

Kao što sam već rekao, da biste napisali playbook morate znati šta želite da radite i kako to učiniti. Hajde da odlučimo šta nam treba. Za Rails aplikaciju trebat će nam nekoliko sistemskih paketa: nginx, postgresql (redis, itd.). Osim toga, potrebna nam je posebna verzija ruby-a. Najbolje ga je instalirati preko rbenv (rvm, asdf...). Pokretanje svega ovoga kao root korisnik je uvijek loša ideja, tako da morate kreirati posebnog korisnika i konfigurirati njegova prava. Nakon ovoga, potrebno je da učitate naš kod na server, kopirate konfiguracije za nginx, postgres itd. i pokrenete sve ove servise.

Kao rezultat toga, slijed radnji je sljedeći:

  1. Prijavite se kao root
  2. instalirati sistemske pakete
  3. kreirati novog korisnika, konfigurisati prava, ssh ključ
  4. konfigurišite sistemske pakete (nginx itd.) i pokrenite ih
  5. Kreiramo korisnika u bazi podataka (možete odmah kreirati bazu podataka)
  6. Prijavite se kao novi korisnik
  7. Instalirajte rbenv i ruby
  8. Instaliranje bundlera
  9. Učitavanje koda aplikacije
  10. Pokretanje Puma servera

Štoviše, posljednje faze se mogu obaviti pomoću capistrana, barem iz kutije može kopirati kod u direktorije izdanja, prebaciti izdanje simboličkom vezom nakon uspješnog postavljanja, kopirati konfiguracije iz zajedničkog direktorija, ponovno pokrenuti Pumu, itd. Sve ovo se može uraditi koristeći Ansible, ali zašto?

Struktura fajla

Ansible ima strogu strukturu fajla za sve vaše datoteke, tako da je najbolje da sve to držite u zasebnom direktoriju. Štaviše, nije toliko važno da li će biti u samoj aplikaciji šina ili odvojeno. Možete pohraniti datoteke u zasebno git spremište. Lično, smatrao sam da je najzgodnije kreirati ansible direktorij u /config direktoriju rails aplikacije i sve pohraniti u jedno spremište.

Simple Playbook

Playbook je yml datoteka koja, koristeći posebnu sintaksu, opisuje šta Ansible treba da radi i kako. Hajde da napravimo prvi playbook koji ne radi ništa:

---
- name: Simple playbook
  hosts: all

Ovdje jednostavno kažemo da se zove naš playbook Simple Playbook i da njegov sadržaj treba da se izvrši za sve hostove. Možemo ga spremiti u /ansible direktorij s imenom playbook.yml i pokušajte pokrenuti:

ansible-playbook ./playbook.yml

PLAY [Simple Playbook] ************************************************************************************************************************************
skipping: no hosts matched

Ansible kaže da ne poznaje nijedan host koji odgovara listi svih. Oni moraju biti navedeni u posebnom dosije inventara.

Kreirajmo ga u istom ansible direktoriju:

123.123.123.123

Ovako jednostavno specificiramo host (idealno domaćin našeg VPS-a za testiranje, ili možete registrirati localhost) i spremiti ga pod imenom inventory.
Možete pokušati pokrenuti ansible sa datotekom inventara:

ansible-playbook ./playbook.yml -i inventory
PLAY [Simple Playbook] ************************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************************

PLAY RECAP ************************************************************************************************************************************

Ako imate ssh pristup navedenom hostu, ansible će se povezati i prikupiti informacije o udaljenom sistemu. (default TASK [Gathering Facts]) nakon čega će dati kratak izvještaj o izvršenju (PLAY RECAP).

Podrazumevano, veza koristi korisničko ime pod kojim ste prijavljeni u sistem. Najvjerovatnije neće biti na hostu. U datoteci playbook možete odrediti kojeg korisnika koristiti za povezivanje pomoću direktive remote_user. Također, informacije o udaljenom sistemu vam često mogu biti nepotrebne i ne biste trebali gubiti vrijeme na njihovo prikupljanje. Ovaj zadatak se također može onemogućiti:

---
- name: Simple playbook
  hosts: all
  remote_user: root
  become: true
  gather_facts: no

Pokušajte ponovo pokrenuti playbook i uvjerite se da veza radi. (Ako ste naveli root korisnika, tada morate navesti i direktivu become: true da biste dobili povišena prava. Kao što je napisano u dokumentaciji: become set to ‘true’/’yes’ to activate privilege escalation. iako nije sasvim jasno zašto).

Možda ćete dobiti grešku uzrokovanu činjenicom da ansible ne može odrediti Python interpreter, tada ga možete odrediti ručno:

ansible_python_interpreter: /usr/bin/python3

Možete saznati gdje imate Python pomoću naredbe whereis python.

Instaliranje sistemskih paketa

Ansibleova standardna distribucija uključuje mnoge module za rad sa različitim sistemskim paketima, tako da ne moramo pisati bash skripte iz bilo kojeg razloga. Sada nam je potreban jedan od ovih modula da ažuriramo sistem i instaliramo sistemske pakete. Imam Ubuntu Linux na svom VPS-u, tako da za instaliranje paketa koristim apt-get и modul za to. Ako koristite drugi operativni sistem, možda će vam trebati drugi modul (zapamtite, rekao sam na početku da moramo unaprijed znati šta i kako ćemo raditi). Međutim, sintaksa će najvjerovatnije biti slična.

Dopunimo našu svesku sa prvim zadacima:

---
- 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

Zadatak je upravo zadatak koji će Ansible obavljati na udaljenim serverima. Zadatku dajemo ime tako da možemo pratiti njegovo izvršenje u dnevniku. I opisujemo, koristeći sintaksu određenog modula, šta treba da uradi. U ovom slučaju apt: update_cache=yes - kaže da ažurirate sistemske pakete koristeći apt modul. Druga komanda je malo komplikovanija. Apt modulu prosljeđujemo listu paketa i kažemo da jesu state trebalo bi da postane present, odnosno kažemo instalirajte ove pakete. Na sličan način možemo im reći da ih izbrišu ili ažuriraju jednostavnom promjenom state. Imajte na umu da nam je potreban postgresql-contrib paket da bi šine radile sa postgresql-om, koji sada instaliramo. Opet, ovo morate znati i učiniti; ansible sam po sebi to neće učiniti.

Pokušajte ponovo pokrenuti playbook i provjerite da li su paketi instalirani.

Kreiranje novih korisnika.

Za rad sa korisnicima, Ansible ima i modul - user. Dodajmo još jedan zadatak (sakrio sam već poznate dijelove priručnika iza komentara kako ga ne bih svaki put kopirao u potpunosti): 

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Add a new user
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

Kreiramo novog korisnika, postavljamo šell i lozinku za njega. A onda nailazimo na nekoliko problema. Što ako korisnička imena moraju biti različita za različite hostove? A pohranjivanje lozinke u čistom tekstu u priručniku je vrlo loša ideja. Za početak, stavimo korisničko ime i lozinku u varijable, a pred kraj članka ću pokazati kako šifrirati lozinku.

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Add a new user
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

Varijable se postavljaju u playbooks pomoću dvostrukih vitičastih zagrada.

Naznačit ćemo vrijednosti varijabli u datoteci inventara:

123.123.123.123

[all:vars]
user=my_user
user_password=123qweasd

Obratite pažnju na direktivu [all:vars] - kaže da su sljedeći blok teksta varijable (vars) i one su primjenjive na sve hostove (sve).

Dizajn je takođe zanimljiv "{{ user_password | password_hash('sha512') }}". Stvar je u tome što ansible ne instalira korisnika putem user_add kao da biste to uradili ručno. I direktno sprema sve podatke, zbog čega također moramo unaprijed pretvoriti lozinku u hash, što ova komanda radi.

Dodajmo našeg korisnika u sudo grupu. Međutim, prije toga moramo se uvjeriti da takva grupa postoji jer to niko neće učiniti umjesto nas:

---
- 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"

Sve je prilično jednostavno, imamo i grupni modul za kreiranje grupa, sa sintaksom vrlo sličnom apt. Tada je dovoljno registrirati ovu grupu korisniku (groups: "sudo").
Također je korisno dodati ssh ključ ovom korisniku kako bismo se mogli prijaviti koristeći ga bez lozinke:

---
- 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

U ovom slučaju, dizajn je zanimljiv "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — kopira sadržaj datoteke id_rsa.pub (vaše ime može biti drugačije), odnosno javni dio ssh ključa i učitava ga na listu ovlaštenih ključeva za korisnika na serveru.

Uloge

Sva tri zadatka za kreiranje upotrebe lako se mogu svrstati u jednu grupu zadataka i bilo bi dobro da ovu grupu pohranite odvojeno od glavne knjige kako ne bi postala prevelika. U tu svrhu, Ansible ima uloge.
Prema strukturi datoteka koja je naznačena na samom početku, uloge se moraju smjestiti u poseban direktorij uloga, za svaku ulogu postoji poseban direktorij s istim imenom, unutar direktorija zadataka, datoteka, šablona itd.
Kreirajmo strukturu fajla: ./ansible/roles/user/tasks/main.yml (main je glavna datoteka koja će biti učitana i izvršena kada se uloga poveže s playbook-om; druge datoteke uloga se mogu povezati s njom). Sada možete prenijeti sve zadatke koji se odnose na korisnika u ovu datoteku:

# 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

U glavnom priručniku morate navesti da koristite ulogu korisnika:

---
- 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

Također, možda ima smisla ažurirati sistem prije svih drugih zadataka; da biste to učinili, možete preimenovati blok tasks u kojima su definisani u pre_tasks.

Postavljanje nginxa

Trebali bismo već imati instaliran Nginx; moramo ga konfigurirati i pokrenuti. Uradimo to odmah u ulozi. Kreirajmo strukturu fajla:

- ansible
  - roles
    - nginx
      - files
      - tasks
        - main.yml
      - templates

Sada su nam potrebni fajlovi i šabloni. Razlika između njih je u tome što ansible kopira datoteke direktno, takve kakve jesu. I predlošci moraju imati ekstenziju j2 i mogu koristiti varijabilne vrijednosti koristeći iste dvostruke vitičaste zagrade.

Omogućimo nginx unutra main.yml fajl. Za ovo imamo systemd modul:

# Copy nginx configs and start it
- name: enable service nginx and start
  systemd:
    name: nginx
    state: started
    enabled: yes

Ovdje ne samo da kažemo da nginx mora biti pokrenut (odnosno da ga pokrećemo), već odmah kažemo da mora biti omogućen.
Sada kopirajmo konfiguracijske datoteke:

# 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'

Kreiramo glavnu nginx konfiguracijsku datoteku (možete je preuzeti direktno sa servera ili je sami napisati). I također konfiguracijski fajl za našu aplikaciju u direktoriju sites_available (ovo nije neophodno, ali korisno). U prvom slučaju koristimo modul za kopiranje za kopiranje datoteka (fajl mora biti u /ansible/roles/nginx/files/nginx.conf). U drugom kopiramo predložak, zamjenjujući vrijednosti varijabli. Šablon bi trebao biti unutra /ansible/roles/nginx/templates/my_app.j2). A moglo bi izgledati otprilike ovako:

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 }};
  ....
}

Obratite pažnju na umetke {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — ovo su sve varijable čije će vrijednosti Ansible zamijeniti u predlošku prije kopiranja. Ovo je korisno ako koristite playbook za različite grupe domaćina. Na primjer, možemo dodati našu datoteku inventara:

[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

Ako sada pokrenemo naš playbook, on će izvršiti navedene zadatke za oba domaćina. Ali u isto vrijeme, za scenski host, varijable će se razlikovati od proizvodnih, i to ne samo u ulogama i playbookovima, već iu nginx konfiguracijama. {{ inventory_hostname }} ne treba navesti u inventaru - ovo posebna ansible varijabla i tamo je pohranjen host za koji je playbook trenutno pokrenut.
Ako želite da imate datoteku inventara za nekoliko hostova, ali da se pokrenete samo za jednu grupu, to se može učiniti sljedećom naredbom:

ansible-playbook -i inventory ./playbook.yml -l "staging"

Druga opcija je da imate odvojene datoteke inventara za različite grupe. Ili možete kombinirati dva pristupa ako imate mnogo različitih domaćina.

Vratimo se na podešavanje nginxa. Nakon kopiranja konfiguracijskih datoteka, moramo kreirati simboličku vezu u sitest_enabled do my_app.conf iz sites_available. I ponovo pokrenite 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

Ovdje je sve jednostavno - opet ansible moduli sa prilično standardnom sintaksom. Ali postoji jedna stvar. Nema smisla svaki put ponovo pokretati nginx. Jeste li primijetili da ne pišemo komande poput: „uradi ovo ovako“, sintaksa više izgleda kao „ovo bi trebalo da ima ovo stanje“. A najčešće upravo tako funkcioniše ansible. Ako grupa već postoji ili je sistemski paket već instaliran, ansible će to provjeriti i preskočiti zadatak. Također, datoteke neće biti kopirane ako se u potpunosti podudaraju sa onim što se već nalazi na serveru. Ovo možemo iskoristiti i ponovo pokrenuti nginx samo ako su konfiguracijske datoteke promijenjene. Za ovo postoji direktiva registra:

# 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

Ako se jedna od konfiguracijskih datoteka promijeni, napravit će se kopija i varijabla će biti registrirana restart_nginx. I samo ako je ova varijabla registrirana, servis će biti ponovo pokrenut.

I, naravno, morate dodati ulogu nginx u glavni playbook.

Postavljanje postgresql-a

Moramo da omogućimo postgresql koristeći systemd na isti način kao što smo uradili sa nginxom, a takođe kreiramo korisnika kojeg ćemo koristiti za pristup bazi podataka i samoj bazi podataka.
Hajde da napravimo ulogu /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 }}"

Neću opisivati ​​kako dodati varijable u inventar, to je već urađeno mnogo puta, kao i sintaksu modula postgresql_db i postgresql_user. Više informacija možete pronaći u dokumentaciji. Ovdje je najzanimljivija direktiva become_user: postgres. Činjenica je da po defaultu samo postgres korisnik ima pristup postgresql bazi podataka i to samo lokalno. Ova direktiva nam omogućava da izvršavamo komande u ime ovog korisnika (ako imamo pristup, naravno).
Također, možda ćete morati dodati red u pg_hba.conf kako biste novom korisniku omogućili pristup bazi podataka. Ovo se može uraditi na isti način kao što smo promijenili nginx konfiguraciju.

I naravno, morate dodati ulogu postgresql u glavni playbook.

Instalacija ruby-a putem rbenv-a

Ansible nema module za rad sa rbenv-om, ali se instalira kloniranjem git repozitorija. Stoga ovaj problem postaje najnestandardniji. Hajde da joj napravimo ulogu /ansible/roles/ruby_rbenv/main.yml i počnimo da ga popunjavamo:

# Install rbenv and ruby
- name: Install rbenv
  become_user: "{{ user }}"
  git: repo=https://github.com/rbenv/rbenv.git dest=~/.rbenv

Ponovo koristimo direktivu become_user za rad pod korisnikom kojeg smo kreirali za ove svrhe. Pošto je rbenv instaliran u svom matičnom direktoriju, a ne globalno. Takođe koristimo git modul za kloniranje spremišta, navodeći repo i odredište.

Zatim moramo registrovati rbenv init u bashrc i tamo dodati rbenv u PATH. Za ovo imamo 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 -)"'

Zatim morate instalirati ruby_build:

- name: Install ruby-build
  become_user: "{{ user }}"
  git: repo=https://github.com/rbenv/ruby-build.git dest=~/.rbenv/plugins/ruby-build

I na kraju instalirajte ruby. Ovo se radi preko rbenv-a, odnosno jednostavno sa bash komandom:

- name: Install ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    rbenv install {{ ruby_version }}
  args:
    executable: /bin/bash

Mi kažemo koju komandu da izvršimo i sa čime. Međutim, ovdje nailazimo na činjenicu da ansible ne pokreće kod sadržan u bashrc prije nego što pokrene komande. To znači da će rbenv morati biti definiran direktno u istoj skripti.

Sljedeći problem je zbog činjenice da naredba ljuske nema stanje sa ansible tačke gledišta. Odnosno, neće biti automatske provjere da li je ova verzija rubyja instalirana ili ne. Ovo možemo sami uraditi:

- 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

Sve što ostaje je instalirati bundler:

- name: Install bundler
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    gem install bundler

I opet, dodajte našu ulogu ruby_rbenv u glavni playbook.

Dijeljeni fajlovi.

Općenito, postavljanje bi se moglo završiti ovdje. Dalje, ostaje samo pokrenuti capistrano i on će sam kopirati kod, kreirati potrebne direktorije i pokrenuti aplikaciju (ako je sve ispravno konfigurirano). Međutim, capistrano često zahtijeva dodatne konfiguracijske datoteke, kao što su database.yml ili .env Mogu se kopirati baš kao datoteke i predlošci za nginx. Postoji samo jedna suptilnost. Prije kopiranja datoteka, morate kreirati strukturu direktorija za njih, otprilike ovako:

# Copy shared files for deploy
- name: Ensure shared dir
  become_user: "{{ user }}"
  file:
    path: "{{ app_path }}/shared/config"
    state: directory

navodimo samo jedan direktorij i ansible će automatski kreirati roditeljske ako je potrebno.

Ansible Vault

Već smo se susreli s činjenicom da varijable mogu sadržavati tajne podatke kao što je korisnička lozinka. Ako ste kreirali .env fajl za aplikaciju, i database.yml onda mora biti još više takvih kritičnih podataka. Bilo bi dobro sakriti ih od znatiželjnih očiju. U tu svrhu se koristi ansible vault.

Kreirajmo fajl za varijable /ansible/vars/all.yml (ovdje možete kreirati različite datoteke za različite grupe hostova, baš kao u inventaru: production.yml, staging.yml, itd.).
Sve varijable koje moraju biti šifrirane moraju se prenijeti u ovu datoteku koristeći standardnu ​​yml sintaksu:

# 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

Nakon čega se ovaj fajl može šifrirati naredbom:

ansible-vault encrypt ./vars/all.yml

Naravno, prilikom šifriranja, morat ćete postaviti lozinku za dešifriranje. Možete vidjeti šta će biti unutar datoteke nakon pozivanja ove naredbe.

Uz pomoć ansible-vault decrypt datoteka se može dešifrirati, modificirati i zatim ponovo šifrirati.

Ne morate dešifrirati datoteku da biste radili. Čuvate ga šifrovano i pokrećete playbook sa argumentom --ask-vault-pass. Ansible će tražiti lozinku, dohvatiti varijable i izvršiti zadatke. Svi podaci će ostati šifrirani.

Kompletna naredba za nekoliko grupa hostova i ansible trezor će izgledati otprilike ovako:

ansible-playbook -i inventory ./playbook.yml -l "staging" --ask-vault-pass

Ali neću vam dati potpuni tekst knjiga i uloga, napišite ga sami. Jer ansible je takav - ako ne razumete šta treba da se uradi, onda to neće učiniti umesto vas.

izvor: www.habr.com

Dodajte komentar