ProHoster > Blogi > Haldamine > Serveri seadistamine Rails rakenduse juurutamiseks Ansible'i abiga

Serveri seadistamine Rails rakenduse juurutamiseks Ansible'i abiga

MĂ”ni aeg tagasi pidin kirjutama mitu ansible playbooki, et valmistada serverit ette Railsi rakenduse juurutamiseks. Olin ĂŒllatunud, et ei leidnud lihtsat samm-sammult juhendit. Ei soovinud ma lihtsalt kellegi teise playbooki kopeerida, ilma et oleksin aru saanud, mis toimub, ja lĂ”puks pidin lugema dokumentatsiooni, et kĂ”ik ise kokku koguda. VĂ”ib-olla saan ma kellegile selle protsessi kiiremaks muuta selle artikli abil.

Esiteks tuleb mĂ”ista, et ansible pakub mugavat liidest juba ette mÀÀratud toimingute loendi tĂ€itmiseks kaugserveril (serveritel) SSH kaudu. Siin ei ole mingit maagia, ei saa pluginat installida ja sealt saadud rakendust juurutada nullist seisaku aegadega koos dokkeri, jĂ€lgimise ja muude mugavustega. Playbooki kirjutamiseks peate teadma, mida tĂ€pselt soovite teha ja kuidas seda teha. SeetĂ”ttu mind ei rahuldaks tulnud playbookid GitHubist vĂ”i artiklid, kus öeldakse: “Kopeerige ja kĂ€ivitage, – see töötab.”

Mida meil on vaja?

Nagu ma juba ĂŒtlesin, tuleb playbooki kirjutamiseks teada, mida soovite teha ja kuidas seda teha. MÀÀratleme, mida me vajame. Railsi rakenduse jaoks vajame mitmeid sĂŒsteemipakette: nginx, postgresql (redis, jmt). Lisaks on meil vaja konkreetse versiooni ruby'd. Soovitatav on seda installida rbenv kaudu (rvm, asdf
). KĂ”ike seda root-kasutaja alt kĂ€ivitamine on alati halb mĂ”te, seetĂ”ttu tuleb luua eraldi kasutaja ning seadistada tema Ă”igused. PĂ€rast seda peame ĂŒles laadima meie koodi serverisse, kopeerima nginx, postgres, jmt konfiguratsioonifailid ja kĂ€ivitama kĂ”ik need teenused.

LÔpuks on tegevuste jÀrjekord jÀrgmine:

  1. Logime sisse root'ina
  2. installime sĂŒsteemipaketid
  3. loome uue kasutaja, seadistame Ôigused, ssh vÔtme
  4. seadistame sĂŒsteemipaketid (nginx jmt) ja kĂ€ivitame need
  5. loome kasutaja andmebaasis (vÔime kohe ka andmebaasi luua)
  6. Logime sisse uue kasutajana
  7. Installime rbenv ja ruby
  8. Installime bundleri
  9. Üles laadime rakenduse koodi
  10. KĂ€ivitame Puma serveri

Viimaseid etappe saab teha ka capistrano abil, vĂ€hemalt oskab see vaikimisi kopeerida koodi release kataloogidesse, vahetada release sĂŒmboolset linki pĂ€rast edukat juurutamist, kopeerida konfiguratsioonid jagatud kataloogist, taaskĂ€ivitada puma ja nii edasi. KĂ”ike seda saab teha ka Ansible'i abil, aga miks?

Failistruktuur

Ansible'il on range failistruktuur oma failide jaoks, seetĂ”ttu on kĂ”ige parem hoida kĂ”ik eraldi kataloogis. Samuti ei ole oluline, kas see on Railsi rakenduses vĂ”i eraldi. Failide hoidmine eraldi git-reposiitiumis on samuti okei. Isiklikult leidsin, et on kĂ”ige mugavam luua ansible kataloog /config kataloogis Railsi rakenduses ja hoida kĂ”ik ĂŒhes repos.

Lihtne Playbook

Playbook on yml-fail, kus spetsiaalse sĂŒntaksiga on kirja pandud, mida ja kuidas ansible peab tegema. Loome esimese playbook'i, mis ei tee midagi:

---
- name: Lihtne playbook
  hosts: kÔik

Siin me lihtsalt ĂŒtleme, et meie playbooki nimi on Lihtne Playbook ja et selle sisu tuleb tĂ€ita kĂ”igil hostidel. VĂ”ime selle salvestada /ansible katalooge nimega playbook.yml ja proovida kĂ€ivitada:

ansible-playbook ./playbook.yml

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

Ansible ĂŒtleb, et ei tea hostidest, mis vastaksid nimekirjale kĂ”ik. Need tuleb loetleda spetsiaalses inventaarifailis..

Loome selle sama ansible katalooge:

123.123.123.123

Nii lihtsalt mÀÀrame hosti (ideaalis oma VPS host testimiseks vÔi vÔime ka localhosti kirjutada) ja salvestame selle nimega inventory.
VÔime proovida ansible't kÀivitada inventaarifailiga:

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

TEGEVUS [Faktide kogumine] **********************************************************************************************************************************

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

Kui teil on SSH-ĂŒhendus antud hostiga, siis ansible ĂŒhendub ja kogub teavet kaugmasina kohta. (vaikimisi TEGEVUS [Faktide kogumine]) pĂ€rast mida annab see lĂŒhikese aruande tĂ€itmisest (PLAY RECAP).

Vaikimisi kasutatakse ĂŒhenduseks kasutajanime, millega olete sĂŒsteemi sisse logitud. Hosti peal seda tĂ”enĂ€oliselt ei ole. Playbook'i failis saate mÀÀrata, millist kasutajat kasutada ĂŒhendamiseks, kasutades direktiivi remote_user. Samuti vĂ”ib teave kaugmasina kohta teile sageli olla ebavajalik ja ei ole mĂ”tet aega kulutada selle kogumisele. Selle ĂŒlesande saab samuti vĂ€lja lĂŒlitada:

---
- name: Lihtne playbook
  hosts: kÔik
  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, siis peate mÀÀrama ka direktiivi become: true, et saavutada kĂ”rgendatud Ă”igused. Nagu dokumentatsioonis on kirjutatud: become seatud 'true'/’yes’ privilege escalation'i aktiveerimiseks. kuigi pole tĂ€pselt selge, miks).

VÔimalik, et saate vea, kuna ansible ei suuda Python'i tÔlgendajat mÀÀrata, siis saab selle kÀsitsi mÀÀrata:

ansible_python_interpreter: /usr/bin/python3

kus te python'i asukohta kontrollite kÀsuga whereis python.

SĂŒsteemipakettide installimine

TavapĂ€rases Ansible'i paketis on mitmeid mooduleid erinevate sĂŒsteemipakettidega töötamiseks, nii et me ei pea igaks puhuks bash-skripte kirjutama. Praegu vajame ĂŒhte nendest moodulitest sĂŒsteemi vĂ€rskendamiseks ja sĂŒsteemipakettide installimiseks. Mul on VPS-l Ubuntu Linux, seega kasutan pakettide installimiseks apt-get ja moodulit.Kui teil on teine operatsioonisĂŒsteem, siis vĂ”ib olla vajalik teine moodul (pange tĂ€hele, et ma ĂŒtlesin alguses, et on hea ette teada, mida ja kuidas teeme). Kuid sĂŒntaks on tĂ”enĂ€oliselt sarnane.

TĂ€iendame meie playbook'i esmaste ĂŒ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

Task — see on ĂŒlesanne, mille ansible tĂ€idab eemalserverites. Anname ĂŒlesandele nime, et jĂ€lgida selle tĂ€itmist logis. Ja kirjeldame, kasutades konkreetse mooduli sĂŒntaksit, mida on vaja teha. Antud juhul apt: update_cache=yes — ĂŒtleb sĂŒsteemipakettide vĂ€rskendamiseks kasutada moodulit apt. Teine kĂ€sk on mĂ”nevĂ”rra keerulisem. Edastame moodulile apt pakettide loendi ja ĂŒtlevame, et nende state peab olema present, mis tĂ€hendab, et ĂŒtleme, et need pakettide installitakse. Sarnasel viisil saame öelda, et neid eemaldatakse vĂ”i uuendatakse, lihtsalt muutes state. Pange tĂ€hele, et Rails'i tööks PostgreSQL-i kasutamise korral on meil vajalik pakett postgresql-contrib, mille me hetkel installime. Seda tuleb samuti teada ja teostada, ansible ise seda ei tee.

Proovige playbook uuesti kÀivitada ja kontrollida, kas paketid installitakse.

Uute kasutajate loomine.

Kasutajatega töötamiseks on Ansible'il samuti moodul — user. Lisame veel ĂŒhe ĂŒlesande (ma peitsin juba teadaolevad ploki osad kommentaaridesse, et mitte iga kord kogu playbook'i 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 talle shell'i ja parooli. Siinkohal seisame silmitsi mitmete probleemidega. Mida teha, kui kasutajanimed peaksid olema erinevad erinevates hostides? Ja parooli hoidmine avatud kujul playbook'is on vĂ€ga halb idee. Alguses eemaldame kasutajanime ja parooli muutujateks ja hiljem artikli lĂ”pus nĂ€itan, kuidas parooli krĂŒpteerida.

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

kahekordsete sulgudes muutujaid mÀÀratakse playbook'ides.

Muutuja vÀÀrtused mÀÀrame inventuuri 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Ă”ikidele hostidele (all).

Samuti on huvitav konstruktsioon "{{ user_password | password_hash('sha512') }}". TÀhelepanu, et ansible ei lisa kasutajat lÀbi user_add nagu te teeksite seda kÀsitsi. Kogu teave salvestatakse otse, mistÔttu peame parooli eelnevalt hÀsima, mida see kÀsk teebki.

Lisame meie kasutaja sudo rĂŒhma. Enne seda peame veenduma, et selline grupp olemas on, kuna 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 piisavalt lihtne, meie seadmel on ka moodul rĂŒhmade loomiseks, mille sĂŒntaks on vĂ€ga sarnane apt-ile. PĂ€rast seda piisab, kui see grupp kasutajale mÀÀrata (groups: "sudo").
Samuti on kasulik lisada sellele kasutajale ssh vÔti, et saaksime 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

Antud juhul on huvitav konstruktsioon "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — ta kopeerib faili id_rsa.pub sisu (teie nimi vĂ”ib olla erinev), st ssh vĂ”tme avaliku osa ja laadib selle autoriseeritud vĂ”tmete loendisse serveri kasutaja jaoks.

Rollid

KĂ”ik kolm ĂŒlesannet, mis on seotud loomisega, saab hĂ”lpsasti liigitada ĂŒhe ĂŒlesande gruppi ning oleks hea seda gruppi hoida eraldi pĂ”hipleiibookist, et see ei paisuks liiga suureks. Selleks on ansibles olemas rollide.
Vastavalt alguses mainitud failistruktuurile tuleks rollid paigutada eraldi kausta roles, iga rolli jaoks eraldi kaust sama nimega, kaustas tasks, files, templates jne.
Loome failistruktuuri: ./ansible/roles/user/tasks/main.yml (main — see on pĂ”hifail, mis laetakse ja tĂ€idetakse rolli ĂŒhendamisel pleibookiga, selles saab lisada teisi rollifaili). NĂŒĂŒd saab selle faili alla laadida kĂ”ik kasutajatega seotud ĂŒlesanded:

# 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

PÔhipleibooks tuleks mÀrkida rolli kasutamine user:

---
- name: Lihtne pleibook
  hosts: kÔik
  remote_user: root
  gather_facts: ei

  tasks:
    - name: Uuenda sĂŒsteemi
      apt: update_cache=yes
    - name: Paigalda 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, selleks saab blokki nimetada ĂŒmber tasks kus need on mÀÀratud pre_tasks.

nginx seadistus

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

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

NĂŒĂŒd vajame faile ja vajadusi. Erinevus nende vahel on see, et ansible kopeerib failid otse, nagu need on. Aaga mallid peavad olema j2 laiendiga ja neil saab kasutada muutuja vÀÀrtusi, kasutades samu kahekordseid kurvihunnikuid.

Lisame nginx-i main.yml failis. Selle jaoks on meil olemas systemd 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 öelda, et nginx peab olema kĂ€ivitatud (st me kĂ€ivitame selle), vaid me ĂŒtleme ka, et see peab olema lubatud.
NĂŒĂŒd kopeerime konfigureerimisfailid:

# 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 nginx'i pĂ”hikonfiguratsioonifaili (saame selle otse serverist vĂ”i kirjutame ise). Samuti loome konfigureerimisfaili meie rakendusele kausta sites_available (see ei ole kohustuslik, kuid kasulik). Esimeses juhul kasutame copy moodulit failide kopeerimiseks (fail peab olema asukohta /ansible/roles/nginx/files/nginx.conf). Teises — kopeerime malliga, asendades muutuja vÀÀrtused. Mall peab olema asukohta /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 }};
  ....
}

Pöörake tĂ€helepanu sisestustele {{ 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 pleibooki erinevate hostigruppide jaoks. NĂ€iteks saame tĂ€iendada meie inventari 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 me nĂŒĂŒd oma pleibooki kĂ€ivitame, siis teostab see nimetatud ĂŒlesanded mĂ”lema hosti jaoks. Kuid samas staging hosti jaoks on muutujad erinevad produtsioonist ning mitte ainult rollides ja pleibooks, vaid ka nginx-i konfigureeringutes. {{ inventory_hostname }} ei ole vaja mĂ€rgistada inventari failis — see on spetsiaalne ansible muutujas, ja seal hoitakse hosti, mille jaoks pleibook hetkel kĂ€ib.
Kui soovite omada inventari faili mitme hosti jaoks, kuid kĂ€ivitada ainult ĂŒhe grupi jaoks, siis saate seda teha jĂ€rgmise kĂ€suga:

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

teine variant — omada eraldi inventari faile erinevate gruppide jaoks. VĂ”i saab kombineerida kahte lĂ€henemist, kui teil on palju erinevaid hoste.

Naaseme nginx-i seadistamise juurde. PĂ€rast konfigureerimisfailide kopeerimist peame looma sĂŒmboolse lingi sites_enabled kausta my_app.conf failist sites_available. Ja taaskĂ€ivitama nginx-i.

... # vana kood mail.yml

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

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

Siin on kĂ”ik lihtne — taas ansible moodulid, mille sĂŒntaks on piisavalt standardne. Kuid on ĂŒks punkt. Nginx'i iga kord taaskĂ€ivitamine pole mĂ”istlik. Olete tĂ€hele pannud, et me ei kirjuta kĂ€ske stiilis: "tee seda niimoodi", sĂŒntaks nĂ€eb pigem vĂ€lja nagu "sellel peab olema selline olek". Ja tĂ”epoolest, just selliselt ansible töötleb. Kui grupp juba eksisteerib vĂ”i sĂŒsteemipakett on juba paigaldatud, kontrollib ansible seda ja jĂ€tab ĂŒlesande vahele. Samuti ei kopeerita faile, kui need on tĂ€iesti samad nagu need, mis juba serveris on. Saame seda Ă€ra kasutada ja taaskĂ€ivitada nginx'i ainult siis, kui konfiguratsioonifailid on muutunud. Selleks 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 registreeritakse muutuv restart_nginx. Ja ainult siis, kui see muutuv on registreeritud, toimib teenuse taaskĂ€ivitamine.

Ja muidugi, tuleb lisada nginx'i roll pÔhitegevusloendisse.

Postgresql'i seadistamine

Peame postgresql'i sisselĂŒlitama systemd abil, just nagu me seda tegime nginx'iga, samuti looma kasutaja, mida me kasutame andmebaasile juurdepÀÀsuks, ja looma ise 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 palju korda tehtud, samuti postgresql_db ja postgresql_user moodulite sĂŒntaks. Rohkem teavet vĂ”ib leida dokumentatsioonist. Siin on kĂ”ige huvitavam direktiiv become_user: postgres. Asi on selles, et vaikimisi on ligipÀÀs postgresql andmebaasi ainult postgres kasutajal ja ainult lokaalselt. See direktiiv vĂ”imaldab meil tĂ€ita kĂ€ske selle kasutaja nimel (kui meil on juurdepÀÀs).
Samuti vÔib olla, et teil tuleb pg_hba.conf faili kirjutada, et avada uuele kasutajale ligipÀÀs andmebaasi. Seda saab teha samuti, nagu me muutsime nginx'i konfi.

Ja muidugi, tuleb lisada postgresql'i roll pÔhitegevusloendisse.

Ruby installimine lÀbi rbenv

Ansible'il ei ole mooduleid rbenv'iga töötamiseks, ning see paigaldatakse git reposteeri kloonimise teel. SeetĂ”ttu on see ĂŒlesanne kĂ”ige vĂ€hem standardne. 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 direktiivi become_user, et töötada loodud kasutaja alt. Kuna rbenv paigaldatakse tema kodu katalooge, mitte globaalsetena. Ja kasutame samuti git moodulit, et kloonida reposteeri, mÀÀrates repo ja dest.

Edasi peame lisama rbenv init bashrc-sse ja sinna lisama rbenv PATH-i. Selleks on meil moodul 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 -)"'

Peale seda tuleb installida 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 tuleb installida ruby. See toimub lÀbi rbenv, st lihtsalt bash kÀsu abil:

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

KĂŒtame, millist kĂ€sku tĂ€ita ja millega. Kuid kokku puutume sellega, et ansible ei kĂ€ivita bashrc-s sisalduvat koodi enne kĂ€skude kĂ€ivitamist. Seega tuleb rbenv mÀÀrata otse selles skriptis.

JÀrgmine probleem on seotud sellega, et shell kÀsk ei oma seisundit ansible'i vaatevinklist. Seega ei toimu automaatset kontrolli, kas see ruby versioon on paigaldatud vÔi mitte - seda peab me ise tegema:

- 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

Ja tuleb installida bundler:

- name: Install 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Ôhitegevusloendisse.

Jagatud failid.

Üldiselt oleks selle seadistuse vĂ”inud lĂ”petada. JĂ€rgmiseks tuleb kĂ€ivitada capistrano ja see kopeerib koodi ise, loob vajalikud kataloogid ja kĂ€ivitab rakenduse (kui kĂ”ik on Ă”igesti seadistatud). Kuid sageli on capistrano jaoks vaja lisakonstruktsioone, nagu database.yml vĂ”i .env Saame neid kopeerida tĂ€pselt nagu faile ja malle nginx'i jaoks. On ainult ĂŒks nĂŒanss. Enne failide kopeerimist on vajalik luua neile kataloogide struktuur, 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 sellega, et muutujaid vÔivad sisaldada salajased andmed nagu kasutaja parool. Kui olete loonud .env rakenduse faili, ja database.yml seal kindlasti peaks olema rohkem selliseid kriitilisi andmeid. Need oleks hea varjata vÀliste silmade eest. Selle jaoks kasutatakse ansible vault.

Loome faili muutujate jaoks /ansible/vars/all.yml (siin saab luua erinevaid faile erinevate hostigruppide jaoks, just nagu inventuurifailis: production.yml, staging.yml jne).
Sellesse faili tuleb 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

Muidugi, krĂŒpteerimise ajal tuleb seadistada ka dekrĂŒpteerimise parool. Saate nĂ€ha, mis failis toimub pĂ€rast selle kĂ€su kĂ€ivitamist.

Kasutades ansible-vault decrypt faili saab dekrĂŒpteerida, muuta ja siis uuesti krĂŒpteerida.

Töötamiseks ei ole faili dekrĂŒpteerimine vajalik. Hoidke seda krĂŒpteeritud kujul ja kĂ€ivitage playbook argumendiga --ask-vault-pass. Ansible kĂŒsib parooli, toob muutujad ja tĂ€idab ĂŒlesanded. KĂ”ik andmed jÀÀvad krĂŒpteerituks.

Kogu kÀsk mitme hostigruppide 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 kogu playbookide ja rollide teksti, kirjutage ise. Sest ansible on selline asi — kui te ei mĂ”ista, mida teha, siis ka tema ei tee seda.

Allikas: habr.com

Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster