ProHoster > Blog > Adminisztráció > A Rails alkalmazás telepítésének beállítása Ansible segítségével

A Rails alkalmazás telepítésének beállítása Ansible segítségével

Nemrégiben szükségem volt néhány Ansible playbook írására a Rails alkalmazás telepítéséhez szükséges szerver előkészítéséhez. Meglepődve tapasztaltam, hogy nem találtam egyszerű lépésről lépésre útmutatót. Nem akartam egyszerűen átmásolni egy másik playbookját anélkül, hogy megértettem volna a folyamatot, ezért végül el kellett olvasnom a dokumentációt, hogy mindent saját magam összeállítsak. Talán tudok segíteni valakinek ezt a folyamatot felgyorsítani ezzel a cikkel.

Elsősorban fontos megérteni, hogy az Ansible kényelmes felületet biztosít számunkra egy előre meghatározott műveletek listájának végrehajtásához távoli szerveren (szervereken) SSH-n keresztül. Itt nincs semmiféle varázslat, nem lehet plugint telepíteni, és dobozból kapni a telepítési folyamatot nullás leállással a Docker, a monitorozás és egyéb extrák segítségével. Ahhoz, hogy playbookot írjunk, tudnunk kell, mit akarunk csinálni és hogyan. Ezért nem elégednek meg a GitHubon található kész playbookokkal, vagy az olyan cikkekkel, amelyek azt mondják: "Másold és futtasd, működni fog".

Mire van szükségünk?

Ahogy már említettem, ahhoz, hogy playbookot írjunk, tudnunk kell, mit akarunk csinálni és hogyan. Nézzük meg, mire van szükségünk. A Rails alkalmazáshoz szükségünk lesz néhány rendszerspecifikus csomagra: nginx, postgresql (redis, stb.). Ezen kívül szükségünk lesz a megfelelő verziójú Ruby-ra is. A legjobb, ha rbenv-en (rvm, asdf stb.) keresztül telepítjük. Mindig rossz ötlet root felhasználóként futtatni mindent, ezért létre kell hoznunk egy külön felhasználót, és be kell állítanunk a jogosultságait. Ezután fel kell töltenünk a kódunkat a szerverre, másolnunk kell a konfigurációkat az nginx-hez, postgreshez stb., és el kell indítanunk ezeket a szolgáltatásokat.

Végül a műveletek sorrendje a következő:

  1. Bejelentkezünk rootként
  2. telepítjük a rendszerspecifikus csomagokat
  3. új felhasználót hozunk létre, beállítjuk a jogosultságokat, ssh kulcsot
  4. beállítjuk a rendszerspecifikus csomagokat (nginx stb.) és elindítjuk azokat
  5. Létrehozunk egy felhasználót az adatbázisban (lehet, hogy az adatbázist is azonnal létrehozzuk)
  6. Bejelentkezünk az új felhasználóval
  7. telepítjük az rbenv-et és a Ruby-t
  8. telepítjük a bundlert
  9. feltöltjük az alkalmazás kódját
  10. elindítjuk a Puma szervert

Ráadásul az utolsó lépéseket a Capistrano segítségével is megtehetjük, hiszen az alapból képes a kódot feltölteni a kiadási könyvtárakba, a sikeres telepítés után szimbolikus linket váltani, átmozgatni a konfigurációkat a megosztott könyvtárból, újraindítani a Pumát stb. Mindezt meg lehet tenni az Ansible segítségével is, de miért tennénk?

Fájlszerkezet

Az Ansible-nek szigorú fájlszerkezete van minden fájl számára, ezért a legjobb, ha mindezt külön könyvtárban tartjuk. Nem számít, hogy az a rails alkalmazáson belül lesz-e, vagy külön. Fájlokat lehet tárolni egy külön git tárolóban is. Személy szerint nekem a legkényelmesebb az volt, hogy létrehoztam egy ansible könyvtárat a /config könyvtárban a rails alkalmazásban, és mindent egy tárolóban tároltam.

Egyszerű Playbook

A Playbook egy yml fájl, amelyben speciális szintaxissal le van írva, hogy az ansible-nek mit és hogyan kell csinálnia. Hozzuk létre az első playbook-ot, amely nem csinál semmit:

---
- name: Egyszerű playbook
  hosts: all

Itt egyszerűen azt mondjuk, hogy playbook-unknak ez a neve Egyszerű Playbook és hogy a tartalmát minden hoszton végre kell hajtani. Menthetjük a /ansible könyvtárba a playbook.yml és próbáljuk meg futtatni:

ansible-playbook ./playbook.yml

PLAY [Egyszerű Playbook] ************************************************************************************************************************************
kihagyás: nincs olyan hoszt, amely megfelelne

Az Ansible azt mondja, hogy nem ismeri a hosztokat, amelyek összhangban lennének az all listával. Ezeket egy speciális inventory fájlban kell felsorolni.

Hozzuk létre ezt a fájlt ugyanabban az ansible könyvtárban:

123.123.123.123

Így egyszerűen megadjuk a hosztot (ideális esetben a VPS-ünk hosztja a teszteléshez, vagy beírhatjuk a localhost-ot) és elmentjük a nevén inventory.
Próbáljunk meg ansible-t futtatni az inventory fájllal:

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

TASK [Tények gyűjtése] ************************************************************************************************************************************

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

Ha hozzáférése van ssh-n keresztül a megadott hoszthoz, akkor az ansible csatlakozik és összegyűjti az információt a távoli rendszerről. (alapértelmezett TASK [Tények gyűjtése]) után pedig rövid jelentést ad a végrehajtásról (PLAY RECAP).

Alapértelmezés szerint a kapcsolat felvételére azt a felhasználónevet használja, amellyel be van jelentkezve a rendszerbe. A hoszton valószínűleg nem lesz ilyen. A playbook fájlban megadhatja, hogy melyik felhasználót használja a csatlakozáshoz a remote_user utasítással. Ezenkívül az információ a távoli rendszerről gyakran nem hasznos, és nem érdemes időt pazarolni arra, hogy összegyűjtse. Ezt a feladatot szintén ki lehet kapcsolni:

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

Próbálja meg újra futtatni a playbookot, és győződjön meg arról, hogy a kapcsolat működik. (Ha a root felhasználót adta meg, akkor a become: true irányelvet is meg kell adnia a magasabb jogosultságok megszerzéséhez. Ahogy a dokumentációban le van írva: a become beállítása 'true'/'yes' értékre aktiválja a jogosultság-emelést. bár nem egészen világos, hogy miért).

Lehetséges, hogy olyan hiba lép fel, amelyet az okoz, hogy az ansible nem tudja meghatározni a Python értelmezőt, ezért ezt manuálisan kell megadni:

ansible_python_interpreter: /usr/bin/python3

hogy hol található a python, azt a whereis python.

Rendszerszoftverek telepítése

Az Ansible alapértelmezett telepítése számos modult tartalmaz, amelyek különböző rendszerszoftverekkel való munkához szükségesek, ezért nem kell minden esetben bash scriptet írni. Most szükségünk lesz az egyik ilyen modulra a rendszer frissítéséhez és a rendszerszoftverek telepítéséhez. Az én VPS-em Ubuntu Linuxot futtat, ezért a csomagok telepítéséhez a apt-get és modulját használom.Ha más operációs rendszert használ, akkor lehet, hogy másik modulra lesz szükség (ne feledje, hogy az elején mondtam, hogy előre tudnia kell, hogy mit és hogyan fogunk csinálni). Azonban a szintaxis valószínűleg hasonló lesz.

Bővítsük ki a playbookunkat az első feladatokkal:

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

  tasks:
    - name: Rendszer frissítése
      apt: update_cache=yes
    - name: Rendszer függőségek telepítése
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

A Task - ez az a feladat, amelyet az ansible végrehajt a távoli szervereken. Nevet adunk a feladatnak, hogy nyomon követhessük a végrehajtását a naplóban. És leírjuk, a konkrét modul szintaxisával, hogy mit kell tennie. Ebben az esetben apt: update_cache=yes - ez azt mondja, hogy frissítse a rendszerszoftvereket az apt modul segítségével. A második parancs kissé bonyolultabb. Átadunk a modulnak egy listát a csomagokról, és megmondjuk, hogy azokat state kell telepíteni present, tehát azt mondjuk, hogy telepítse ezeket a csomagokat. Hasonló módon azt is megmondhatjuk nekik, hogy távolítsák el vagy frissítsék őket, csak a statemegfelelő módosításával. Ne feledje, hogy a rails működéséhez a postgresql-lel szükségünk van a postgresql-contrib csomagra is, amelyet most telepítünk. Ezt ismét tudni kell és megtenni, az ansible önállóan ezt nem fogja megcsinálni.

Próbálja meg újra futtatni a playbookot, és ellenőrizze, hogy a csomagok telepítve vannak-e.

Új felhasználók létrehozása.

Az Ansible felhasználókkal való munkájához van egy modul — user. Adjunk hozzá egy új feladatot (a már ismert részeket kommentekkel rejtettem el, hogy ne kelljen minden alkalommal az egész playbookot másolnom):

---
- name: Egyszerű playbook
  # ...
  tasks:
    # ...
    - name: Új felhasználó hozzáadása
      user:
        name: my_user
        shell: /bin/bash
        password: "{{ 123qweasd | password_hash('sha512') }}"

Új felhasználót hozunk létre, beállítjuk a shelljét és a jelszavát. Azonnal több problémával szembesülünk. Mi van, ha a felhasználónevek eltérőek kell legyenek a különböző hosztok számára? És a jelszó nyílt formában való tárolása a playbookban nagyon rossz ötlet. Kezdetben emeljük ki a felhasználónevet és a jelszót változókba, a cikk vége felé megmutatom, hogyan titkosíthatjuk a jelszót.

---
- name: Egyszerű playbook
  # ...
  tasks:
    # ...
    - name: Új felhasználó hozzáadása
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"

A dupla kapcsos zárójelek segítségével állítunk be változókat a playbookokban.

A változók értékeit az inventory fájlban fogjuk megadni:

123.123.123.123

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

Figyeljük meg az utasítást [all:vars] — ez azt jelzi, hogy a következő szövegrész változók (vars), és ezek minden hosztra (all) érvényesek.

Érdekes az is, hogy "{{ user_password | password_hash('sha512') }}". Az a lényeg, hogy az ansible nem a user_add segítségével állítja be a felhasználót, ahogy azt manuálisan tennénk. Hanem közvetlenül tárolja az összes adatot, ezért a jelszót előre átalakítjuk hash-ként, amit ez a parancs is végez. Adjunk hozzá felhasználónkat a sudo csoporthoz. Azonban előtte biztosítanunk kell, hogy létezik-e ilyen csoport, mert ezt senki nem fogja megtenni helyettünk:

--- - name: Egyszerű playbook # ... tasks: # ... - name: Győződjön meg arról, hogy létezik egy 'sudo' csoport group: name: sudo state: present - name: Új felhasználó hozzáadása user: name: "{{ user }}" shell: /bin/bash password: "{{ user_password | password_hash('sha512') }}" groups: "sudo"

Minden elég egyszerű, rendelkezésünkre áll a group modul csoportok létrehozásához, amelynek szintaxisa nagyon hasonlít az apt-hoz. Ezután egyszerűen csak meg kell adni ezt a csoportot a felhasználónak (

groups: "sudo"Jó ötlet, ha SSH kulcsot is hozzáadunk ehhez a felhasználóhoz, hogy belépjünk hozzá jelszó nélkül:).
Hasznos lenne SSH kulcsot hozzáadni ennek a felhasználónak, hogy jelszó nélkül tudjunk bejelentkezni.

---
- name: Egyszerű playbook
  # ...
  tasks:
    # ...
    - name: Biztosítsa a 'sudo' csoportot
      group:
      name: sudo
        state: present
    - name: Új felhasználó hozzáadása
      user:
        name: "{{ user }}"
        shell: /bin/bash
        password: "{{ user_password | password_hash('sha512') }}"
        groups: "sudo"
    - name: SSH kulcs telepítése
      authorized_key:
        user: "{{ user }}"
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

Ebben az esetben az érdekes szerkezet "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — ez a fájl tartalmát másolja az id_rsa.pub-ból (nálad a neve eltérhet), vagyis az ssh kulcs nyilvános részét és feltölti a felhasználó engedélyezett kulcsainak listájába a szerveren.

Szerepek

Az összes három feladatot könnyen egy csoportba lehet sorolni, és nem lenne rossz ezt a csoportot külön tárolni a fő playbooktól, hogy ne nőjön túl nagyra. Erre az ansible-ben szereket.
A fent megadott fájlstruktúra szerint a szereket külön roles könyvtárba kell helyezni, minden szerephez külön könyvtárat létrehozva az azonos névvel, a könyvtár belsejében tasks, files, templates stb.
Hozzuk létre a fájlstruktúrát: ./ansible/roles/user/tasks/main.yml (main — ez a fő fájl, amely betöltődik és végrehajtódik, amikor a szerepet a playbookhoz csatolják, itt más fájlokat is csatlakoztathatsz a szerepből). Most áthelyezhetjük ebbe a fájlba az összes feladatot, amely a felhasználóhoz tartozik:

# 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 fő playbookban meg kell határozni a user szerep használatát:

---
- name: Egyszerű playbook
  hosts: all
  remote_user: root
  gather_facts: no

  tasks:
    - name: Rendszer frissítése
      apt: update_cache=yes
    - name: Rendszerfüggőségek telepítése
      apt:
        name: git,nginx,redis,postgresql,postgresql-contrib
        state: present

  roles:
    - user

Lehet, hogy érdemes a rendszer frissítését korábban elvégezni, mint a többi feladat, ehhez átnevezhetjük a blokkot tasks amelyben ezek meghatározva vannak pre_tasks.

nginx beállítása

Az Nginx-nek már telepítve kell lennie, konfigurálnunk és el kell indítanunk. Ezt azonnal a szerepen belül csináljuk. Hozzuk létre a fájlstruktúrát:

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

Most szükségünk lesz fájlokra és sablonokra. A különbség közöttük az, hogy az ansible a fájlokat közvetlenül másolja, ahogy vannak. A sablonoknak j2 kiterjesztésűeknek kell lenniük és értékeket használhatunk bennük a változók segítségével ugyanazokkal a dupla kapcsos zárójelekkel.

Hozzuk be az nginx-et a main.yml fájlba. Ehhez a systemd modult használjuk:

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

Itt nemcsak azt mondjuk, hogy az nginx-nek el kell indulnia (vagyis elindítjuk), hanem azt is, hogy engedélyezve kell lennie.
Most lemásoljuk a konfigurációs fájlokat:

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

Létrehozzuk az nginx fő konfigurációs fájlját (ezt közvetlenül a szerverről lemásolhatjuk, vagy saját magunk is megírhatjuk). Továbbá létre kell hoznunk egy konfigurációs fájlt az alkalmazásunkhoz a sites_available könyvtárba (ez nem kötelező, de hasznos). Az első esetben a copy modult használjuk a fájlok másolására (a fájlnak a következő helyen kell lennie: /ansible/roles/nginx/files/nginx.conf). A második esetben másoljuk a sablont, behelyettesítve a változók értékeit. A sablonnak a következő helyen kell lennie: /ansible/roles/nginx/templates/my_app.j2). Így nézhet ki például:

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

Figyeljen a beszúrásokra {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — ezek mind változók, amelyeket az ansible behelyettesít a sablonba a másolás előtt. Ez hasznos, ha a playbookot különböző hoszt csoportokhoz használjuk. Például kiegészíthetjük az inventory fájlunkat:

[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

Ha most elindítjuk a playbookunkat, akkor a megadott feladatokat mindkét hoszton végrehajtja. De a staging hosztnál a változók eltérnek a production-tól, és nemcsak a szerepek és playbookok, hanem az nginx konfigurációban is. {{ inventory_hostname }} nem szükséges megadni az inventory fájlban - ez egy speciális ansible változó és ott tárolódik az a hoszt, amelyre a playbookot éppen végrehajtják.
Ha több hoszt számára szeretne inventory fájlt készíteni, de csak egy csoport számára indítani, ezt a következő paranccsal megteheti:

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

egy másik lehetőség - külön inventory fájlokat készíteni a különböző csoportokhoz. Vagy a két megközelítést is kombinálhatja, ha sok különböző hosztja van.

Térjünk vissza az nginx konfigurálásához. A konfigurációs fájlok másolása után szimbólumot kell létrehoznunk a sites_enabled mappában a my_app.conf fájlt illetően a sites_available-ból. Majd újra kell indítani az nginx-t.

... # régi kód a mail.yml fájlban

- name: Szimbólum létrehozása a sites-enabled-hez
  file:
    src: \/etc\/nginx\/sites-available\/my_app.conf
    dest: \/etc\/nginx\/sites-enabled\/my_app.conf
    state: link

- name: nginx újraindítása
  service:
    name: nginx
    state: restarted

Itt minden egyszerű — ismét ansible modulok, amelyek elég szabványos szintaxissal rendelkeznek. De van egy fontos szempont. Nincs értelme minden alkalommal újraindítani a nginxt. Észrevetted, hogy nem írunk olyan parancsokat, hogy: „csináld így”, a szintaxis inkább úgy néz ki, mint „ennek ilyen állapotban kell lennie”. És a leggyakrabban éppen így működik az ansible. Ha a csoport már létezik, vagy a rendszercsomag már telepítve van, akkor az ansible ezt ellenőrzi és átugorja a feladatot. A fájlok sem lesznek másolva, ha teljesen megegyeznek azzal, ami már van a szerveren. Ezt kihasználhatjuk, és csak akkor indítjuk újra a nginxt, ha a konfigurációs fájlok megváltoztak. Erre létezik a register: utasítás.

# 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

Ha bármelyik konfigurációs fájl megváltozik, akkor a másolás végrehajtása és a változó regisztrálása fog megtörténni. restart_nginx. És csak akkor, ha ez a változó regisztrálva lett, a szolgáltatás újraindítása végrehajtásra kerül.

Nos, természetesen hozzá kell adni az nginx szerepet a fő playbookhoz.

Postgresql beállítása

Meg kell akadályoznunk a postgresql elindítását a systemd segítségével, pontosan úgy, ahogy azt a nginxt is tettük, és létre kell hoznunk egy felhasználót, amelyet az adatbázishoz való hozzáféréshez fogunk használni, valamint magát az adatbázist.
Hozzunk létre egy szerepet /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 }}"

Nem fogom részletezni, hogyan kell változókat hozzáadni az inventoryhoz, ezt már sokszor megtettük, akárcsak a postgresql_db és postgresql_user modulok szintaxisát. További adatok találhatók a dokumentációban. Itt a legérdekesebb utasítás a következő: become_user: postgres. A dolog lényege, hogy alapértelmezés szerint a postgresql adatbázishoz való hozzáférés csak a postgres felhasználónak és csak helyben lehetséges. Ez az utasítás lehetővé teszi számunkra, hogy parancsokat futtassunk ennek a felhasználónak a nevében (ha természetesen van hozzáférésünk).
Lehet, hogy a pg_hba.conf fájlba is be kell írnod egy sort, hogy megnyisd az új felhasználó hozzáférését az adatbázisba. Ezt pontosan úgy lehet megtenni, ahogy a nginx konfigurációját is módosítottuk.

Nos, természetesen hozzá kell adni a postgresql szerepet a fő playbookhoz.

Ruby telepítése rbenv-en keresztül

Az ansible-ben nincsenek modulok a rbenv kezelésére, és a telepítés a git repository klónozásával történik. Ezért ez a feladat a legnagyobb eltéréseket mutatja. Hozzunk létre ennek a szerepet /ansible/roles/ruby_rbenv/main.yml és kezdjük el kitölteni:

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

Ismét a become_user utasítást használjuk, hogy az általunk létrehozott felhasználó nevében dolgozzunk. Mivel az rbenv az ő home könyvtárába van telepítve, nem globálisan. Emellett a git modult is használjuk a tároló klónozásához, feltüntetve a repo-t és a dest-et.

Ezután szükség van az rbenv init parancs hozzáadására a bashrc fájlhoz, és ehhez is adjuk hozzá az rbenv-t a PATH változóhoz. Ehhez a lineinfile modult használjuk:

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

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

Ezután telepíteni kell a ruby_build-ot:

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

Végül telepíteni kell a ruby-t. Ezt az rbenv-en keresztül tehetjük meg, csak egy bash parancs segítségével:

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

Megmondjuk, milyen parancsot kell végrehajtani és mivel. Azonban itt beleütközünk abba, hogy az ansible nem hajtja végre a bashrc fájlban található kódot a parancsok futtatása előtt. Ezért az rbenv definícióját közvetlenül ebben a szkriptben kell elhelyezni.

A következő probléma az, hogy a shell parancsnak nincs állapota az ansible szempontjából. Ezért automatikus ellenőrzés arra, hogy a ruby verzió telepítve van-e, nem lesz. Mi magunk is megtehetjük:

- név: 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

Ezután telepítenünk kell a bundler-t:

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

És ismét hozzá kell adnunk a ruby_rbenv szerepünket a fő playbookhoz.

Megosztott fájlok.

Összességében itt a beállítást be lehetne fejezni. Ezt követően el kell indítani a capistrano-t, és az automatikusan átmásolja a kódot, létrehozza a szükséges könyvtárakat és elindítja az alkalmazást (ha minden helyesen van beállítva). Azonban gyakran a capistrano-hoz további konfigurációs fájlok szükségesek, mint például database.yml vagy .env Ezeket pontosan úgy lehet átmásolni, mint a nginx fájlokat és sablonokat. Csak egy apróság van. A fájlok másolása előtt létre kell hozni a könyvtárak struktúráját, valami ilyesmit:

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

Csak egy könyvtárat adunk meg, és az ansible automatikusan létrehozza a szülő könyvtárakat, ha szükséges.

Ansible Vault

Már találkoztunk azzal, hogy a változók titkos adatokat tartalmazhatnak, például a felhasználó jelszavát. Ha létrehoztál .env fájl az alkalmazás számára, és database.yml ott még több kritikus adatnak kellene lennie. Ezt jó lenne elrejteni a kíváncsi szemek elől. Erre az ansible vault.

létrehozunk egy fájlt a változók számára /ansible/vars/all.yml (itt különböző fájlokat hozhatsz létre különböző hosztcsoportok számára, pont úgy, mint az inventory fájlban: production.yml, staging.yml, stb.).
Ebben a fájlban át kell helyezni az összes, titkosítani kívánt változót a standard yml szintaxis használatával:

# 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

Ezután a fájlt a következő parancs segítségével titkosíthatod:

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

Természetesen a titkosításkor meg kell adnod egy jelszót a visszafejtéshez. Megnézheted, mi lesz a fájlban ennek a parancsnak a végrehajtása után.

Segítségével ansible-vault decrypt a fájl visszafejthető, módosítható és újra titkosítható.

Az alkalmazáshoz nem szükséges a fájl visszafejtése. Titkosítva tárolod, és a playbookot az alábbi argumentummal indítod --ask-vault-pass. Az Ansible megkérdezi a jelszót, előhívja a változókat és végrehajtja a feladatokat. Minden adat titkosítva marad.

A teljes parancs több hosztcsoport és az ansible vault esetén körülbelül így néz ki:

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

A playbookok és szerepek teljes szövegét nem adom meg, írjátok meg magatok. Mert az Ansible ilyen — ha nem érted, mit kell tenned, akkor ő sem fogja megtenni.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster