ProHoster > Blog > Stjórnsýsla > Að setja upp netþjón til að dreifa Rails forriti með Ansible

Að setja upp netþjón til að dreifa Rails forriti með Ansible

Ekki er langt síðan ég þurfti að skrifa nokkrar Ansible leikbækur til að undirbúa þjóninn fyrir að dreifa Rails forriti. Og, furðu, fann ég ekki einfalda skref-fyrir-skref handbók. Ég vildi ekki afrita leikbók einhvers annars án þess að skilja hvað var að gerast, og á endanum varð ég að lesa skjölin og safna öllu sjálfur. Kannski get ég hjálpað einhverjum að flýta þessu ferli með hjálp þessarar greinar.

Það fyrsta sem þarf að skilja er að ansible veitir þér þægilegt viðmót til að framkvæma fyrirfram skilgreindan lista yfir aðgerðir á ytri netþjónum í gegnum SSH. Það er enginn galdur hér, þú getur ekki sett upp viðbætur og fengið núll niður í miðbæ af forritinu þínu með docker, eftirliti og öðru góðgæti úr kassanum. Til þess að skrifa leikbók verður þú að vita nákvæmlega hvað þú vilt gera og hvernig á að gera það. Þess vegna er ég ekki sáttur við tilbúnar leikrit frá GitHub, eða greinar eins og: „Afrita og keyra, það mun virka.“

Hvað þurfum við?

Eins og ég sagði þegar, til þess að skrifa leikbók þarftu að vita hvað þú vilt gera og hvernig á að gera það. Við skulum ákveða hvað við þurfum. Fyrir Rails forrit þurfum við nokkra kerfispakka: nginx, postgresql (redis, osfrv.). Að auki þurfum við sérstaka útgáfu af rúbíni. Best er að setja það upp í gegnum rbenv (rvm, asdf...). Að keyra þetta allt sem rótnotanda er alltaf slæm hugmynd, svo þú þarft að búa til sérstakan notanda og stilla réttindi hans. Eftir þetta þarftu að hlaða upp kóðanum okkar á netþjóninn, afrita stillingarnar fyrir nginx, postgres, osfrv og hefja allar þessar þjónustur.

Fyrir vikið er röð aðgerða sem hér segir:

  1. Skráðu þig inn sem rót
  2. setja upp kerfispakka
  3. búa til nýjan notanda, stilla réttindi, ssh lykill
  4. stilltu kerfispakka (nginx osfrv.) og keyrðu þá
  5. Við búum til notanda í gagnagrunninum (þú getur strax búið til gagnagrunn)
  6. Skráðu þig inn sem nýr notandi
  7. Settu upp rbenv og ruby
  8. Að setja upp búntara
  9. Hleður upp forritskóðanum
  10. Ræsir Puma netþjóninn

Þar að auki er hægt að gera síðustu stigin með því að nota capistrano, að minnsta kosti út fyrir kassann getur það afritað kóða í útgáfumöppur, skipt um útgáfu með tákntengli við árangursríka uppsetningu, afritað stillingar úr sameiginlegri möppu, endurræst puma osfrv. Allt þetta er hægt að gera með Ansible, en hvers vegna?

Uppbygging skráa

Ansible hefur strangt skrá uppbyggingu fyrir allar skrárnar þínar, svo það er best að hafa þær allar í sérstakri möppu. Þar að auki, það er ekki svo mikilvægt hvort það verður í teina forritinu sjálfu, eða sérstaklega. Þú getur geymt skrár í sérstakri git geymslu. Persónulega fannst mér þægilegast að búa til viðeigandi möppu í /config skránni í rails forritinu og geyma allt í einni geymslu.

Einföld leikbók

Playbook er yml skrá sem með sérstökum setningafræði lýsir því hvað Ansible ætti að gera og hvernig. Við skulum búa til fyrstu leikbókina sem gerir ekkert:

---
- name: Simple playbook
  hosts: all

Hér segjum við einfaldlega að leikbókin okkar heitir Simple Playbook og að innihald þess ætti að vera keyrt fyrir alla gestgjafa. Við getum vistað það í /ansible möppu með nafninu playbook.yml og reyndu að keyra:

ansible-playbook ./playbook.yml

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

Ansible segist ekki þekkja neina gestgjafa sem passa við allan listann. Þeir verða að vera skráðir í sérstakri birgðaskrá.

Við skulum búa það til í sömu möppu:

123.123.123.123

Svona tilgreinum við einfaldlega gestgjafann (helst gestgjafi VPS okkar til að prófa, eða þú getur skráð localhost) og vistum hann undir nafninu inventory.
Þú getur prófað að keyra ansible með birgðaskrá:

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

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

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

Ef þú hefur ssh aðgang að tilgreindum hýsil, þá mun ansible tengjast og safna upplýsingum um ytra kerfið. (sjálfgefið TASK [Gathering Facts]) eftir það mun það gefa stutta skýrslu um framkvæmdina (PLAY RECAP).

Sjálfgefið er að tengingin notar notandanafnið sem þú ert skráður undir í kerfinu. Það mun líklegast ekki vera á gestgjafanum. Í leikbókarskránni geturðu tilgreint hvaða notanda á að nota til að tengjast með því að nota remote_user tilskipunina. Einnig geta upplýsingar um fjarkerfi oft verið óþarfar fyrir þig og þú ættir ekki að eyða tíma í að safna þeim. Einnig er hægt að slökkva á þessu verkefni:

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

Reyndu að keyra leikbókina aftur og vertu viss um að tengingin virki. (Ef þú tilgreindir rótarnotandann, þá þarftu líka að tilgreina orðið: true tilskipunina til að öðlast aukin réttindi. Eins og skrifað er í skjölunum: become set to ‘true’/’yes’ to activate privilege escalation. þó ekki sé alveg ljóst hvers vegna).

Kannski færðu villu sem stafar af því að ansible getur ekki ákvarðað Python túlkinn, þá geturðu tilgreint það handvirkt:

ansible_python_interpreter: /usr/bin/python3

Þú getur fundið út hvar þú ert með python með skipuninni whereis python.

Að setja upp kerfispakka

Stöðluð dreifing Ansible inniheldur margar einingar til að vinna með ýmsa kerfispakka, svo við þurfum ekki að skrifa bash forskriftir af einhverjum ástæðum. Nú þurfum við eina af þessum einingum til að uppfæra kerfið og setja upp kerfispakka. Ég er með Ubuntu Linux á VPS, svo ég nota til að setja upp pakka apt-get и mát fyrir það. Ef þú ert að nota annað stýrikerfi, þá gætir þú þurft aðra einingu (mundu að ég sagði í upphafi að við þurfum að vita fyrirfram hvað og hvernig við munum gera). Hins vegar mun setningafræðin líklegast vera svipuð.

Við skulum bæta við leikbókinni okkar með fyrstu verkunum:

---
- 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

Verkefni er nákvæmlega það verkefni sem Ansible mun framkvæma á ytri netþjónum. Við gefum verkefninu nafn svo að við getum fylgst með framkvæmd þess í log. Og við lýsum, með því að nota setningafræði tiltekinnar einingar, hvað hún þarf að gera. Í þessu tilfelli apt: update_cache=yes - segir að uppfæra kerfispakka með því að nota apt eininguna. Önnur skipunin er aðeins flóknari. Við sendum lista yfir pakka til viðeigandi einingarinnar og segjum að þeir séu það state ætti að verða present, það er, við segjum að setja upp þessa pakka. Á svipaðan hátt getum við sagt þeim að eyða þeim eða uppfært með því einfaldlega að breyta state. Vinsamlegast athugaðu að til að teinar virki með postgresql þurfum við postgresql-contrib pakkann, sem við erum að setja upp núna. Aftur, þú þarft að vita og gera þetta; Ansible á eigin spýtur mun ekki gera þetta.

Reyndu að keyra leikbókina aftur og athugaðu hvort pakkarnir séu uppsettir.

Að búa til nýja notendur.

Til að vinna með notendum hefur Ansible einnig einingu - notandi. Við skulum bæta við einu verkefni í viðbót (ég faldi þegar þekkta hluta leikbókarinnar á bak við athugasemdirnar til að afrita það ekki alveg í hvert skipti): 

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

Við búum til nýjan notanda, setjum skel og lykilorð fyrir hann. Og svo lendum við í nokkrum vandamálum. Hvað ef notendanöfn þurfa að vera mismunandi fyrir mismunandi gestgjafa? Og að geyma lykilorðið í skýrum texta í leikbókinni er mjög slæm hugmynd. Til að byrja með skulum við setja notandanafnið og lykilorðið í breytur og í lok greinarinnar mun ég sýna hvernig á að dulkóða lykilorðið.

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

Breytur eru settar í leikbókum með því að nota tvöfaldar krullaðar axlabönd.

Við munum gefa til kynna gildi breytanna í birgðaskránni:

123.123.123.123

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

Vinsamlegast athugaðu tilskipunina [all:vars] - það segir að næsti textabálkur sé breytur (vars) og þær eiga við um alla véla (alla).

Hönnunin er líka áhugaverð "{{ user_password | password_hash('sha512') }}". Málið er að ansible setur ekki upp notandann í gegnum user_add eins og þú myndir gera það handvirkt. Og það vistar öll gögn beint, þess vegna verðum við líka að breyta lykilorðinu í hass fyrirfram, sem er það sem þessi skipun gerir.

Bætum notandanum okkar í sudo hópinn. En áður en þetta kemur þurfum við að ganga úr skugga um að slíkur hópur sé til vegna þess að enginn mun gera þetta fyrir okkur:

---
- 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"

Allt er frekar einfalt, við erum líka með hópeiningu til að búa til hópa, með setningafræði mjög svipuð apt. Þá er nóg að skrá þennan hóp á notandann (groups: "sudo").
Það er líka gagnlegt að bæta ssh lykli við þennan notanda svo að við getum skráð okkur inn með því án lykilorðs:

---
- 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

Í þessu tilfelli er hönnunin áhugaverð "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — það afritar innihald id_rsa.pub skráarinnar (nafnið þitt gæti verið annað), það er opinbera hluta ssh lykilsins og hleður því upp á listann yfir leyfilega lykla fyrir notandann á þjóninum.

Hlutverk

Öll þrjú verkefnin til að skapa notkun má auðveldlega flokka í einn verkefnahóp og gott væri að geyma þennan hóp aðskilinn frá aðalleikritinu svo hann verði ekki of stór. Í þessu skyni hefur Ansible hlutverkum.
Samkvæmt skráarskipulaginu sem tilgreint er strax í upphafi verður að setja hlutverk í sérstaka hlutverkaskrá, fyrir hvert hlutverk er sérstök mappa með sama nafni, inni í möppunni fyrir verkefni, skrár, sniðmát o.s.frv.
Við skulum búa til skráarskipulag: ./ansible/roles/user/tasks/main.yml (main er aðalskráin sem verður hlaðin og keyrð þegar hlutverk er tengt við leikbókina; hægt er að tengja aðrar hlutverkaskrár við hana). Nú geturðu flutt öll verkefni sem tengjast notandanum yfir á þessa skrá:

# 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

Í aðalleikritinu verður þú að tilgreina að nota notendahlutverkið:

---
- 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

Einnig getur verið skynsamlegt að uppfæra kerfið fyrir öll önnur verkefni; til að gera þetta geturðu endurnefna blokkina tasks þar sem þau eru skilgreind í pre_tasks.

Að setja upp nginx

Við ættum nú þegar að hafa Nginx uppsett; við þurfum að stilla það og keyra það. Gerum það strax í hlutverkinu. Við skulum búa til skráarskipulag:

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

Nú þurfum við skrár og sniðmát. Munurinn á þeim er sá að ansible afritar skrárnar beint, eins og þær eru. Og sniðmát verða að hafa j2 framlenginguna og þau geta notað breytileg gildi með sömu tvöföldu krulluðu axlaböndum.

Við skulum virkja nginx inn main.yml skrá. Fyrir þetta höfum við systemd einingu:

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

Hér segjum við ekki aðeins að nginx verði að vera ræst (þ.e. við ræsum það), heldur segjum við strax að það verði að vera virkt.
Nú skulum við afrita stillingarskrárnar:

# 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'

Við búum til helstu nginx stillingarskrána (þú getur tekið hana beint af þjóninum eða skrifað hana sjálfur). Og einnig stillingarskrá fyrir forritið okkar í möppunni sites_available (þetta er ekki nauðsynlegt en gagnlegt). Í fyrra tilvikinu notum við afritunareininguna til að afrita skrár (skráin verður að vera í /ansible/roles/nginx/files/nginx.conf). Í öðru lagi afritum við sniðmátið og setjum út gildi breytanna. Sniðmátið ætti að vera í /ansible/roles/nginx/templates/my_app.j2). Og það gæti litið svona út:

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

Gefðu gaum að innleggunum {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — þetta eru allar breyturnar þar sem gildi Ansible koma í staðinn fyrir sniðmátið áður en það er afritað. Þetta er gagnlegt ef þú notar leikbók fyrir mismunandi hópa gestgjafa. Til dæmis getum við bætt við birgðaskránni okkar:

[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

Ef við ræsum nú leikbókina okkar mun hún framkvæma tilgreind verkefni fyrir báða gestgjafana. En á sama tíma, fyrir sviðsstjóra, verða breyturnar aðrar en framleiðslurnar, og ekki aðeins í hlutverkum og leikbókum, heldur einnig í nginx stillingum. {{ inventory_hostname }} þarf ekki að tilgreina í birgðaskránni - þetta sérstök breytu og gestgjafinn sem leikbókin er í gangi fyrir er geymd þar.
Ef þú vilt hafa birgðaskrá fyrir nokkra gestgjafa, en aðeins keyra fyrir einn hóp, er hægt að gera það með eftirfarandi skipun:

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

Annar valkostur er að hafa aðskildar birgðaskrár fyrir mismunandi hópa. Eða þú getur sameinað þessar tvær aðferðir ef þú ert með marga mismunandi gestgjafa.

Við skulum fara aftur í að setja upp nginx. Eftir að hafa afritað stillingarskrárnar þurfum við að búa til tákntengil í sitest_enabled til my_app.conf frá sites_available. Og endurræstu 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

Allt er einfalt hér - aftur anible einingar með nokkuð staðlaða setningafræði. En það er eitt atriði. Það þýðir ekkert að endurræsa nginx í hvert skipti. Hefur þú tekið eftir því að við skrifum ekki skipanir eins og: „gerið þetta svona“, setningafræðin lítur meira út eins og „þetta ætti að hafa þetta ástand“. Og oftast er þetta nákvæmlega hvernig ansible virkar. Ef hópurinn er þegar til, eða kerfispakkinn er þegar uppsettur, þá mun ansible athuga þetta og sleppa verkefninu. Einnig verða skrár ekki afritaðar ef þær passa algjörlega við það sem þegar er á þjóninum. Við getum nýtt okkur þetta og endurræst nginx aðeins ef stillingarskránum hefur verið breytt. Það er tilskipun um skráningu um þetta:

# 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

Ef ein af stillingarskrám breytist verður afrit af því og breytan skráð restart_nginx. Og aðeins ef þessi breyta hefur verið skráð verður þjónustan endurræst.

Og auðvitað þarftu að bæta nginx hlutverkinu við aðalleikbókina.

Setja upp postgresql

Við þurfum að virkja postgresql með því að nota systemd á sama hátt og við gerðum með nginx, og einnig búa til notanda sem við munum nota til að fá aðgang að gagnagrunninum og gagnagrunninum sjálfum.
Búum til hlutverk /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 }}"

Ég mun ekki lýsa því hvernig á að bæta breytum við birgðahaldið, þetta hefur þegar verið gert margoft, sem og setningafræði postgresql_db og postgresql_user eininganna. Frekari upplýsingar er að finna í skjölunum. Áhugaverðasta tilskipunin hér er become_user: postgres. Staðreyndin er sú að sjálfgefið er að aðeins postgres notandinn hefur aðgang að postgresql gagnagrunninum og aðeins á staðnum. Þessi tilskipun gerir okkur kleift að framkvæma skipanir fyrir hönd þessa notanda (ef við höfum aðgang, auðvitað).
Einnig gætirðu þurft að bæta línu við pg_hba.conf til að leyfa nýjum notanda aðgang að gagnagrunninum. Þetta er hægt að gera á sama hátt og við breyttum nginx stillingunni.

Og auðvitað þarftu að bæta postgresql hlutverkinu við aðalleikbókina.

Að setja upp ruby ​​í gegnum rbenv

Ansible er ekki með einingar til að vinna með rbenv, en það er sett upp með því að klóna git repository. Þess vegna verður þetta vandamál hið óstöðluðusta. Búum til hlutverk fyrir hana /ansible/roles/ruby_rbenv/main.yml og við skulum byrja að fylla það út:

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

Við notum aftur orðið_notandi tilskipunina til að vinna undir notandanum sem við bjuggum til í þessum tilgangi. Þar sem rbenv er sett upp í heimaskránni sinni, en ekki á heimsvísu. Og við notum líka git eininguna til að klóna geymsluna, tilgreina endurhverfu og dest.

Næst þurfum við að skrá rbenv init í bashrc og bæta rbenv við PATH þar. Fyrir þetta höfum við lineinfile eininguna:

- 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 -)"'

Þá þarftu að setja upp ruby_build:

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

Og að lokum settu upp Ruby. Þetta er gert í gegnum rbenv, það er einfaldlega með bash skipuninni:

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

Við segjum hvaða skipun á að framkvæma og með hvaða. Hins vegar, hér rekumst við á þá staðreynd að ansible keyrir ekki kóðann sem er í bashrc áður en skipanirnar eru keyrðar. Þetta þýðir að rbenv verður að vera skilgreint beint í sama handriti.

Næsta vandamál er vegna þess að skel skipunin hefur ekkert ástand frá annible sjónarmiði. Það er, það verður engin sjálfvirk athugun hvort þessi útgáfa af ruby ​​er uppsett eða ekki. Við getum gert þetta sjálf:

- 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

Allt sem er eftir er að setja upp bundler:

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

Og aftur, bættu hlutverki okkar ruby_rbenv við aðalleikbókina.

Samnýttar skrár.

Almennt séð væri hægt að klára uppsetninguna hér. Næst er allt sem eftir er að keyra capistrano og það mun afrita kóðann sjálfan, búa til nauðsynlegar möppur og ræsa forritið (ef allt er rétt stillt). Hins vegar þarf capistrano oft viðbótar stillingarskrár, svo sem database.yml eða .env Hægt er að afrita þau alveg eins og skrár og sniðmát fyrir nginx. Það er aðeins ein næmni. Áður en þú afritar skrár þarftu að búa til möppuskipulag fyrir þær, eitthvað á þessa leið:

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

við tilgreinum aðeins eina möppu og ansible mun sjálfkrafa búa til foreldri ef þörf krefur.

Ansible Vault

Við höfum þegar rekist á þá staðreynd að breytur geta innihaldið leynileg gögn eins og lykilorð notandans. Ef þú hefur búið til .env skrá fyrir umsóknina, og database.yml þá hljóta að vera enn fleiri slík gagnrýnin gögn. Það væri gott að fela þá fyrir hnýsnum augum. Í þessu skyni er það notað ansible hvelfingu.

Við skulum búa til skrá fyrir breytur /ansible/vars/all.yml (hér geturðu búið til mismunandi skrár fyrir mismunandi hópa hýsingar, alveg eins og í birgðaskránni: production.yml, staging.yml, osfrv).
Allar breytur sem þarf að dulkóða verður að flytja í þessa skrá með því að nota staðlaða yml setningafræði:

# 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

Eftir það er hægt að dulkóða þessa skrá með skipuninni:

ansible-vault encrypt ./vars/all.yml

Við dulkóðun þarftu náttúrulega að setja lykilorð fyrir afkóðun. Þú getur séð hvað verður inni í skránni eftir að þú hefur hringt í þessa skipun.

Með ansible-vault decrypt skrána er hægt að afkóða, breyta og síðan dulkóða aftur.

Þú þarft ekki að afkóða skrána til að virka. Þú geymir það dulkóðað og keyrir leikbókina með rökunum --ask-vault-pass. Ansible mun biðja um lykilorðið, sækja breyturnar og framkvæma verkefnin. Öll gögn verða áfram dulkóðuð.

Heildarskipunin fyrir nokkra hópa gestgjafa og hugsanlega hvelfingu mun líta einhvern veginn svona út:

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

En ég mun ekki gefa þér allan texta leikbóka og hlutverka, skrifaðu það sjálfur. Vegna þess að ansible er svona - ef þú skilur ekki hvað þarf að gera, þá mun það ekki gera það fyrir þig.

Heimild: www.habr.com

Bæta við athugasemd