Nastavenie servera na nasadenie aplikácie Rails pomocou Ansible

Nie je to tak dávno, čo som potreboval napísať niekoľko Ansible playbookov, aby som pripravil server na nasadenie aplikácie Rails. A prekvapivo som nenašiel jednoduchý návod krok za krokom. Nechcel som kopírovať učebnicu niekoho iného bez toho, aby som pochopil, čo sa deje, a nakoniec som si musel prečítať dokumentáciu a všetko zhromaždiť sám. Možno pomôžem niekomu urýchliť tento proces pomocou tohto článku.

Prvá vec, ktorú treba pochopiť, je, že ansible vám poskytuje pohodlné rozhranie na vykonávanie vopred definovaného zoznamu akcií na vzdialenom serveri (serveroch) cez SSH. Nie je tu žiadna mágia, nemôžete nainštalovať plugin a získať nulový výpadok nasadenia vašej aplikácie s dockerom, monitorovaním a ďalšími vychytávkami hneď po vybalení. Aby ste mohli napísať playbook, musíte vedieť, čo presne chcete robiť a ako to urobiť. Preto nie som spokojný s hotovými playbookmi z GitHubu alebo článkami typu: „Skopíruj a spustite, bude to fungovať.“

Čo potrebujeme?

Ako som už povedal, na to, aby ste mohli napísať knihu, musíte vedieť, čo chcete robiť a ako to robiť. Rozhodnime sa, čo potrebujeme. Pre aplikáciu Rails budeme potrebovať niekoľko systémových balíkov: nginx, postgresql (redis, atď.). Okrem toho potrebujeme špecifickú verziu rubínu. Najlepšie je nainštalovať cez rbenv (rvm, asdf...). Spúšťať toto všetko ako používateľ root je vždy zlý nápad, takže musíte vytvoriť samostatného používateľa a nakonfigurovať jeho práva. Potom musíte nahrať náš kód na server, skopírovať konfigurácie pre nginx, postgres atď. a spustiť všetky tieto služby.

V dôsledku toho je postupnosť akcií nasledovná:

  1. Prihláste sa ako root
  2. nainštalovať systémové balíky
  3. vytvoriť nového používateľa, nakonfigurovať práva, kľúč ssh
  4. nakonfigurujte systémové balíky (nginx atď.) a spustite ich
  5. Vytvoríme používateľa v databáze (databázu môžete vytvoriť okamžite)
  6. Prihláste sa ako nový používateľ
  7. Nainštalujte rbenv a ruby
  8. Inštalácia zväzovača
  9. Nahrávanie kódu aplikácie
  10. Spustenie servera Puma

Navyše, posledné fázy je možné vykonať pomocou capistrano, aspoň po vybalení dokáže skopírovať kód do adresárov vydania, prepnúť vydanie pomocou symbolického odkazu po úspešnom nasadení, skopírovať konfigurácie zo zdieľaného adresára, reštartovať pumu atď. To všetko sa dá urobiť pomocou Ansible, ale prečo?

Štruktúra súboru

Ansible má prísny štruktúra súboru pre všetky vaše súbory, takže je najlepšie ich uchovávať v samostatnom adresári. Navyše nie je až také dôležité, či to bude v samotnej aplikácii koľajníc alebo samostatne. Súbory môžete ukladať do samostatného úložiska git. Osobne sa mi najviac osvedčilo vytvoriť si adresár ansible v adresári /config aplikácie rails a všetko uložiť do jedného úložiska.

Jednoduchá príručka

Playbook je súbor yml, ktorý pomocou špeciálnej syntaxe popisuje, čo má Ansible robiť a ako. Poďme vytvoriť prvú príručku, ktorá nič nerobí:

---
- name: Simple playbook
  hosts: all

Tu jednoducho povieme, že náš playbook sa volá Simple Playbook a že jeho obsah by sa mal spustiť pre všetkých hostiteľov. Môžeme ho uložiť do adresára /ansible s názvom playbook.yml a skús spustiť:

ansible-playbook ./playbook.yml

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

Ansible hovorí, že nepozná žiadnych hostiteľov, ktorí zodpovedajú zoznamu všetkých. Musia byť uvedené v osobitnom inventarizačný súbor.

Vytvorme ho v rovnakom adresári ansible:

123.123.123.123

Takto jednoducho určíme hostiteľa (ideálne hostiteľa nášho VPS na testovanie, alebo si môžete zaregistrovať localhost) a uložíme ho pod názvom inventory.
Môžete skúsiť spustiť ansible so súborom inventára:

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

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

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

Ak máte ssh prístup k určenému hostiteľovi, potom sa ansible pripojí a zhromaždí informácie o vzdialenom systéme. (predvolená ÚLOHA [Gathering Facts]), po ktorej vydá krátku správu o vykonaní (PLAY RECAP).

Štandardne sa pri pripojení používa používateľské meno, pod ktorým ste prihlásený do systému. S najväčšou pravdepodobnosťou to nebude na hostiteľovi. V súbore playbook môžete pomocou direktívy remote_user určiť, ktorý používateľ sa má použiť na pripojenie. Informácie o vzdialenom systéme môžu byť pre vás často zbytočné a nemali by ste strácať čas ich zhromažďovaním. Túto úlohu možno tiež deaktivovať:

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

Skúste znova spustiť príručku a uistite sa, že pripojenie funguje. (Ak ste zadali užívateľa typu root, musíte zadať aj príkaz stať: true, aby ste získali zvýšené práva. Ako je napísané v dokumentácii: become set to ‘true’/’yes’ to activate privilege escalation. aj keď nie je celkom jasné prečo).

Možno dostanete chybu spôsobenú skutočnosťou, že ansible nemôže určiť interpret Pythonu, potom ho môžete zadať ručne:

ansible_python_interpreter: /usr/bin/python3 

Pomocou príkazu zistíte, kde máte python whereis python.

Inštalácia systémových balíkov

Štandardná distribúcia Ansible obsahuje mnoho modulov pre prácu s rôznymi systémovými balíkmi, takže nemusíme z akéhokoľvek dôvodu písať bash skripty. Teraz potrebujeme jeden z týchto modulov na aktualizáciu systému a inštaláciu systémových balíkov. Na svojom VPS mám Ubuntu Linux, takže na inštaláciu balíkov používam apt-get и modul na to. Ak používate iný operačný systém, možno budete potrebovať iný modul (nezabudnite, že som na začiatku povedal, že musíme vopred vedieť, čo a ako budeme robiť). Syntax však bude s najväčšou pravdepodobnosťou podobná.

Doplňme našu príručku o prvé úlohy:

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

  tasks:
    - name: Update system
      apt: update_cache=yes
    - name: Install system dependencies
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

Úloha je presne tá úloha, ktorú Ansible vykoná na vzdialených serveroch. Úlohe dáme názov, aby sme mohli sledovať jej vykonanie v protokole. A pomocou syntaxe konkrétneho modulu popíšeme, čo má robiť. V tomto prípade apt: update_cache=yes - hovorí o aktualizácii systémových balíkov pomocou modulu apt. Druhý príkaz je trochu komplikovanejší. Odovzdáme modul apt zoznam balíkov a povieme, že sú state by sa mal stať present, to znamená, že nainštalujte tieto balíky. Podobným spôsobom im môžeme povedať, aby ich vymazali, alebo ich jednoduchou zmenou aktualizovali state. Upozorňujeme, že na to, aby koľajnice fungovali s postgresql, potrebujeme balík postgresql-contrib, ktorý práve inštalujeme. Opäť to musíte vedieť a urobiť to; ansible to sám o sebe neurobí.

Skúste znova spustiť príručku a skontrolujte, či sú balíky nainštalované.

Vytváranie nových používateľov.

Pre prácu s používateľmi má Ansible aj modul – používateľ. Pridajme ešte jednu úlohu (už známe časti playbooku som schoval za komentáre, aby som ho zakaždým nekopíroval celý):

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

Vytvoríme nového užívateľa, nastavíme mu schému a heslo. A potom narazíme na niekoľko problémov. Čo ak sa musia používateľské mená pre rôznych hostiteľov líšiť? A ukladanie hesla v čistom texte v playbooku je veľmi zlý nápad. Na začiatok dáme používateľské meno a heslo do premenných a na konci článku ukážem, ako heslo zašifrovať.

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

Premenné sú nastavené v zošitoch pomocou dvojitých zložených zátvoriek.

Hodnoty premenných uvedieme v inventárnom súbore:

123.123.123.123

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

Vezmite prosím na vedomie smernicu [all:vars] - hovorí, že ďalším blokom textu sú premenné (vars) a sú použiteľné pre všetkých hostiteľov (všetky).

Zaujímavý je aj dizajn "{{ user_password | password_hash('sha512') }}". Ide o to, že ansible nenainštaluje užívateľa cez user_add ako by ste to robili ručne. A všetky dáta ukladá priamo, preto musíme heslo vopred previesť na hash, čo robí tento príkaz.

Pridajme nášho používateľa do skupiny sudo. Predtým sa však musíme uistiť, že takáto skupina existuje, pretože to za nás nikto neurobí:

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

Všetko je celkom jednoduché, máme tu aj skupinový modul na vytváranie skupín, so syntaxou veľmi podobnou apt. Potom už stačí túto skupinu používateľovi zaregistrovať (groups: "sudo").
Je tiež užitočné pridať tomuto používateľovi kľúč ssh, aby sme sa pomocou neho mohli prihlásiť bez hesla:

---
- name: Simple playbook
  # ...
  tasks:
    # ...
    - name: Ensure a 'sudo' group
      group:
      name: sudo
        state: present
    - name: Add a new user
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: Deploy SSH Key
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

V tomto prípade je zaujímavý dizajn "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — skopíruje obsah súboru id_rsa.pub (vaše meno sa môže líšiť), teda verejnú časť kľúča ssh a nahrá ho do zoznamu autorizovaných kľúčov pre používateľa na serveri.

role

Všetky tri úlohy na vytváranie použitia sa dajú jednoducho zaradiť do jednej skupiny úloh a túto skupinu by bolo dobré uložiť oddelene od hlavného playbooku, aby sa príliš nezväčšila. Na tento účel má Ansible rolí.
Podľa štruktúry súborov uvedenej na úplnom začiatku musia byť role umiestnené v samostatnom adresári rolí, pre každú rolu existuje samostatný adresár s rovnakým názvom, v adresári úloh, súborov, šablón atď.
Vytvorme štruktúru súboru: ./ansible/roles/user/tasks/main.yml (main je hlavný súbor, ktorý sa načíta a spustí, keď je rola pripojená k playbooku; možno k nemu pripojiť ďalšie súbory rolí). Teraz môžete do tohto súboru preniesť všetky úlohy súvisiace s používateľom:

# Create user and add him to groups
- name: Ensure a 'sudo' group
  group:
    name: sudo
    state: present

- name: Add a new user
  user:
    name: "{{ user }}"
    shell: /bin/bash
    password: "{{ user_password | password_hash('sha512') }}"
    groups: "sudo"

- name: Deploy SSH Key
  authorized_key:
    user: "{{ user }}"
    key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
    state: present

V hlavnej príručke musíte zadať, aby ste použili rolu používateľa:

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

  tasks:
    - name: Update system
      apt: update_cache=yes
    - name: Install system dependencies
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

  roles:
    - user

Tiež môže mať zmysel aktualizovať systém pred všetkými ostatnými úlohami; na tento účel môžete premenovať blok tasks v ktorom sú definované v pre_tasks.

Nastavenie nginx

Nginx by sme už mali mať nainštalovaný, musíme ho nakonfigurovať a spustiť. Urobme to hneď v úlohe. Vytvorme štruktúru súboru:

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

Teraz potrebujeme súbory a šablóny. Rozdiel medzi nimi je v tom, že ansible kopíruje súbory priamo, tak ako je. Šablóny musia mať príponu j2 a môžu používať premenné hodnoty pomocou rovnakých dvojitých zložených zátvoriek.

Povoľme nginx in main.yml súbor. Na to máme systémový modul:

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

Tu nielen hovoríme, že nginx musí byť spustený (to znamená, že ho spustíme), ale hneď hovoríme, že musí byť povolený.
Teraz skopírujeme konfiguračné súbory:

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

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'

Vytvárame hlavný konfiguračný súbor nginx (môžete ho prevziať priamo zo servera alebo si ho napísať sami). A tiež konfiguračný súbor pre našu aplikáciu v adresári sites_available (nie je to potrebné, ale užitočné). V prvom prípade použijeme na kopírovanie súborov modul kopírovania (súbor musí byť v /ansible/roles/nginx/files/nginx.conf). V druhom skopírujeme šablónu a nahradíme hodnoty premenných. Šablóna by mala byť in /ansible/roles/nginx/templates/my_app.j2). A môže to vyzerať nejako takto:

upstream {{ app_name }} {
  server unix:{{ app_path }}/shared/tmp/sockets/puma.sock;
}

server {
  listen 80;
  server_name {{ server_name }} {{ inventory_hostname }};
  root {{ app_path }}/current/public;

  try_files $uri/index.html $uri.html $uri @{{ app_name }};
  ....
}

Venujte pozornosť vložkám {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — toto sú všetky premenné, ktorých hodnoty Ansible pred kopírovaním nahradí do šablóny. Je to užitočné, ak používate príručku pre rôzne skupiny hostiteľov. Napríklad môžeme pridať náš inventárny súbor:

[production]
123.123.123.123

[staging]
231.231.231.231

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

[production:vars]
server_name=production
app_path=/home/www/my_app
app_name=my_app

[staging:vars]
server_name=staging
app_path=/home/www/my_stage
app_name=my_stage_app

Ak teraz spustíme našu príručku, vykoná zadané úlohy pre oboch hostiteľov. Zároveň sa však pre hostiteľa inscenácie budú premenné líšiť od produkčných, a to nielen v rolách a playbookoch, ale aj v konfiguráciách nginx. {{ inventory_hostname }} nemusia byť uvedené v inventárnom spise - toto špeciálna ansible premenná a tam je uložený hostiteľ, pre ktorý je playbook momentálne spustený.
Ak chcete mať súbor inventára pre niekoľko hostiteľov, ale spustiť iba pre jednu skupinu, môžete to urobiť pomocou nasledujúceho príkazu:

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

Ďalšou možnosťou je mať samostatné súbory inventára pre rôzne skupiny. Alebo môžete tieto dva prístupy skombinovať, ak máte veľa rôznych hostiteľov.

Vráťme sa k nastaveniu nginx. Po skopírovaní konfiguračných súborov musíme v sitetest_enabled vytvoriť symbolický odkaz na my_app.conf z lokality sites_available. A reštartujte nginx.

... # old code in mail.yml

- name: Create symlink to sites-enabled
  file:
    src: /etc/nginx/sites-available/my_app.conf
    dest: /etc/nginx/sites-enabled/my_app.conf
    state: link

- name: restart nginx
  service:
    name: nginx
    state: restarted

Všetko je tu jednoduché - opäť ansible moduly s pomerne štandardnou syntaxou. Ale je tu jeden bod. Nemá zmysel zakaždým reštartovať nginx. Všimli ste si, že nepíšeme príkazy ako: „urob to takto“, syntax vyzerá skôr ako „toto by malo mať tento stav“. A najčastejšie presne takto funguje ansible. Ak skupina už existuje alebo je už nainštalovaný systémový balík, ansible to skontroluje a preskočí úlohu. Súbory sa tiež neskopírujú, ak sa úplne zhodujú s tým, čo je už na serveri. Môžeme to využiť a reštartovať nginx iba v prípade, že boli zmenené konfiguračné súbory. Na to existuje smernica o registri:

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

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes
  register: restart_nginx

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'
  register: restart_nginx

- name: Create symlink to sites-enabled
  file:
    src: /etc/nginx/sites-available/my_app.conf
    dest: /etc/nginx/sites-enabled/my_app.conf
    state: link

- name: restart nginx
  service:
    name: nginx
    state: restarted
  when: restart_nginx.changed

Ak sa zmení jeden z konfiguračných súborov, vytvorí sa kópia a premenná sa zaregistruje restart_nginx. A iba ak bola táto premenná zaregistrovaná, služba sa reštartuje.

A, samozrejme, musíte pridať rolu nginx do hlavnej príručky.

Nastavenie postgresql

Musíme povoliť postgresql pomocou systemd rovnakým spôsobom, ako sme to urobili s nginx, a tiež vytvoriť používateľa, ktorého budeme používať na prístup k databáze a samotnej databáze.
Vytvorme rolu /ansible/roles/postgresql/tasks/main.yml:

# Create user in postgresql
- name: enable postgresql and start
  systemd:
    name: postgresql
    state: started
    enabled: yes

- name: Create database user
  become_user: postgres
  postgresql_user:
    name: "{{ db_user }}"
    password: "{{ db_password }}"
    role_attr_flags: SUPERUSER

- name: Create database
  become_user: postgres
  postgresql_db:
    name: "{{ db_name }}"
    encoding: UTF-8
    owner: "{{ db_user }}"

Nebudem popisovať, ako pridať premenné do inventára, to už bolo urobené veľakrát, rovnako ako syntax modulov postgresql_db a postgresql_user. Viac informácií nájdete v dokumentácii. Tu je najzaujímavejšia smernica become_user: postgres. Faktom je, že štandardne má prístup k databáze postgresql iba používateľ postgres a iba lokálne. Táto smernica nám umožňuje vykonávať príkazy v mene tohto používateľa (samozrejme, ak máme prístup).
Možno budete musieť pridať riadok do pg_hba.conf, aby ste umožnili novému používateľovi prístup k databáze. Dá sa to urobiť rovnakým spôsobom, ako sme zmenili konfiguráciu nginx.

A samozrejme, musíte pridať postgresql úlohu do hlavnej príručky.

Inštalácia ruby ​​cez rbenv

Ansible nemá moduly na prácu s rbenv, ale inštaluje sa naklonovaním git repozitára. Preto sa tento problém stáva najneštandardnejším. Vytvorme pre ňu rolu /ansible/roles/ruby_rbenv/main.yml a začneme ho vypĺňať:

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

Opäť používame direktívu stať sa_užívateľom, aby sme fungovali pod používateľom, ktorého sme na tieto účely vytvorili. Keďže rbenv je nainštalovaný vo svojom domovskom adresári, a nie globálne. A tiež používame modul git na klonovanie úložiska, pričom špecifikujeme repo a dest.

Ďalej musíme zaregistrovať rbenv init v bashrc a tam pridať rbenv do PATH. Na to máme modul lineinfile:

- name: Add rbenv to PATH
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'export PATH="${HOME}/.rbenv/bin:${PATH}"'

- name: Add rbenv init to bashrc
  become_user: "{{ user }}"
  lineinfile:
    path: ~/.bashrc
    state: present
    line: 'eval "$(rbenv init -)"'

Potom musíte nainštalovať ruby_build:

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

A nakoniec nainštalujte ruby. To sa deje prostredníctvom rbenv, teda jednoducho pomocou príkazu bash:

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

Hovoríme, ktorý príkaz vykonať a čím. Tu však narážame na fakt, že ansible pred spustením príkazov nespustí kód obsiahnutý v bashrc. To znamená, že rbenv bude musieť byť definovaný priamo v tom istom skripte.

Ďalší problém je spôsobený skutočnosťou, že príkaz shell nemá z ansible hľadiska žiadny stav. To znamená, že nebude automatická kontrola, či je táto verzia ruby ​​nainštalovaná alebo nie. Môžeme to urobiť sami:

- name: Install ruby
  become_user: "{{ user }}"
  shell: |
    export PATH="${HOME}/.rbenv/bin:${PATH}"
    eval "$(rbenv init -)"
    if ! rbenv versions | grep -q {{ ruby_version }}
      then rbenv install {{ ruby_version }} && rbenv global {{ ruby_version }}
    fi
  args:
    executable: /bin/bash

Zostáva len nainštalovať bundler:

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

A opäť pridajte našu rolu ruby_rbenv do hlavnej príručky.

Zdieľané súbory.

Vo všeobecnosti tu môžete dokončiť nastavenie. Ďalej už zostáva len spustiť capistrano a to si sám skopíruje kód, vytvorí potrebné adresáre a spustí aplikáciu (ak je všetko správne nakonfigurované). Capistrano však často vyžaduje dodatočné konfiguračné súbory, ako napr database.yml alebo .env Dajú sa skopírovať rovnako ako súbory a šablóny pre nginx. Je tu len jedna jemnosť. Pred kopírovaním súborov musíte pre ne vytvoriť adresárovú štruktúru, napríklad:

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

zadáme iba jeden adresár a ansible v prípade potreby automaticky vytvorí nadradený.

Ansible Vault

Už sme sa stretli s tým, že premenné môžu obsahovať tajné údaje, ako napríklad heslo používateľa. Ak ste vytvorili .env súbor k žiadosti a database.yml potom musí byť takýchto kritických údajov ešte viac. Bolo by dobré ich skryť pred zvedavými očami. Na tento účel sa používa možná klenba.

Vytvorme súbor pre premenné /ansible/vars/all.yml (tu môžete vytvoriť rôzne súbory pre rôzne skupiny hostiteľov, rovnako ako v súbore inventára: production.yml, staging.yml atď.).
Všetky premenné, ktoré musia byť zašifrované, musia byť prenesené do tohto súboru pomocou štandardnej syntaxe yml:

# System vars
user_password: 123qweasd
db_password: 123qweasd

# ENV vars
aws_access_key_id: xxxxx
aws_secret_access_key: xxxxxx
aws_bucket: bucket_name
rails_secret_key_base: very_secret_key_base

Potom je možné tento súbor zašifrovať príkazom:

ansible-vault encrypt ./vars/all.yml

Pri šifrovaní budete samozrejme musieť nastaviť heslo na dešifrovanie. Po zavolaní tohto príkazu môžete vidieť, čo bude v súbore.

Prostredníctvom ansible-vault decrypt súbor je možné dešifrovať, upraviť a potom znova zašifrovať.

Aby ste mohli pracovať, nemusíte súbor dešifrovať. Uložíte ho zašifrovaný a spustíte playbook s argumentom --ask-vault-pass. Ansible požiada o heslo, získa premenné a vykoná úlohy. Všetky dáta zostanú zašifrované.

Kompletný príkaz pre niekoľko skupín hostiteľov a ansible vault bude vyzerať asi takto:

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

Ale nedám vám celý text zošitov a rolí, napíšte si to sami. Pretože ansible je taký - ak nerozumiete tomu, čo je potrebné urobiť, neurobí to za vás.

Zdroj: hab.com

Pridať komentár