🥇 In server ynstelle foar it ynsetten fan in Rails-applikaasje mei Ansible

Net lang lyn moast ik ferskate Ansible-spielboeken skriuwe om de tsjinner ta te rieden op it ynsetten fan in Rails-applikaasje. En, ferrassend, ik fûn gjin ienfâldige stap-foar-stap hantlieding. Ik woe net in oar syn playbook kopiearje sûnder te begripen wat der bart, en op it lêst moast ik de dokumintaasje lêze, alles sels sammelje. Miskien kin ik immen helpe om dit proses te fersnellen mei help fan dit artikel.

It earste ding om te begripen is dat ansible jo in handige ynterface leveret om in foarôf definieare list mei aksjes út te fieren op in tsjinner op ôfstân fia SSH. D'r is hjir gjin magy, jo kinne gjin plugin ynstallearje en in nul-downtime-ynset fan jo applikaasje krije mei docker, tafersjoch en oare guod út 'e doaze. Om in toanielstik te skriuwen, moatte jo witte wat jo krekt wolle dwaan en hoe't jo it dwaan. Dêrom bin ik net tefreden mei ready-made playbooks fan GitHub, of artikels lykas: "Kopiearje en útfiere, it sil wurkje."

Wat wy nedich?

Lykas ik al sei, om in playbook te skriuwen moatte jo witte wat jo wolle dwaan en hoe't jo it dwaan. Litte wy beslute wat wy nedich binne. Foar in Rails-applikaasje sille wy ferskate systeempakketten nedich hawwe: nginx, postgresql (redis, ensfh.). Dêrneist hawwe wy in spesifike ferzje fan ruby nedich. It is it bêste om it te ynstallearjen fia rbenv (rvm, asdf ...). Dit alles útfiere as in root-brûker is altyd in min idee, dus jo moatte in aparte brûker meitsje en syn rjochten ynstelle. Hjirnei moatte jo ús koade uploade nei de server, kopiearje de konfiguraasjes foar nginx, postgres, ensfh en begjinne al dizze tsjinsten.

As gefolch, de folchoarder fan aksjes is as folget:

Oanmelde as root
ynstallearje systeem pakketten
meitsje in nije brûker, konfigurearje rjochten, ssh kaai
konfigurearje systeempakketten (nginx ensfh) en útfiere se
Wy meitsje in brûker yn 'e databank (jo kinne fuortendaliks in databank oanmeitsje)
Oanmelde as in nije brûker
Ynstallearje rbenv en ruby
Ynstallaasje fan de bundler
It opladen fan de applikaasje koade
It starten fan de Puma-tsjinner

Boppedat kinne de lêste stadia dien wurde mei capistrano, teminsten út 'e doaze kin it koade kopiearje yn release-mappen, de release wikselje mei in symlink by suksesfolle ynset, konfiguraasjes kopiearje fan in dielde map, puma opnij starte, ensfh. Dit alles kin dien wurde mei Ansible, mar wêrom?

Triemstruktuer

Ansible hat strang triem struktuer foar al jo bestannen, dus it is it bêste om it allegear yn in aparte map te hâlden. Boppedat is it net sa wichtich oft it sil wêze yn de rails applikaasje sels, of apart. Jo kinne bestannen opslaan yn in apart git-repository. Persoanlik fûn ik it meast handich om in ansible map te meitsjen yn 'e map / config fan' e railsapplikaasje en alles yn ien repository op te slaan.

Ienfâldich Playbook

Playbook is in yml-bestân dat, mei help fan spesjale syntaksis, beskriuwt wat Ansible moat dwaan en hoe. Litte wy it earste playbook meitsje dat neat docht:

---
- name: Simple playbook
  hosts: all

Hjir sizze wy gewoan dat ús playbook hjit Simple Playbook en dat de ynhâld derfan moat wurde útfierd foar alle hosts. Wy kinne it bewarje yn /ansible map mei de namme playbook.yml en besykje te rinnen:

ansible-playbook ./playbook.yml

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

Ansible seit dat it gjin hosts ken dy't oerienkomme mei de hiele list. Se moatte wurde neamd yn in spesjale ynventarisaasje triem.

Litte wy it oanmeitsje yn deselde ansible map:

123.123.123.123

Dit is hoe't wy gewoan de host spesifisearje (ideaal de host fan ús VPS foar testen, of jo kinne localhost registrearje) en bewarje it ûnder de namme inventory.
Jo kinne besykje ansible út te fieren mei in ynventarisaasjebestân:

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

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

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

As jo ssh tagong hawwe ta de opjûne host, dan sil ansible ferbine en ynformaasje sammelje oer it systeem op ôfstân. (standert TASK [Gathing Facts]) wêrnei't it sil jaan in koart ferslach oer de útfiering (PLAY RECAP).

Standert brûkt de ferbining de brûkersnamme wêrunder jo ynlogd binne by it systeem. It sil nei alle gedachten net op de host wêze. Yn it playbook-bestân kinne jo opjaan hokker brûker jo brûke moatte om te ferbinen mei de remote_user-rjochtline. Ek kin ynformaasje oer in systeem op ôfstân faaks net nedich wêze foar jo en jo moatte gjin tiid fergrieme mei it sammeljen. Dizze taak kin ek útskeakele wurde:

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

Besykje it playbook nochris út te fieren en soargje derfoar dat de ferbining wurket. (As jo de root-brûker opjûn hawwe, dan moatte jo ek de wurde: true-rjochtline opjaan om ferhege rjochten te krijen. Lykas skreaun yn 'e dokumintaasje: become set to ‘true’/’yes’ to activate privilege escalation. hoewol it net hielendal dúdlik is wêrom).

Miskien krije jo in flater feroarsake troch it feit dat ansible de Python-tolk net kin bepale, dan kinne jo it manuell opjaan:

ansible_python_interpreter: /usr/bin/python3

Jo kinne útfine wêr't jo python hawwe mei it kommando whereis python.

Ynstallaasje fan systeempakketten

De standertdistribúsje fan Ansible omfettet in protte modules foar it wurkjen mei ferskate systeempakketten, dus wy hoege om ien of oare reden gjin bash-skripts te skriuwen. No hawwe wy ien fan dizze modules nedich om it systeem te aktualisearjen en systeempakketten te ynstallearjen. Ik haw Ubuntu Linux op myn VPS, dus om pakketten te ynstallearjen dy't ik brûke apt-get и module foar it. As jo in oar bestjoeringssysteem brûke, dan kinne jo in oare module nedich hawwe (ûnthâld dat ik oan it begjin sei dat wy fan tefoaren moatte witte wat en hoe't wy sille dwaan). De syntaksis sil lykwols nei alle gedachten fergelykber wêze.

Litte wy ús playbook oanfolje mei de earste taken:

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

Taak is krekt de taak dy't Ansible sil útfiere op servers op ôfstân. Wy jouwe de taak in namme sadat wy de útfiering dêrfan kinne folgje yn it log. En wy beskriuwe, mei de syntaksis fan in spesifike module, wat it moat dwaan. Yn dit gefal apt: update_cache=yes - seit om systeempakketten te aktualisearjen mei de apt-module. It twadde kommando is in bytsje komplisearre. Wy jouwe in list mei pakketten troch oan de apt-module en sizze dat se binne state wurde moat present, dat is, wy sizze dizze pakketten ynstallearje. Op in fergelykbere manier kinne wy har fertelle se te wiskjen, of se bywurkje troch gewoan te feroarjen state. Tink derom dat foar rails om te wurkjen mei postgresql wy it postgresql-contrib-pakket nedich hawwe, dat wy no ynstallearje. Nochris, jo moatte dit witte en dwaan; ansible op himsels sil dit net dwaan.

Besykje it playbook opnij út te fieren en kontrolearje dat de pakketten ynstalleare binne.

It meitsjen fan nije brûkers.

Om mei brûkers te wurkjen hat Ansible ek in module - brûker. Litte wy noch ien taak tafoegje (ik ferburgen de al bekende dielen fan it playbook efter de opmerkingen om it net elke kear folslein te kopiearjen):

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

Wy meitsje in nije brûker, set in schell en wachtwurd foar it. En dan komme wy tsjin ferskate problemen. Wat as brûkersnammen oars moatte wêze foar ferskate hosts? En it opslaan fan it wachtwurd yn dúdlike tekst yn it playbook is in heul min idee. Om te begjinnen, litte wy de brûkersnamme en wachtwurd yn fariabelen sette, en oan 'e ein fan it artikel sil ik sjen litte hoe't jo it wachtwurd kinne fersiferje.

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

Fariabelen wurde ynsteld yn playbooks mei help fan dûbele curly beugels.

Wy sille de wearden fan 'e fariabelen oanjaan yn it ynventarisaasjebestân:

123.123.123.123

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

Let op de rjochtline [all:vars] - it seit dat it folgjende tekstblok fariabelen (vars) is en se binne fan tapassing op alle hosts (allegear).

It ûntwerp is ek nijsgjirrich "{{ user_password | password_hash('sha512') }}". It ding is dat ansible de brûker net fia user_add lykas jo soene dwaan it mei de hân. En it bewarret alle gegevens direkt, dêrom moatte wy it wachtwurd ek yn 't foarút konvertearje yn in hash, wat dit kommando docht.

Litte wy ús brûker tafoegje oan 'e sudo-groep. Foardat wy lykwols moatte soargje dat sa'n groep bestiet, om't gjinien dit foar ús sil dwaan:

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

Alles is frij simpel, wy hawwe ek in groep module foar it meitsjen fan groepen, mei in syntaksis hiel ferlykber mei apt. Dan is it genôch om dizze groep te registrearjen by de brûker (groups: "sudo").
It is ek nuttich om in ssh-kaai oan dizze brûker ta te foegjen, sadat wy kinne oanmelde mei it sûnder wachtwurd:

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

Yn dit gefal is it ûntwerp ynteressant "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - it kopiearret de ynhâld fan it id_rsa.pub-bestân (jo namme kin oars wêze), dat is it iepenbiere diel fan 'e ssh-kaai en uploadt it nei de list mei autorisearre kaaien foar de brûker op 'e tsjinner.

Rollen

Alle trije taken foar it meitsjen fan gebrûk kin maklik wurde yndield yn ien taak groep, en it soe in goed idee in opslaan dizze groep apart út de wichtichste playbook, sadat it net groeie te grut. Foar dit doel hat Ansible rollen.
Neffens de oan it begjin oanjûne bestânsstruktuer moatte rollen wurde pleatst yn in aparte rolmap, foar elke rol is d'r in aparte map mei deselde namme, binnen de map taken, triemmen, sjabloanen, ensfh.
Litte wy in triemstruktuer oanmeitsje: ./ansible/roles/user/tasks/main.yml (haad is de haadbestân dy't laden en útfierd wurdt as in rol ferbûn is mei it playbook; oare rolbestannen kinne dêrmei ferbûn wurde). No kinne jo alle taken yn ferbân mei de brûker oerdrage nei dit bestân:

# 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

Yn it haadspielboek moatte jo oanjaan om de brûkersrol te brûken:

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

Ek kin it sin wêze om it systeem te aktualisearjen foar alle oare taken; om dit te dwaan kinne jo it blok omneame tasks dêr't se binne definiearre yn pre_tasks.

It ynstellen fan nginx

Wy moatte Nginx al ynstalleare hawwe; wy moatte it konfigurearje en útfiere. Litte wy it direkt yn 'e rol dwaan. Litte wy in triemstruktuer oanmeitsje:

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

No hawwe wy bestannen en sjabloanen nedich. It ferskil tusken har is dat ansible de bestannen direkt kopiearret, lykas is. En sjabloanen moatte de j2-útwreiding hawwe en se kinne fariabele wearden brûke mei deselde dûbele krullende beugels.

Litte wy nginx ynskeakelje main.yml map. Hjirfoar hawwe wy in systemd module:

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

Hjir sizze wy net allinich dat nginx moat wurde begon (dat is, wy lansearje it), mar wy sizze fuortendaliks dat it moat wurde ynskeakele.
Litte wy no de konfiguraasjebestannen kopiearje:

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

Wy meitsje it haad nginx-konfiguraasjetriem (jo kinne it direkt fan 'e tsjinner nimme, of sels skriuwe). En ek it konfiguraasjetriem foar ús applikaasje yn 'e map sites_available (dit is net nedich, mar nuttich). Yn it earste gefal brûke wy de kopymodule om bestannen te kopiearjen (it bestân moat yn /ansible/roles/nginx/files/nginx.conf). Yn 'e twadde kopiearje wy it sjabloan, ferfange de wearden fan' e fariabelen. It sjabloan moat yn wêze /ansible/roles/nginx/templates/my_app.j2). En it kin der sa útsjen:

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

Jou omtinken oan de ynserts {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} - dit binne alle fariabelen waans wearden Ansible sil ferfange yn it sjabloan foardat jo kopiearje. Dit is handich as jo in playbook brûke foar ferskate groepen hosts. Wy kinne bygelyks ús ynventarisaasjebestân tafoegje:

[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

As wy no ús playbook starte, sil it de opjûne taken foar beide hosts útfiere. Mar tagelyk, foar in staging host, de fariabelen sille wêze oars as de produksje ones, en net allinnich yn rollen en playbooks, mar ek yn nginx configs. {{ inventory_hostname }} net hoege te wurde oantsjutte yn de ynventarisaasje triem - dit spesjale ansible fariabele en de host wêrfoar it playbook op it stuit rint wurdt dêr opslein.
As jo in ynventarisaasjebestân hawwe wolle foar ferskate hosts, mar allinich foar ien groep útfiere, kin dit dien wurde mei it folgjende kommando:

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

In oare opsje is om aparte ynventarisaasjebestannen te hawwen foar ferskate groepen. Of jo kinne de twa oanpakken kombinearje as jo in protte ferskillende hosts hawwe.

Litte wy weromgean nei it ynstellen fan nginx. Nei it kopiearjen fan de konfiguraasjebestannen, moatte wy in symlink meitsje yn sitest_enabled nei my_app.conf fan sites_available. En opnij starte 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

Alles is hjir ienfâldich - wer oanwêzige modules mei in frij standert syntaksis. Mar der is ien punt. D'r is gjin punt om nginx elke kear opnij te begjinnen. Hawwe jo opfallen dat wy gjin kommando's skriuwe lykas: "do dit sa", de syntaksis liket mear op "dit moat dizze steat hawwe". En meastentiids is dit krekt hoe't ansible wurket. As de groep al bestiet, of it systeempakket is al ynstalleare, dan sil ansible dit kontrolearje en de taak oerslaan. Ek wurde bestannen net kopiearre as se folslein oerienkomme mei wat al op de tsjinner stiet. Wy kinne profitearje fan dit en opnij starte nginx allinich as de konfiguraasjetriemmen binne feroare. D'r is in registerrjochtline foar dit:

# 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

As ien fan de konfiguraasje triemmen feroaret, sil in kopy makke wurde en de fariabele wurdt registrearre restart_nginx. En allinich as dizze fariabele registrearre is, sil de tsjinst opnij starte.

En fansels moatte jo de nginx-rol tafoegje oan it haadspielboek.

Postgresql

Wy moatte postgresql ynskeakelje mei systemd op deselde manier as wy diene mei nginx, en ek in brûker meitsje dy't wy sille brûke om tagong te krijen ta de databank en de databank sels.
Litte wy in rol meitsje /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 }}"

Ik sil net beskriuwe hoe't jo fariabelen tafoegje oan ynventarisaasje, dit is al in protte kearen dien, lykas de syntaksis fan 'e postgresql_db en postgresql_user modules. Mear ynformaasje is te finen yn 'e dokumintaasje. De meast nijsgjirrige rjochtline hjir is become_user: postgres. It feit is dat standert allinich de postgres-brûker tagong hat ta de postgresql-database en allinich lokaal. Dizze rjochtline lit ús kommando's útfiere út namme fan dizze brûker (as wy tagong hawwe, fansels).
Ek moatte jo miskien in rigel tafoegje oan pg_hba.conf om in nije brûker tagong te krijen ta de databank. Dit kin dien wurde op deselde manier as wy de nginx-konfiguraasje hawwe feroare.

En fansels moatte jo de postgresql-rol tafoegje oan it haadspielboek.

Ynstallaasje fan ruby fia rbenv

Ansible hat gjin modules foar in wurk mei rbenv, mar it wurdt ynstallearre troch cloning in git repository. Dêrom wurdt dit probleem de meast net-standert. Litte wy in rol foar har meitsje /ansible/roles/ruby_rbenv/main.yml en lit ús begjinne mei it ynfoljen:

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

Wy brûke opnij de word_user-rjochtline om te wurkjen ûnder de brûker dy't wy foar dizze doelen makke hawwe. Sûnt rbenv is ynstallearre yn syn thús triemtafel, en net globaal. En wy brûke ek de git-module om it repository te klonjen, repo en dest oantsjutte.

Folgjende moatte wy rbenv init registrearje yn bashrc en rbenv tafoegje oan PATH dêr. Hjirfoar hawwe wy de lineinfile module:

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

Dan moatte jo ruby_build ynstallearje:

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

En úteinlik ynstallearje ruby. Dit wurdt dien fia rbenv, dat is gewoan mei it bash kommando:

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

Wy sizze hokker kommando út te fieren en mei wat. Hjir komme wy lykwols oer it feit dat ansible de koade yn bashrc net útfiert foardat de kommando's útfiert. Dit betsjut dat rbenv direkt yn itselde skript definiearre wurde moat.

It folgjende probleem is te tankjen oan it feit dat it shell kommando hat gjin steat fan in ansible eachpunt. Dat is, d'r sil gjin automatyske kontrôle wêze as dizze ferzje fan ruby is ynstalleare of net. Wy kinne dit sels dwaan:

- 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

Alles wat oerbliuwt is om bundler te ynstallearjen:

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

En wer, foegje ús rol ruby_rbenv ta oan it haadspielboek.

Dielde triemmen.

Yn 't algemien koe de opset hjir foltôge wurde. Folgjende, alles wat bliuwt is om capistrano út te fieren en it sil de koade sels kopiearje, de nedige mappen oanmeitsje en de applikaasje starte (as alles goed is konfigureare). Capistrano fereasket lykwols faak ekstra konfiguraasjebestannen, lykas database.yml of .env Se kinne wurde kopiearre krekt as bestannen en sjabloanen foar nginx. Der is mar ien subtiliteit. Foardat jo bestannen kopiearje, moatte jo in mapstruktuer foar har oanmeitsje, soksawat as dit:

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

wy spesifisearje mar ien map en ansible sil automatysk meitsje âlder ones as it nedich is.

Ansible Vault

Wy hawwe it feit al tsjinkaam dat fariabelen geheime gegevens kinne befetsje lykas it wachtwurd fan de brûker. As jo hawwe makke .env triem foar de applikaasje, en database.yml dan moatte der noch mear sokke krityske gegevens komme. It soe goed wêze om se te ferbergjen foar nijsgjirrige eagen. Foar dit doel wurdt it brûkt ansible ferwulft.

Litte wy in bestân meitsje foar fariabelen /ansible/vars/all.yml (hjir kinne jo ferskate triemmen oanmeitsje foar ferskate groepen hosts, krekt as yn 'e ynventarisaasjebestân: production.yml, staging.yml, ensfh).
Alle fariabelen dy't fersifere moatte moatte wurde oerbrocht nei dit bestân mei de standert yml-syntaksis:

# 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

Hjirnei kin dit bestân fersifere wurde mei it kommando:

ansible-vault encrypt ./vars/all.yml

Fansels, as jo fersiferje, moatte jo in wachtwurd ynstelle foar dekodearring. Jo kinne sjen wat der yn it bestân sil wêze nei it oproppen fan dit kommando.

Mei help fan ansible-vault decrypt it bestân kin wurde ûntsifere, wizige en dan wer fersifere.

Jo hoege it bestân net te ûntsiferjen om te wurkjen. Jo bewarje it fersifere en útfiere it playbook mei it argumint --ask-vault-pass. Ansible sil om it wachtwurd freegje, de fariabelen ophelje en de taken útfiere. Alle gegevens sille fersifere bliuwe.

It folsleine kommando foar ferskate groepen hosts en mooglike ferwulft sil der sa útsjen:

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

Mar ik sil jo de folsleine tekst fan toanielstikken en rollen net jaan, skriuw it sels. Want ansible is sa - as jo net begripe wat der dien wurde moat, dan docht it it net foar jo.

Boarne: www.habr.com

In server ynstelle om in Rails-applikaasje yn te setten mei Ansible

Wat wy nedich?

Triemstruktuer

Ienfâldich Playbook

Ynstallaasje fan systeempakketten

It meitsjen fan nije brûkers.

Rollen

It ynstellen fan nginx

Postgresql

Ynstallaasje fan ruby fia rbenv

Dielde triemmen.

Ansible Vault

Add a comment cancel reply

In server ynstelle om in Rails-applikaasje yn te setten mei Ansible

Wat wy nedich?

Triemstruktuer

Ienfâldich Playbook

Ynstallaasje fan systeempakketten

It meitsjen fan nije brûkers.

Rollen

It ynstellen fan nginx

Postgresql

Ynstallaasje fan ruby ​​fia rbenv

Dielde triemmen.

Ansible Vault

Add a comment cancel reply

Ynstallaasje fan ruby fia rbenv