ProHoster > Blogi > Haldamine > Serveri konfigureerimine Rails-rakenduse juurutamiseks Ansible abil

Serveri konfigureerimine Rails-rakenduse juurutamiseks Ansible abil

Mitte kaua aega tagasi oli mul vaja kirjutada mitu Ansible'i mänguraamatut, et valmistada server ette Railsi rakenduse juurutamiseks. Ja üllataval kombel ei leidnud ma lihtsat samm-sammult käsiraamatut. Ma ei tahtnud kopeerida kellegi teise mänguraamatut, mõistmata, mis toimub, ja lõpuks pidin lugema dokumentatsiooni, kogudes kõik ise kokku. Võib-olla saan aidata kellelgi selle artikli abil seda protsessi kiirendada.

Esimene asi, mida tuleb mõista, on see, et ansible pakub teile mugavat liidest, mille abil saate SSH-i kaudu kaugserveris(t)es teha eelmääratletud toimingute loendi. Siin pole mingit maagiat, te ei saa installida pistikprogrammi ega saada oma rakendust ilma seisakuta koos doki, seire ja muude hüvedega karbist välja. Mänguraamatu kirjutamiseks peate teadma, mida täpselt soovite teha ja kuidas seda teha. Seetõttu ei ole ma rahul GitHubi valmis juhendite ega artiklitega nagu "Kopeeri ja käivita, see töötab."

Mida me vajame?

Nagu ma juba ütlesin, peate mänguraamatu kirjutamiseks teadma, mida soovite teha ja kuidas seda teha. Otsustame, mida vajame. Railsi rakenduse jaoks vajame mitut süsteemipaketti: nginx, postgresql (redis jne). Lisaks vajame rubiini spetsiifilist versiooni. Kõige parem on see installida rbenv kaudu (rvm, asdf...). Kõige selle juurkasutajana käitamine on alati halb mõte, seega tuleb luua eraldi kasutaja ja seadistada tema õigused. Pärast seda peate meie koodi serverisse üles laadima, kopeerima nginxi, postgresi jne konfiguratsioonid ja käivitama kõik need teenused.

Selle tulemusena on toimingute jada järgmine:

  1. Logi sisse administraatorina
  2. installige süsteemipaketid
  3. loo uus kasutaja, seadista õigused, ssh-võti
  4. konfigureerige süsteemipaketid (nginx jne) ja käivitage need
  5. Loome andmebaasis kasutaja (andmebaasi saate kohe luua)
  6. Logi sisse uue kasutajana
  7. Installige rbenv ja ruby
  8. Kimpu paigaldamine
  9. Rakenduse koodi üleslaadimine
  10. Puma serveri käivitamine

Veelgi enam, viimaseid etappe saab teha capistrano abil, vähemalt karbist välja võttes saab see kopeerida koodi väljalaskekataloogidesse, vahetada väljalaske edukal juurutamisel symlinkiga, kopeerida konfiguratsioone jagatud kataloogist, taaskäivitada puma jne. Seda kõike saab teha Ansible abil, aga miks?

Faili struktuur

Ansible on range faili struktuur kõigi failide jaoks, seega on kõige parem hoida seda kõike eraldi kataloogis. Pealegi pole nii oluline, kas see on rööbaste rakenduses endas või eraldi. Saate salvestada faile eraldi git-hoidlasse. Isiklikult pidasin kõige mugavamaks luua rails rakenduse /config kataloogis võimalik kataloog ja salvestada kõik ühes hoidlas.

Lihtne mänguraamat

Playbook on yml-fail, mis spetsiaalse süntaksi abil kirjeldab, mida ja kuidas Ansible peaks tegema. Loome esimese mänguraamatu, mis ei tee midagi:

---
- name: Simple playbook
  hosts: all

Siin ütleme lihtsalt, et meie mänguraamat on nn Simple Playbook ja et selle sisu tuleks käivitada kõigi hostide jaoks. Saame selle nimega salvestada kataloogi /ansible playbook.yml ja proovige joosta:

ansible-playbook ./playbook.yml

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

Ansible ütleb, et ta ei tea ühtegi hosti, mis vastaks kõigi loendile. Need peavad olema eriloendis loetletud inventuurifail.

Loome selle samasse võimalikku kataloogi:

123.123.123.123

Nii me lihtsalt määrame hosti (ideaaljuhul meie VPS-i hosti testimiseks või võite registreerida kohaliku hosti) ja salvestame selle nime alla inventory.
Võite proovida käivitada ansible koos inventuurifailiga:

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

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

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

Kui teil on määratud hostile ssh-juurdepääs, loob ansible ühenduse ja kogub teavet kaugsüsteemi kohta. (vaikeülesanne [Faktide kogumine]), misjärel esitab see täitmise kohta lühikese aruande (PLAY RECAP).

Vaikimisi kasutab ühendus kasutajanime, mille all olete süsteemi sisse logitud. Tõenäoliselt ei ole see hostis. Mänguraamatu failis saate määrata, millist kasutajat kasutada ühenduse loomiseks, kasutades käskkirja remote_user. Samuti võib teave kaugsüsteemi kohta sageli olla teile ebavajalik ja te ei tohiks selle kogumisele aega raisata. Selle ülesande saab ka keelata:

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

Proovige mänguraamatut uuesti käivitada ja veenduge, et ühendus töötab. (Kui määrasite juurkasutaja, siis peate kõrgendatud õiguste saamiseks määrama ka käsu muutuda: true. Nagu dokumentatsioonis kirjas: become set to ‘true’/’yes’ to activate privilege escalation. kuigi pole täiesti selge, miks).

Võib-olla kuvatakse teile tõrketeade, mille põhjuseks on asjaolu, et ansible ei suuda Pythoni tõlgendajat määrata, siis saate selle käsitsi määrata:

ansible_python_interpreter: /usr/bin/python3

Käsuga saate teada, kus teil python on whereis python.

Süsteemipakettide installimine

Ansible standarddistributsioon sisaldab palju mooduleid erinevate süsteemipakettidega töötamiseks, nii et me ei pea mingil põhjusel bash-skripte kirjutama. Nüüd vajame ühte neist moodulitest süsteemi värskendamiseks ja süsteemipakettide installimiseks. Minu VPS-is on Ubuntu Linux, seega kasutan pakettide installimiseks apt-get и moodul selle jaoks. Kui kasutate teist operatsioonisüsteemi, siis võib vaja minna teistsugust moodulit (pidage meeles, ma ütlesin alguses, et me peame eelnevalt teadma, mida ja kuidas teeme). Tõenäoliselt on süntaks siiski sarnane.

Täiendame oma mänguraamatut esimeste ülesannetega:

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

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

Ülesanne on täpselt see ülesanne, mida Ansible kaugserverites täidab. Anname ülesandele nime, et saaksime selle täitmist logis jälgida. Ja me kirjeldame konkreetse mooduli süntaksi abil, mida see tegema peab. Sel juhul apt: update_cache=yes - ütleb süsteemipakettide värskendamiseks apt mooduli abil. Teine käsk on veidi keerulisem. Edastame pakettide loendi apt-moodulile ja ütleme, et need on nii state peaks saama present, see tähendab, et installige need paketid. Samamoodi saame käskida neil need kustutada või lihtsalt muutes värskendada state. Pange tähele, et rööbaste töötamiseks postgresql-iga vajame paketti postgresql-contrib, mida me praegu installime. Jällegi peate seda teadma ja tegema; ansible üksi seda ei tee.

Proovige mänguraamatut uuesti käivitada ja kontrollige, kas paketid on installitud.

Uute kasutajate loomine.

Kasutajatega töötamiseks on Ansiblel ka moodul – kasutaja. Lisame veel ühe ülesande (peitsin mänguraamatu juba teadaolevad osad kommentaaride taha, et mitte iga kord tervenisti kopeerida): 

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

Loome uue kasutaja, määrame sellele shelli ja parooli. Ja siis puutume kokku mitme probleemiga. Mis siis, kui erinevate hostide kasutajanimed peavad olema erinevad? Ja parooli salvestamine selge tekstina mänguraamatusse on väga halb mõte. Alustuseks paneme kasutajanime ja parooli muutujateks ning artikli lõpupoole näitan, kuidas parooli krüptida.

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

Muutujad määratakse mänguraamatutes topeltkõverate sulgude abil.

Näitame inventuurifailis muutujate väärtused:

123.123.123.123

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

Pange tähele direktiivi [all:vars] - see ütleb, et järgmine tekstiplokk on muutujad (vars) ja need on rakendatavad kõikidele hostidele (kõikidele).

Disain on ka huvitav "{{ user_password | password_hash('sha512') }}". Asi on selles, et ansible ei installi kasutajat selle kaudu user_add nagu teeksite seda käsitsi. Ja see salvestab kõik andmed otse, mistõttu peame ka parooli eelnevalt räsi muutma, mida see käsk teeb.

Lisame oma kasutaja sudo gruppi. Kuid enne seda peame veenduma, et selline rühm on olemas, sest keegi ei tee seda meie eest:

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

Kõik on üsna lihtne, meil on rühmade loomiseks ka grupimoodul, mille süntaks on väga sarnane apt-le. Siis piisab selle grupi registreerimisest kasutajale (groups: "sudo").
Samuti on kasulik lisada sellele kasutajale ssh-võti, et saaksime seda kasutades sisse logida ilma paroolita:

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

Sel juhul on disain huvitav "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — kopeerib faili id_rsa.pub sisu (teie nimi võib olla erinev), st ssh-võtme avaliku osa ja laadib selle üles serveris kasutaja jaoks volitatud võtmete loendisse.

Rollid

Kõik kolm kasutuse loomise ülesannet saab hõlpsasti liigitada ühte ülesannete rühma ja see rühm oleks hea salvestada põhimänguraamatust eraldi, et see liiga suureks ei kasvaks. Selleks on Ansible roll.
Vastavalt kohe alguses märgitud failistruktuurile tuleb rollid paigutada eraldi rollide kataloogi, iga rolli jaoks on eraldi samanimeline kataloog ülesannete, failide, mallide jne kataloogis
Loome failistruktuuri: ./ansible/roles/user/tasks/main.yml (main on peamine fail, mis laaditakse ja käivitatakse, kui roll on mänguraamatuga ühendatud; sellega saab ühendada muid rollifaile). Nüüd saate kõik kasutajaga seotud ülesanded sellesse faili üle kanda:

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

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

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

Peamises mänguraamatus peate kasutajarolli kasutamiseks määrama:

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

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

  roles:
    - user

Samuti võib olla mõttekas värskendada süsteemi enne kõiki muid toiminguid; selleks saate ploki ümber nimetada tasks milles need on määratletud pre_tasks.

Nginxi seadistamine

Meil peaks olema juba installitud Nginx; peame selle konfigureerima ja käivitama. Teeme seda kohe rollis. Loome failistruktuuri:

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

Nüüd vajame faile ja malle. Nende erinevus seisneb selles, et ansible kopeerib failid otse, nagu on. Ja mallidel peab olema laiend j2 ja nad saavad kasutada muutuvaid väärtusi, kasutades samu topeltkõveraid sulgusid.

Lubame nginxi sisse main.yml faili. Selleks on meil süsteemne moodul:

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

Siin me mitte ainult ei ütle, et nginx tuleb käivitada (st käivitame selle), vaid ütleme kohe, et see peab olema lubatud.
Nüüd kopeerime konfiguratsioonifailid:

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

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

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

Loome peamise nginxi konfiguratsioonifaili (saate selle otse serverist võtta või ise kirjutada). Ja ka meie rakenduse konfiguratsioonifail kataloogis sites_available (see pole vajalik, kuid kasulik). Esimesel juhul kasutame failide kopeerimiseks kopeerimismoodulit (fail peab olema sees /ansible/roles/nginx/files/nginx.conf). Teises kopeerime malli, asendades muutujate väärtused. Mall peaks sees olema /ansible/roles/nginx/templates/my_app.j2). Ja see võib välja näha umbes selline:

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

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

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

Pöörake tähelepanu sisestustele {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — need on kõik muutujad, mille väärtused Ansible asendavad malli enne kopeerimist. See on kasulik, kui kasutate erinevate võõrustajate rühmade jaoks mänguraamatut. Näiteks saame lisada oma laofaili:

[production]
123.123.123.123

[staging]
231.231.231.231

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

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

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

Kui käivitame nüüd oma mänguraamatu, täidab see mõlema hosti jaoks määratud ülesandeid. Kuid samal ajal on lavastusjuhi jaoks muutujad tootmisomadustest erinevad ja mitte ainult rollides ja mänguraamatutes, vaid ka nginxi konfiguratsioonides. {{ inventory_hostname }} ei pea inventuurifailis täpsustama – see spetsiaalne võimalik muutuja ja host, mille jaoks mänguraamat parasjagu töötab, on sinna salvestatud.
Kui soovite andmefaili mitme hosti jaoks, kuid soovite töötada ainult ühe rühma jaoks, saate seda teha järgmise käsuga:

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

Teine võimalus on eri rühmade jaoks eraldi laofailid. Või võite need kaks lähenemisviisi kombineerida, kui teil on palju erinevaid hoste.

Läheme tagasi nginxi seadistamise juurde. Pärast konfiguratsioonifailide kopeerimist peame failis sitest_enabled looma saidilt sites_available faili my_app.conf sümlingi. Ja taaskäivitage nginx.

... # old code in mail.yml

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

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

Siin on kõik lihtne - jällegi võimalikud moodulid üsna standardse süntaksiga. Kuid on üks punkt. Pole mõtet nginxi iga kord taaskäivitada. Kas olete märganud, et me ei kirjuta selliseid käske nagu: "tee seda nii", süntaks näeb pigem välja selline: "sellel peaks olema selline olek". Ja enamasti töötab ansible täpselt nii. Kui rühm on juba olemas või süsteemipakett on juba installitud, kontrollib ansible seda ja jätab ülesande vahele. Samuti ei kopeerita faile, kui need vastavad täielikult serveris juba olevale. Saame seda ära kasutada ja nginxi taaskäivitada ainult siis, kui konfiguratsioonifaile on muudetud. Selle jaoks on olemas registri käskkiri:

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

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

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

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

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

Kui üks konfiguratsioonifailidest muutub, tehakse koopia ja muutuja registreeritakse restart_nginx. Ja ainult siis, kui see muutuja on registreeritud, taaskäivitatakse teenus.

Ja loomulikult peate nginxi rolli lisama põhijuhendisse.

Postgresql seadistamine

Peame lubama postgresqli, kasutades systemd samamoodi nagu nginxi puhul, ning looma ka kasutaja, mida kasutame andmebaasile ja andmebaasile juurdepääsuks.
Loome rolli /ansible/roles/postgresql/tasks/main.yml:

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

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

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

Ma ei hakka kirjeldama, kuidas varudesse muutujaid lisada, seda on juba korduvalt tehtud, nagu ka postgresql_db ja postgresql_user moodulite süntaksit. Lisateavet leiate dokumentatsioonist. Kõige huvitavam direktiiv on siin become_user: postgres. Fakt on see, et vaikimisi on postgresql-i andmebaasile juurdepääs ainult postgresi kasutajal ja ainult lokaalselt. See direktiiv võimaldab meil selle kasutaja nimel käske täita (muidugi juhul, kui meil on juurdepääs).
Samuti peate võib-olla lisama faili pg_hba.conf rea, et võimaldada uuel kasutajal andmebaasile juurdepääs. Seda saab teha samamoodi nagu me muutsime nginxi konfiguratsiooni.

Ja loomulikult peate põhijuhendisse lisama postgresqli rolli.

Rubiini paigaldamine rbenv kaudu

Ansiblel pole rbenv-ga töötamiseks mooduleid, kuid see installitakse git-hoidla kloonimise teel. Seetõttu muutub see probleem kõige ebastandardsemaks. Loome talle rolli /ansible/roles/ruby_rbenv/main.yml ja hakkame seda täitma:

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

Me kasutame jällegi käskkirja "muutu_kasutaja", et töötada selle kasutaja all, mille me nendel eesmärkidel lõime. Kuna rbenv on installitud selle kodukataloogi, mitte globaalselt. Samuti kasutame hoidla kloonimiseks git-moodulit, määrates repo ja sihtpunkti.

Järgmiseks peame registreerima rbenv init kataloogis bashrc ja lisama rbenv sinna PATH-i. Selleks on meil lineinfile moodul:

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

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

Seejärel peate installima ruby_build:

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

Ja lõpuks installige rubiin. Seda tehakse rbenv kaudu, st lihtsalt käsuga bash:

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

Me ütleme, millist käsku täita ja millega. Siin puutume aga kokku tõsiasjaga, et ansible ei käivita enne käskude käivitamist bashrc-is sisalduvat koodi. See tähendab, et rbenv tuleb määratleda otse samas skriptis.

Järgmine probleem on tingitud asjaolust, et shelli käsul puudub olek mõistlikust vaatepunktist. See tähendab, et automaatset kontrolli ei toimu, kas see rubiini versioon on installitud või mitte. Seda saame ise teha:

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

Jääb üle vaid komplekteerija installida:

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

Ja jälle lisage meie roll ruby_rbenv põhijuhendisse.

Jagatud failid.

Üldiselt võiks siin seadistamise lõpule viia. Järgmiseks jääb üle vaid käivitada capistrano ja see kopeerib ise koodi, loob vajalikud kataloogid ja käivitab rakenduse (kui kõik on õigesti seadistatud). Capistrano nõuab aga sageli täiendavaid konfiguratsioonifaile, nt database.yml või .env Neid saab kopeerida nagu nginxi faile ja malle. On ainult üks peensus. Enne failide kopeerimist peate looma nende jaoks kataloogistruktuuri, mis on umbes selline:

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

me määrame ainult ühe kataloogi ja ansible loob vajadusel automaatselt vanemad kataloogid.

Ansible Vault

Oleme juba kohanud tõsiasja, et muutujad võivad sisaldada salajasi andmeid, näiteks kasutaja parooli. Kui olete loonud .env taotluse faili ja database.yml siis peab selliseid kriitilisi andmeid veelgi rohkem olema. Hea oleks neid võõraste pilkude eest varjata. Sel eesmärgil kasutatakse seda võimalik varahoidla.

Loome muutujate jaoks faili /ansible/vars/all.yml (siin saab luua erinevaid faile erinevatele hostirühmadele, täpselt nagu laofailis: production.yml, staging.yml jne).
Kõik muutujad, mis tuleb krüpteerida, tuleb sellesse faili üle kanda standardse ymli süntaksi abil:

# System vars
user_password: 123qweasd
db_password: 123qweasd

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

Pärast seda saab selle faili krüpteerida käsuga:

ansible-vault encrypt ./vars/all.yml

Loomulikult peate krüptimisel määrama dekrüpteerimiseks parooli. Pärast selle käsu kutsumist näete, mis faili sees on.

Abil ansible-vault decrypt faili saab dekrüpteerida, muuta ja seejärel uuesti krüptida.

Töötamiseks ei pea te faili dekrüpteerima. Salvestate selle krüpteeritult ja käivitate selle argumendiga mänguraamatu --ask-vault-pass. Ansible küsib parooli, hangib muutujad ja täidab ülesandeid. Kõik andmed jäävad krüpteerituks.

Mitme hostirühma ja ansible varahoidla täielik käsk näeb välja umbes selline:

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

Kuid ma ei anna teile näidendiraamatute ja rollide täisteksti, kirjutage see ise. Sest ansible on selline – kui sa ei saa aru, mida teha tuleb, siis ta seda sinu eest ei tee.

Allikas: www.habr.com

Lisa kommentaar