ProHoster > Blogi > Haldamine > Rails rakenduse rakendamiseks serveri seadistamine Ansible'i abil

Rails rakenduse rakendamiseks serveri seadistamine Ansible'i abil

Hiljuti pidin kirjutama mitu ansible playbook'i, et valmistada serverit ette Rails rakenduse juurdepÀÀsuks. Üllatuseks ei leidnud ma lihtsat samm-sammult manuaali. Ma ei soovinud kopeerida kellegi teise playbook'i ilma olukorrast aru saamata, seega pidin lĂ”puks lugema dokumentatsiooni ja kĂ”ike iseseisvalt koguma. Loodetavasti suudan ma kellegi jaoks seda protsessi kiirendada kĂ€esoleva artikli abil.

Esimese asjana on oluline mĂ”ista, et ansible pakub teile mugavat liidest ettenĂ€htud toimingute loendi teostamiseks kaugserveris (serverites) lĂ€bi SSH. Siin ei ole mingit maagiat, ei saa lihtsalt pluginaid paigaldada ja saada nullist seisakuta juurdepÀÀsu oma rakendusele koos Docker'i, monitooringu ja muude mugavustega. Et playbook'i kirjutada, peate teadma, mida tĂ€pselt soovite teha ja kuidas seda teha. SeetĂ”ttu ei rahulda mind valmis playbook'id GitHub'is vĂ”i artiklid, mis ĂŒtlevad: “Kopeerige ja kĂ€ivitage, — see töötab.”

Mida me vajame?

Nagu ma juba ĂŒtlesin, peab playbook'i kirjutamiseks teadma, mida soovite teha ja kuidas seda teha. MÀÀratletakse, mida me vajame. Rails rakenduse jaoks vajame mitut sĂŒsteemipaketti: nginx, postgresql (redis jne). Lisaks on meil vajalik teatud versiooni ruby. Parim on see paigaldada rbenvi (rvm, asdf...) kaudu. KĂ”ik see root kasutajana kĂ€ivitamine on alati halb mĂ”te, seega tuleks luua eraldi kasutaja ja seada tal Ă”igused. PĂ€rast seda tuleb meie kood serverisse ĂŒles laadida, kopeerida konfiguratsioonid nginx’ile, postgres’ile jne. ning kĂ€ivitada kĂ”ik need teenused.

KokkuvÔtteks on tegevuste jÀrjestus jÀrgmine:

  1. Logime sisse root'ina
  2. paigaldame sĂŒsteemipaketid
  3. loome uue kasutaja, seame Ôigused, ssh vÔtme
  4. seame sĂŒsteemipaketid (nginx jne) ja kĂ€ivitame need
  5. Loome kasutaja andmebaasis (vÔime kohe ka andmebaasi luua)
  6. Logime sisse uue kasutajana
  7. Paigaldame rbenv ja ruby
  8. Paigaldame bundleri
  9. Laeme rakenduskoodi ĂŒles
  10. KĂ€ivitame Puma serveri

Ja viimaseid etappe saab teha Capistrano abil, vĂ€hemalt suudab see vĂ€lja anda koodi toimetada versioonide kaustadesse, vahetada vĂ€lja versioon sĂŒmboolse lingina pĂ€rast eduka juurutamist, kopeerida konfiguratsioonid jagatud kaustast, restartida Puma jne. KĂ”ike seda saab teha ka Ansible'i abil, aga miks?

Failistruktuur

Ansible'il on rangelt eemaldus failistruktuur kĂ”igi failide jaoks, seega on parim hoida need eraldi kaustas. Oluline pole, kas see kaust asub rails'i rakenduses vĂ”i on see eraldi. Faile saab hoida eraldi git-repositooriumis. Minu jaoks oli mugavaim luua ansible kaust rails'i rakenduse /config kausta ja hoida kĂ”ik ĂŒhes repositooriumis.

Lihtne Playbook

Playbook on yml fail, milles on spetsiaalse sĂŒntaksiga kirjeldatud, mida ja kuidas ansible peab tegema. Loome esimese playbooki, mis ei tee midagi:

---
- name: Lihtne playbook
  hosts: all

Siin ĂŒtleme lihtsalt, et meie playbooki nimi on Lihtne Playbook ja et tema sisu tuleb tĂ€ita kĂ”ikide hostide jaoks. Saame selle salvestada /ansible kausta nimega playbook.yml ja proovida kĂ€ivitada:

ansible-playbook ./playbook.yml

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

Ansible ĂŒtleb, et ei tea hoste, mis vastaksid nimekirjale all. Need tuleb eraldi mĂ€rkida spetsiaalses inventaarifailis..

Loome selle samasse ansible kausta:

123.123.123.123

Niimoodi lihtsalt nÀitame hosti (ideaalis oma VPS hosti testimiseks, vÔi vÔib ka localhost'i mÀrkida) ja salvestame selle nimega inventory.
VÔime proovida ansible't kÀivitada inventaarifailiga:

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

TASK [Faktide kogumine] ************************************************************************************************************************************

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

Kui teil on ssh juurdepÀÀs mĂ€rgitud hostile, siis ansible ĂŒhendub ja kogub teavet eemaloleva sĂŒsteemi kohta. (vaikimisi TASK [Faktide kogumine]) pĂ€rast seda annab see lĂŒhikese aruande tĂ€itmise kohta (PLAY RECAP).

K vaikimisi kasutatakse ĂŒhendamiseks teie sĂŒsteemi kasutajanime, millega olete sisse loginud. Hostil seda tĂ”enĂ€oliselt ei ole. Playbooki failis saab mÀÀrata, millist kasutajat kasutada ĂŒhendamisel remote_user direktiivi abil. Samuti vĂ”ib teave eemaloleva sĂŒsteemi kohta teile tihti olla jĂ€rgnemine ja ei tasuks aega selle kogumisele raisata. Selle ĂŒlesande saab samuti vĂ€lja lĂŒlitada:

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

Proovige playbook uuesti kĂ€ivitada ja veenduda, et ĂŒhendus töötab. (Kui olete mÀÀranud root kasutaja, tuleb samuti seadistada direktiiv become: true, et saada kĂ”rgendatud Ă”igused. Nagu on vĂ€ljendatud dokumentatsioonis: become on seadistatud 'true'/'yes' privileegide tĂ”stmiseks. kuigi pole pĂ€ris selge, miks.)

VÔimalik, et saate vea, mille pÔhjuseks on see, et ansible ei saa mÀÀrata Python'i tÔlgendajat, siis saab selle kÀsitsi mÀÀrata:

ansible_python_interpreter: /usr/bin/python3

Kus asub Python'i installatsioon, saate teada kÀsuga whereis python.

SĂŒsteemipakettide installimine

Ansible'i tavalisse komplekti kuulub palju mooduleid erinevate sĂŒsteemipakettidega töötamiseks, tĂ€nu millele ei pea me igal juhul bash skripte kirjutama. Praegu vajame ĂŒht neid mooduleid sĂŒsteemi vĂ€rskendamiseks ja sĂŒsteemipakettide installimiseks. Mul on VPS-is Ubuntu Linux, seetĂ”ttu kasutan pakettide installimiseks apt-get ja moodulit selle jaoks.Kui teie operatiivsystem on teine, on vĂ”imalik, et vajate muud moodulit (pidage meeles, et rÀÀkisin alguses, et tuleb ette teada, mida ja kuidas teha). Siiski peaks sĂŒntaks olema tĂ”enĂ€oliselt sarnane.

TĂ€iendame meie playbooki esimestest ĂŒlesannetest:

---
- name: Lihtne playbook
  hosts: kÔik
  remote_user: root
  become: true
  gather_facts: ei

  tasks:
    - name: VĂ€rskenda sĂŒsteemi
      apt: update_cache=jah
    - name: Installi sĂŒsteemi sĂ”ltuvused
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: olemas

Task — see on ĂŒlesanne, mida ansible tĂ€idab eemaldatud serverites. Anname ĂŒlesandele nime, et jĂ€lgida selle tĂ€itmist logis. Ja kirjeldame, kasutades konkreetse mooduli sĂŒntaksit, mida tal tuleb teha. Antud juhul apt: update_cache=jah — ĂŒtleb sĂŒsteemi pakettide vĂ€rskendamiseks mooduli apt abil. Teine kĂ€sk on natuke keerulisem. Edastame moodulile apt pakettide loendi ja ĂŒtlememe, et nende state peaks saama present, st ĂŒtleme, et need paketid tuleb installida. Samamoodi saame öelda, et need tuleb eemaldada vĂ”i vĂ€rskendada, lihtsalt vahetades state. Pange tĂ€hele, et Rails'i ja PostgreSQL'i töötamiseks vajame paketti postgresql-contrib, mille me praegu installime. Sellest tuleb samuti teada, ansible ĂŒksi seda teha ei oska.

Proovige playbooki uuesti kÀivitada ja kontrollida, et paketid installitakse.

Uute kasutajate loomine.

Ansible'il on ka kasutajatöötluseks moodul — user. Lisame veel ĂŒhe ĂŒlesande (oma teadmisi peidame mĂ€nguplaane kommenteerides, nii et ei peaks iga kord tervet plaani kopeerima):

---
- name: Lihtne mÀnguplaan
  # ...
  ĂŒlesanded:
    # ...
    - name: Lisa uus kasutaja
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

Loome uue kasutaja, mÀÀrame talle schelli ja parooli. Ja kohe kohtame mitmeid probleeme. Mis siis, kui kasutajanimed peavad eri hostide jaoks olema erinevad? Ja parooli hoidmine plaanis avatud kujul on vĂ€ga halb idee. Alustuseks viime kasutajanime ja parooli muutujatesse, ning artikli lĂ”pus nĂ€itan, kuidas parooli krĂŒptida.

---
- name: Lihtne mÀnguplaan
  # ...
  ĂŒlesanded:
    # ...
    - name: Lisa uus kasutaja
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

Topeltklambrite abil mÀnguplaanidesse muutujaid seadistatakse.

Muutujate vÀÀrtused mÀÀrame inventory failis:

123.123.123.123

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

Pange tĂ€hele direktiivi [all:vars] — see ĂŒtleb, et jĂ€rgmine tekstiblokk on muutujad (vars) ja need kehtivad kĂ”igi hostide (all) jaoks.

Samuti on huvitav konstruktsioon "{{ user_password | password_hash('sha512') }}". Asi on selles, et ansible ei lisa kasutajat kaudu user_add nagu te seda kÀsitsi teeksite. Ta salvestab kÔik andmed otse, seetÔttu peame ka parooli eelnevalt hash'ima, mida see kÀsk teeb.

Lisame oma kasutaja sudo rĂŒhma. Siiski, enne seda tuleb veenduda, et selline rĂŒhm on olemas, sest keegi teine ei tee seda meie eest:

---
- name: Lihtne mÀnguplaan
  # ...
  ĂŒlesanded:
    # ...
    - name: Veenduge, et 'sudo' rĂŒhm on olemas
      group:
        name: sudo
        state: present
    - name: Lisa uus kasutaja
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"

KĂ”ik on piisavalt lihtne, meil on ka rĂŒhma moodul grupi loomiseks, mille sĂŒntaks on vĂ€ga sarnane apt'iga. PĂ€rast seda piisab, kui mÀÀrata see rĂŒhm kasutajale (groups: "sudo").
Samuti on kasulik lisada sellele kasutajale ssh vÔti, et saaksime sisse logida tema alt ilma paroolita:

---
- name: Lihtne mÀnguplats
  # ...
  tasks:
    # ...
    - name: Veendu, et ‘sudo’ grupp on olemas
      group:
      name: sudo
        state: present
    - name: Lisa uus kasutaja
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: Paigalda SSH vÔtme
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

Selles kontekstis on huvitav konstruktsioon "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — see kopeerib faili id_rsa.pub sisu (teie failinimi vĂ”ib olla erinev), st SSH vĂ”tme avaliku osa ja laadib selle kasutaja volitatud vĂ”tmete nimekirja serveris.

Rollid

KĂ”iki kolme ĂŒlesannet, mis loovad kasutaja, vĂ”ib kergesti seostada ĂŒhte ĂŒlesannete gruppi, ja oleks hea hoida seda gruppi eraldi peamisest mĂ€nguplatsist, et see liiga suureks ei paisuks. Selleks on ansibless rollideks.
Vastavalt alguses kÀsitletud failistruktuurile on rollid vajalik paigutada eraldi kausta roles, iga rolli jaoks eraldi kaust sama nimega, sees kaustas tasks, files, templates jne.
Loome failistruktuuri: ./ansible/roles/user/tasks/main.yml (main — see on pĂ”hiline fail, mis laaditakse ja kĂ€ideldakse, kui roll on mĂ€nguplaadi kĂŒlge ĂŒhendatud, seal saab laadida teisi rolli faile). NĂŒĂŒd saab ĂŒle kanda kĂ”ik kasutajaga seotud ĂŒlesanded sellesse faili:

# 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Ànguplaadis on vajalik mÀrkida, et kasutatakse rolli user:

---
- name: Lihtne mÀnguplats
  hosts: all
  remote_user: root
  gather_facts: no

  tasks:
    - name: Uuenda sĂŒsteem
      apt: update_cache=yes
    - name: Installi sĂŒsteemi sĂ”ltuvused
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

  roles:
    - user

Samuti vĂ”ib olla mĂ”istlik sĂŒsteemi uuendamine teostada enne kĂ”iki teisi ĂŒlesandeid, sel juhul saab ploki ĂŒmber nimetada, tasks milles need on mÀÀratletud pre_tasks.

Nginx'i seadistamine

Nginx peab juba olema installitud, seda tuleb konfigureerida ja kÀivitada. Teeme seda kohe rollis. Loome failistruktuuri:

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

NĂŒĂŒd vajame faile ja malli. Erinevus nende vahel on see, et faile ansible kopeerib otse sellisena nagu nad on. Ja mallid peavad olema laiendiga j2 ja nendes saab kasutada muutujaid, kasutades samu kahefoolseid sulgusid.

Lisame nginx'i main.yml faili. Selleks on meil sĂŒsteemimoodul:

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

Siin mitte ainult ei ĂŒtleme, et nginx peab olema started (st kĂ€ime selle kĂ€ima), vaid ĂŒtleme kohe, et see peab olema enabled.
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 pÔhikonfiguratsioonifaili nginx (saame selle otse serverist vÔtta vÔi kirjutada ise). Samuti loome konfiguratsioonifaili meie rakenduse jaoks kaustas sites_available (see pole kohustuslik, kuid kasulik). Esimesel juhul kasutame failide kopeerimiseks copy moodulit (fail peab asuma /ansible/roles/nginx/files/nginx.conf). Teisel juhul kopeerime malli, asendades muutujate vÀÀrtused. Mall peab asuma /ansible/roles/nginx/templates/my_app.j2). Ja see vÔib vÀlja nÀha umbes nii:

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

Pange tĂ€hele sisestusi {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — need on kĂ”ik muutujad, mille vÀÀrtused ansible asendab mallis enne kopeerimist. See on kasulik, kui kasutada playbooki erinevate hostigruppide jaoks. NĂ€iteks saame tĂ€iendada meie inventory faili:

[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 meie playbooki, tĂ€idab see antud ĂŒlesandeid mĂ”lema hosti jaoks. Kuid samas staging hosti jaoks erinevad muutujad productionist, ja mitte ainult rollides ja playbookides, vaid ka nginx konfiguratsioonides. {{ inventory_hostname }} ei pea inventory failis mÀÀrama — see on eriline ansible muutuja ja seal hoitakse hosti, mille jaoks playbook praegu kĂ€ivitatakse.
Kui soovite, et oleks inventory fail mitme hosti jaoks, kuid kĂ€ivitada ainult ĂŒhele grupile, saate seda teha jĂ€rgmise kĂ€suga:

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

Teine variant on omada eraldi inventory faile erinevate grupide jaoks. VÔi saab kahte lÀhenemist kombineerida, kui teil on palju erinevaid hoste.

Tagasi nginx seadistamise juurde. PĂ€rast konfiguratsioonifailide kopeerimist peame looma sĂŒmboolse lingi sitest_enabled kaustas my_app.conf failist sites_available. Ja taaskĂ€ivitama nginx.

... # vana kood mail.yml

- name: Loo sĂŒmboolne link sites-enabled
  file:
    src: \/etc\/nginx\/sites-available\/my_app.conf
    dest: \/etc\/nginx\/sites-enabled\/my_app.conf
    state: link

- name: taaskÀivita nginx
  service:
    name: nginx
    state: restarted

Siin on kĂ”ik lihtne — jĂ€lle ansible moodulid, millel on piisavalt standardne sĂŒntaks. Siiski on ĂŒks moment. Nginx-i iga kord taaskĂ€ivitamine pole otstarbekas. Olete tĂ€hele pannud, et me ei kirjuta kĂ€ske nagu: „tee seda niimoodi“, sĂŒntaks nĂ€eb vĂ€lja pigem nagu „sellel peaks olema selline olek“. Ja enamasti just nii ansible töötabki. Kui grupp juba eksisteerib vĂ”i sĂŒsteemipakett on juba installitud, siis ansible kontrollib seda ja jĂ€tab ĂŒlesande vahele. Samuti ei kopeerita faile, kui need tĂ€ielikult kattuvad sellega, mis juba serveris on. Saame seda Ă€ra kasutada ja taaskĂ€ivitada nginx ainult siis, kui konfiguratsioonifailid on muutunud. Selle jaoks on olemas direktiiv register:

# 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, siis toimub kopeerimine ja muutuja registreeritakse restart_nginx. Ja ainult siis, kui see muutuja on registreeritud, toimub teenuse taaskĂ€ivitamine.

Ja muidugi tuleb lisada nginx roll peamisele playbookile.

PostgreSQL-i seadistamine

Peame aktiveerima postgresql sĂŒsteemisystemd tĂ€pselt nagu me tegime nginxiga ning looma kasutaja, mida me kasutame andmebaasi pÀÀsemiseks, samuti enda andmebaasi.
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 lisada muutujaid inventuuri, seda on juba korduvalt tehtud, samuti postgresql_db ja postgresql_user moodulite sĂŒntaks. Rohkem teavet leiate dokumentatsioonist. Siin on kĂ”ige huvitavam direktiiv become_user: postgres. Asi on selles, et vaikimisi on postgresql andmebaasile juurdepÀÀs ainult postgres kasutajal ja ainult kohalikult. See direktiiv vĂ”imaldab meil kĂ€ivitada kĂ€ske selle kasutaja nimel (kui meil loomulikult on juurdepÀÀs).
Samuti vÔib-olla peate pg_hba.conf-faili lisama rea, et avada juurdepÀÀs uuele kasutajale andmebaasile. Selle saab teha samuti nagu me muutsime nginx konfi.

Ja muidugi tuleb lisada postgresql roll peamisele playbookile.

Ruby installimine lÀbi rbenv

Ansible'is pole rbenv-iga töötamiseks mooduleid ning see paigaldatakse git-repositooriumi kloonimisega. Seega muutub see ĂŒlesanne kĂ”ige ebatavalisemaks. Loome selle jaoks 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

Kasutame jÀlle become_user direktiivi, et töötada loodud kasutaja all. Kuna rbenv installitakse tema kodudirektori alla, mitte globaalset, ning kasutame ka git moodulit, et kloonida reposi, mÀÀrates repo ja dest.

SeejÀrel peame lisama rbenv init bashrc faili ja seal lisama rbenv PATHi. Selleks on meil lineinfile moodul:

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

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

SeejÀrel on vaja installida ruby_build:

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

Ja lÔpuks tuleb installida ruby. Seda tehakse rbenv kaudu, lihtsalt bash kÀsuga:

- name: Installi 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 kĂ€ivitada ja millega. Kuid me seisame silmitsi sellega, et ansible ei kĂ€ivita bashrc-s olevat koodi enne kĂ€skude kĂ€ivitamist. See tĂ€hendab, et rbenv tuleb mÀÀratleda otse selles skriptis.

JÀrgmine probleem on see, et shell kÀsk ei ole ansible'i kontekstis staatiline. Seega ei toimu automaatset kontrolli, kas see ruby versioon on installitud vÔi mitte - me peame selle ise kontrollima:

- name: Installi 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

Ja jÀÀb ĂŒle installida bundler:

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

Ja jÀlle lisada meie ruby_rbenv roll pÔhipleykki.

Jagatud failid.

KokkuvĂ”tteks vĂ”iks seadistuse lĂ”petada. Edasi tuleb kĂ€ivitada capistrano ja see kopeerib koodi automaatselt, loob vajalikud katalooge ja kĂ€ivitab rakenduse (kui on kĂ”ik Ă”igesti seadistatud). Kuid tihti on capistrano jaoks vajalikud lisakonfiguratsioonifailid, nagu database.yml vĂ”i .env Neid saab kopeerida tĂ€pselt nagu nginxi failid ja mallid. On ainult ĂŒks nĂŒanss. Enne failide kopeerimist tuleb luua nende jaoks kataloogistruktuur, midagi sellist:

# 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 katalooge ja ansible loob automaatselt ĂŒlemised, kui need on vajalikud.

Ansible Vault

Oleme juba kokku puutunud olukordadega, kus muutujates vÔivad olla salajased andmed, nÀiteks kasutaja parool. Kui olete loonud .env rakenduse jaoks faili ja database.yml siis peaks seal olema veel rohkem selliseid kriitilisi andmeid. Need oleks hea peita vÔÔraste silmade eest. Selleks kasutatakse ansible vault.

Loome faili muutujate jaoks /ansible/vars/all.yml (siia on vÔimalik luua erinevaid faile erinevate hostigruppide jaoks, sama nagu inventari failis: production.yml, staging.yml jne).
Sellesse faili tuleks ĂŒle kanda kĂ”ik muutujad, mis peavad olema krĂŒpteeritud, kasutades standardset yml sĂŒntaksit:

# 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 faili krĂŒpteerida kĂ€suga:

ansible-vault encrypt .\/vars\/all.yml

Loomulikult peab krĂŒpteerimise kĂ€igus mÀÀrama deĆĄifreerimise parooli. Saate vaadata, mis jÀÀb faili sisse pĂ€rast selle kĂ€su tĂ€itmist.

KĂ€esoleva kaudu ansible-vault decrypt faili saab deĆĄifreerida, muuta ja seejĂ€rel uuesti krĂŒpteerida.

Töötamiseks ei ole faili deĆĄifreerimist vaja. Te hoiatega seda krĂŒpteeritud kujul ja kĂ€ivitate playbook'i koos argumendiga --ask-vault-pass. Ansible kĂŒsib parooli, toob vĂ€lja muutujad ja tĂ€idab ĂŒlesanded. KĂ”ik andmed jÀÀvad krĂŒpteerituks.

TÀielik kÀsk mitme hostigrupi ja ansible vault'i jaoks nÀeb vÀlja umbes nii:

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

Ja ma ei anna teile tĂ€ielikku teksti playbook'idest ja rollidest, kirjutage ise. Sest ansible on selline asi — kui te ei saa aru, mida teha, siis ta ei tee ka seda.

Allikas: habr.com

Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster