Postavljanje poslužitelja za implementaciju Rails aplikacije koristeći Ansible

Nedavno sam trebao napisati nekoliko priručnika za Ansible kako bih pripremio poslužitelj za implementaciju Rails aplikacije. I, začudo, nisam pronašao jednostavan priručnik korak po korak. Nisam želio kopirati tuđu knjigu bez razumijevanja što se događa i na kraju sam morao pročitati dokumentaciju, prikupivši sve sam. Možda nekome mogu pomoći da ubrza ovaj proces uz pomoć ovog članka.

Prva stvar koju treba razumjeti je da vam ansible pruža prikladno sučelje za izvođenje unaprijed definiranog popisa radnji na udaljenim poslužiteljima putem SSH-a. Ovdje nema nikakve magije, ne možete instalirati dodatak i dobiti nultu implementaciju svoje aplikacije s dockerom, nadzorom i drugim dodacima odmah po otvaranju. Kako biste napisali knjigu igrokaza, morate znati što točno želite učiniti i kako to učiniti. Zato nisam zadovoljan gotovim igrama s GitHuba ili člancima poput: "Kopiraj i pokreni, radit će."

Što nam treba?

Kao što sam već rekao, da biste napisali knjigu igrokaza morate znati što želite učiniti i kako to učiniti. Odlučimo što nam treba. Za Rails aplikaciju trebat će nam nekoliko sistemskih paketa: nginx, postgresql (redis, itd.). Osim toga, potrebna nam je specifična verzija rubina. Najbolje ga je instalirati preko rbenv (rvm, asdf...). Pokretanje svega ovoga kao root korisnika uvijek je loša ideja, stoga trebate stvoriti zasebnog korisnika i konfigurirati njegova prava. Nakon ovoga, morate učitati naš kod na poslužitelj, kopirati konfiguracije za nginx, postgres itd. i pokrenuti sve te usluge.

Kao rezultat toga, slijed radnji je sljedeći:

  1. Prijavite se kao root
  2. instalirajte sistemske pakete
  3. stvoriti novog korisnika, konfigurirati prava, ssh ključ
  4. konfigurirajte sistemske pakete (nginx itd.) i pokrenite ih
  5. U bazi podataka kreiramo korisnika (možete odmah kreirati bazu podataka)
  6. Prijavite se kao novi korisnik
  7. Instalirajte rbenv i ruby
  8. Ugradnja bundlera
  9. Učitavanje koda aplikacije
  10. Pokretanje Puma poslužitelja

Štoviše, posljednje faze mogu se obaviti pomoću capistrana, barem izvan okvira može kopirati kod u direktorije izdanja, prebaciti izdanje simboličkom vezom nakon uspješne implementacije, kopirati konfiguracije iz dijeljenog direktorija, ponovno pokrenuti pumu itd. Sve se to može učiniti pomoću Ansiblea, ali zašto?

Struktura datoteke

Ansible ima stroge struktura datoteke za sve vaše datoteke, pa je najbolje da sve to držite u posebnom direktoriju. Štoviše, nije toliko važno hoće li biti u samoj rails aplikaciji ili zasebno. Datoteke možete pohraniti u zasebno git spremište. Osobno mi je bilo najprikladnije stvoriti ansible direktorij u /config direktoriju rails aplikacije i pohraniti sve u jedno spremište.

Jednostavna knjiga za igru

Playbook je yml datoteka koja, koristeći posebnu sintaksu, opisuje što Ansible treba raditi i kako. Kreirajmo prvu knjigu igara koja ne radi ništa:

---
- name: Simple playbook
  hosts: all

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

ansible-playbook ./playbook.yml

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

Ansible kaže da ne poznaje nijedan host koji odgovara popisu svih. Moraju biti navedeni u posebnom popisna datoteka.

Kreirajmo ga u istom ansible direktoriju:

123.123.123.123

Ovako jednostavno odredimo host (idealno host našeg VPS-a za testiranje, ili možete registrirati localhost) i spremimo ga pod imenom inventory.
Možete pokušati pokrenuti ansible s datotekom popisa:

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

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

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

Ako imate ssh pristup navedenom hostu, tada će se ansible spojiti i prikupiti informacije o udaljenom sustavu. (zadani ZADATAK [Gathering Facts]) nakon čega će dati kratko izvješće o izvršenju (PLAY RECAP).

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

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

Pokušajte ponovo pokrenuti priručnik i provjerite radi li veza. (Ako ste naveli root korisnika, tada također trebate navesti direktivu become: true kako 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 pogrešku uzrokovanu činjenicom da ansible ne može odrediti Python tumač, tada ga možete odrediti ručno:

ansible_python_interpreter: /usr/bin/python3 

Pomoću naredbe možete saznati gdje imate python whereis python.

Instaliranje paketa sustava

Standardna distribucija Ansiblea uključuje mnoge module za rad s različitim sistemskim paketima, tako da ne moramo pisati bash skripte iz bilo kojeg razloga. Sada nam treba jedan od ovih modula za ažuriranje sustava i instaliranje sistemskih paketa. Imam Ubuntu Linux na svom VPS-u, pa za instalaciju paketa koristim apt-get и modul za to. Ako koristite drugi operativni sustav, možda će vam trebati drugačiji modul (sjetite se, rekao sam na početku da moramo unaprijed znati što i kako ćemo). Međutim, sintaksa će najvjerojatnije biti slična.

Dopunimo našu knjižicu s 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

Task je upravo zadatak koji će Ansible obavljati na udaljenim poslužiteljima. Zadatku dajemo ime kako bismo mogli pratiti njegovo izvršenje u dnevniku. I mi opisujemo, koristeći sintaksu određenog modula, što on treba učiniti. U ovom slučaju apt: update_cache=yes - kaže ažurirati sistemske pakete pomoću apt modula. Druga naredba je malo kompliciranija. Prosljeđujemo popis paketa apt modulu i kažemo da jesu state treba postati present, odnosno kažemo instalirajte ove pakete. Na sličan način im možemo reći da ih izbrišu ili ažuriraju jednostavnom promjenom state. Imajte na umu da nam je za rad tračnica s postgresql-om potreban paket postgresql-contrib, koji sada instaliramo. Opet, morate to znati i učiniti; ansible sam po sebi to neće učiniti.

Pokušajte ponovno pokrenuti playbook i provjerite jesu li paketi instalirani.

Stvaranje novih korisnika.

Za rad s korisnicima Ansible ima i modul - korisnik. Dodajmo još jedan zadatak (već poznate dijelove priručnika sakrio sam iza komentara da ga svaki put ne kopiram u cijelosti):

---
- 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 mu shelu i lozinku. I tada nailazimo na nekoliko problema. Što ako korisnička imena moraju biti različita za različite hostove? A pohranjivanje lozinke u jasnom tekstu u priručniku vrlo je 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 igrama 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 (all).

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

Dodajmo našeg korisnika u sudo grupu. Međutim, prije toga moramo se uvjeriti da takva grupa postoji jer to nitko 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 vrlo jednostavno, imamo i grupni modul za stvaranje grupa, sa sintaksom vrlo sličnom apt-u. Tada je dovoljno prijaviti 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 popis autoriziranih ključeva za korisnika na poslužitelju.

uloga

Sva tri zadatka za kreiranje upotrebe lako se mogu svrstati u jednu skupinu zadataka, a bilo bi dobro ovu skupinu pohraniti odvojeno od glavne knjige igranja kako ne bi postala prevelika. U tu svrhu Ansible ima roli.
Prema strukturi datoteke naznačenoj na samom početku, uloge moraju biti smještene u poseban direktorij uloga, za svaku ulogu postoji poseban direktorij s istim imenom, unutar direktorija zadataka, datoteka, predložaka itd.
Kreirajmo strukturu datoteke: ./ansible/roles/user/tasks/main.yml (main je glavna datoteka koja će se učitati i izvršiti kada se uloga poveže s playbookom; druge datoteke uloga mogu se povezati s njom). Sada možete prenijeti sve zadatke vezane uz 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 vodiču morate navesti da koristite korisničku ulogu:

---
- 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 sustav prije svih ostalih zadataka; da biste to učinili, možete preimenovati blok tasks u kojem su definirani u pre_tasks.

Postavljanje nginxa

Trebali bismo već imati instaliran Nginx; moramo ga konfigurirati i pokrenuti. Učinimo to odmah u ulozi. Kreirajmo strukturu datoteke:

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

Sada su nam potrebne datoteke i predlošci. Razlika između njih je u tome što ansible izravno kopira datoteke 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 main.yml datoteka. 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 uključ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'

Mi stvaramo glavnu nginx konfiguracijsku datoteku (možete je preuzeti izravno s poslužitelja ili je sami napisati). I također konfiguracijsku datoteku za našu aplikaciju u direktoriju sites_available (ovo nije potrebno, ali je korisno). U prvom slučaju koristimo modul kopiranja za kopiranje datoteka (datoteka mora biti u /ansible/roles/nginx/files/nginx.conf). U drugom kopiramo predložak, zamjenjujući vrijednosti varijabli. Predložak 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 pozornost 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 priručnik za različite skupine 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 hosta. Ali u isto vrijeme, za staging host, varijable će se razlikovati od produkcijskih, i to ne samo u ulogama i igrama, već i u nginx konfiguracijama. {{ inventory_hostname }} ne moraju biti navedeni u popisnoj kartoteci – ovo posebna anzibilna varijabla i host za koji playbook trenutno radi je pohranjen tamo.
Ako želite imati datoteku inventara za nekoliko hostova, ali pokrenuti samo za jednu grupu, to možete učiniti sljedećom naredbom:

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

Druga je mogućnost imati zasebne datoteke inventara za različite skupine. Ili možete kombinirati dva pristupa ako imate mnogo različitih domaćina.

Vratimo se na postavljanje nginxa. Nakon kopiranja konfiguracijskih datoteka, moramo stvoriti simboličku vezu u sitest_enabled na my_app.conf iz sites_available. I ponovno 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 antabilni moduli s prilično standardnom sintaksom. Ali postoji jedna točka. Nema smisla svaki put ponovno pokretati nginx. Jeste li primijetili da ne pišemo naredbe poput: “uradi ovo ovako”, sintaksa više izgleda kao “ovo bi trebalo imati ovo stanje”. I najčešće upravo tako radi ansible. Ako grupa već postoji ili je sistemski paket već instaliran, ansible će to provjeriti i preskočiti zadatak. Također, datoteke se neće kopirati ako u potpunosti odgovaraju onome što je već na poslužitelju. To možemo iskoristiti i ponovno 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 se registrirati restart_nginx. I samo ako je ova varijabla registrirana, usluga će se ponovno pokrenuti.

I, naravno, trebate dodati ulogu nginxa u glavnu knjigu igranja.

Postavljanje postgresql-a

Moramo omogućiti postgresql pomoću systemd-a na isti način kao što smo to učinili s nginxom, te također kreirati korisnika kojeg ćemo koristiti za pristup bazi podataka i samoj bazi podataka.
Kreirajmo 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ć učinjeno mnogo puta, kao i sintaksu postgresql_db i postgresql_user modula. Više informacija možete pronaći u dokumentaciji. Ovdje je najzanimljivija direktiva become_user: postgres. Činjenica je da prema zadanim postavkama samo postgres korisnik ima pristup postgresql bazi podataka i to samo lokalno. Ova nam direktiva omogućuje izvršavanje naredbi u ime ovog korisnika (ako imamo pristup, naravno).
Također, možda ćete morati dodati redak u pg_hba.conf kako biste novom korisniku omogućili pristup bazi podataka. To se može učiniti na isti način kao što smo promijenili nginx konfiguraciju.

I naravno, trebate dodati postgresql ulogu u glavnu knjigu igranja.

Instaliranje ruby ​​​​putem rbenv

Ansible nema module za rad s rbenv-om, već se instalira kloniranjem git repozitorija. Stoga ovaj problem postaje najnestandardniji. Stvorimo ulogu za nju /ansible/roles/ruby_rbenv/main.yml i počnimo ga ispunjavati:

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

Ponovno koristimo direktivu become_user za rad pod korisnikom kojeg smo stvorili za ove svrhe. Budući da je rbenv instaliran u svom početnom direktoriju, a ne globalno. Također koristimo git modul za kloniranje repozitorija, navodeći repo i dest.

Zatim moramo registrirati rbenv init u bashrc i tamo dodati rbenv u PATH. Za ovo imamo lineinfile modul:

- 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 trebate 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. To se radi putem rbenv-a, to jest jednostavno s bash naredbom:

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

Kažemo koju naredbu izvršiti i čime. Međutim, ovdje nailazimo na činjenicu da ansible ne pokreće kod sadržan u bashrc prije pokretanja naredbi. To znači da će rbenv morati biti definiran izravno u istoj skripti.

Sljedeći problem nastaje zbog činjenice da naredba ljuske nema stanje s anzibilne točke gledišta. Odnosno, neće biti automatske provjere je li ova verzija rubyja instalirana ili ne. To možemo učiniti 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

Sve što preostaje 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.

Dijeljene datoteke.

Općenito, postavljanje bi moglo biti dovršeno ovdje. Zatim, sve što preostaje je pokrenuti capistrano i on će sam kopirati kod, stvoriti 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, trebate stvoriti 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

specificiramo samo jedan direktorij i ansible će automatski kreirati nadređene ako je potrebno.

Ansbilni trezor

Već smo naišli na činjenicu da varijable mogu sadržavati tajne podatke kao što je korisnička lozinka. Ako ste stvorili .env datoteku za prijavu i database.yml onda takvih kritičnih podataka mora biti još više. Bilo bi dobro sakriti ih od znatiželjnih očiju. U tu svrhu koristi se ansible svod.

Kreirajmo datoteku za varijable /ansible/vars/all.yml (ovdje možete kreirati različite datoteke za različite grupe hostova, baš kao u datoteci inventara: 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 toga se ova datoteka može šifrirati naredbom:

ansible-vault encrypt ./vars/all.yml

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

Putem ansible-vault decrypt datoteka se može dekriptirati, modificirati i zatim ponovno šifrirati.

Ne morate dešifrirati datoteku da bi radila. Pohranjujete ga šifriranog i pokrećete playbook s argumentom --ask-vault-pass. Ansible će tražiti lozinku, dohvatiti varijable i izvršiti zadatke. Svi će podaci ostati šifrirani.

Potpuna naredba za nekoliko grupa hostova i ansible trezor izgledat će otprilike ovako:

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

Ali neću vam dati cijeli tekst igrokaza i uloga, napišite ga sami. Jer ansible je takav - ako ne razumijete što treba učiniti, onda on to neće učiniti umjesto vas.

Izvor: www.habr.com

Dodajte komentar