ProHoster > Blog > Amministrazione > Configurazione di un servitore per implementà una applicazione Rails Utilizendu Ansible

Configurazione di un servitore per implementà una applicazione Rails Utilizendu Ansible

Micca tantu tempu, avia bisognu di scrive parechji libri di ghjocu ansible per preparà u servitore per implementà una applicazione rails. E, sorprendentemente, ùn aghju micca trovu un manuale simplice passu à passu. Ùn vulia micca copià u librettu di l'altru senza capisce ciò chì passava, è in u risultatu, aghju avutu à leghje a ducumentazione, cullendu tuttu per mè stessu. Forsi possu aiutà à qualchissia per accelerà stu prucessu cù l'aiutu di stu articulu.

A prima cosa da capisce hè chì ansible vi furnisce una interfaccia còmuda per realizà una lista predefinita di l'azzioni nantu à un servitore (s) remoto via SSH. Ùn ci hè micca magia quì, ùn pudete micca installà un plugin è uttene una implementazione zero downtime di a vostra applicazione cù docker, monitoraghju è altri boni fora di a scatula. Per scrive un playbook, avete bisognu di sapè esattamente ciò chì vulete fà è cumu fà. Dunque, ùn sò micca cuntentu di playbooks pronti da github, o articuli cum'è: "Copia è eseguite, funzionerà".

Chì avemu bisognu?

Comu dissi, per scrive un libru di ghjocu, avete bisognu di sapè ciò chì vulete fà è cumu fà. Decidemu ciò chì avemu bisognu. Per una applicazione Rails, avemu bisognu di parechji pacchetti di sistema: nginx, postgresql (redis, etc.). Inoltre, avemu bisognu di ruby ​​​​di una certa versione. Hè megliu installallu cù rbenv (rvm, asdf...). Eseguisce tuttu questu cum'è un utilizatore root hè sempre una mala idea, cusì avete bisognu di creà un utilizatore separatu è stabilisce permessi per ellu. Dopu quì, avete bisognu di cullà u nostru codice à u servitore, copià a cunfigurazione per nginx, postgres, etc. è principià tutti questi servizii.

In u risultatu, a sequenza di l'azzioni hè a siguenti:

  1. Login sottu root
  2. installà i pacchetti di sistema
  3. creà un novu utilizatore, cunfigurà i diritti, chjave ssh
  4. cunfigurà i pacchetti di sistema (nginx etc.) è eseguite
  5. Crea un utilizatore in a basa di dati (pudete immediatamente creà una basa di dati)
  6. Login cum'è un novu utilizatore
  7. Installazione di rbenv è ruby
  8. Installazione di u bundler
  9. Caricà u codice di l'applicazione
  10. Cumincià u Puma Server

Inoltre, l'ultimi passi ponu esse fatti cù capistrano, almenu pò copià u codice per liberà i cartulari fora di a scatula, cambia a liberazione cù un ligame simbolicu dopu a implementazione successu, copià e cunfigurazioni da u cartulare spartutu, riavvia puma, etc. Tuttu chistu pò esse fattu cù Ansible, ma perchè?

Struttura di u schedariu

Ansible hà un strettu struttura di u schedariu per tutti i vostri fugliali, cusì hè megliu di mantene tuttu in un repertoriu separatu. È ùn hè micca cusì impurtante s'ellu serà in l'applicazione di rails stessu, o separatamente. Pudete almacenà i fugliali in un repository git separatu. In modu persunale, aghju trovu a più còmuda di creà un repertoriu ansible in u cartulare /config di l'applicazione rails è almacenà tuttu in un repository.

libru di ghjocu simplice

Un playbook hè un schedariu yml chì descrive, utilizendu una sintassi speciale, ciò chì è cumu ansible deve fà. Creemu u primu playbook chì ùn faci nunda:

---
- name: Simple playbook
  hosts: all

Quì dicemu solu chì u nostru playbook hè chjamatu Simple Playbook è chì u so cuntenutu deve esse currettu per tutti l'ospiti. Pudemu almacenà in u cartulare / ansible chjamatu playbook.yml è pruvate à curriri:

ansible-playbook ./playbook.yml

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

Ansible dice chì ùn cunnosci micca alcun host chì currisponde à a lista di tutti. Anu deve esse listatu in un speciale schedariu d'inventariu.

Creemu in u stessu annuariu ansible:

123.123.123.123

Hè cusì chì simpricimenti specifichi l'ospite (idealmente, l'ospite di u nostru VPS per i testi, o pudete registrà u locale host) è salvate sottu u nome inventory.
Pudete pruvà à eseguisce ansible cù un schedariu d'inventariu:

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

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

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

Sì avete accessu ssh à l'ospitu specificatu, allora ansible si cunnetta è raccoglie infurmazioni nantu à u sistema remoto. (TASK predeterminatu [Gathering Facts] ) dopu chì darà un riassuntu di l'esekzione (PLAY RECAP).

Per automaticamente, a cunnessione usa u nome d'utilizatore sottu à quale site cunnessu in u sistema. Hè assai prubabile, ùn serà micca nantu à l'ospite. In u schedariu di playbook, pudete specificà quale utilizatore per utilizà per cunnette cù a direttiva remote_user. Inoltre, l'infurmazioni nantu à un sistema remotu pò esse spessu innecessariu per voi è ùn avete micca perdi u tempu à cullà. Stu compitu pò ancu esse disattivatu:

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

Pruvate torna u playbook è verificate chì a cunnessione funziona. (Se avete specificatu l'utilizatore root, allora avete bisognu di specificà u diventatu: vera direttiva per ottene diritti elevati. Cumu hè scrittu in a documentazione: become set to ‘true’/’yes’ to activate privilege escalation. ancu s'ellu ùn hè micca chjaru perchè).

Forse vi uttene un errore causatu da u fattu chì ansible ùn pò micca determinà l'interprete python, allora pudete specificà manualmente:

ansible_python_interpreter: /usr/bin/python3

induve avete python, pudete truvà fora cù u cumandamentu whereis python.

Installazione di pacchetti di sistema

В стандартной поставке Ansible входит множетсво модулей для работы с различными системными пакетами, благодаря чему нам не приходится по любому поводу писать bash скрипты. Сейчас нам понадобится один из таких модулей для обновления системы и установки системных пакетов. У меня на VPS стоит Ubuntu Linux соответсвенно для установки пакетов я использую apt-get и modulu per questu. Sè vo aduprate un sistema upirativu differente, allura vi pò bisognu di un modulu differente (ricurdatevi, aghju dettu à u principiu chì avete bisognu di sapè in anticipu chì è cumu faremu). Tuttavia, a sintassi hè prubabilmente simile.

Cumpitemu u nostru libru di ghjocu cù i primi compiti:

---
- 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 hè solu u compitu chì ansible farà nantu à i servitori remoti. Demu à u compitu un nome per seguità a so esecuzione in u log. E discrimu, utilizendu a sintassi di un modulu particulari, ciò chì deve fà. In stu casu apt: update_cache=yes - dice di aghjurnà i pacchetti di u sistema utilizendu u modulu apt. U sicondu cumandamentu hè un pocu più cumplicatu. Passemu una lista di pacchetti à u modulu apt, è dicemu chì elli state deve diventà present, vale à dì, dicemu installate questi pacchetti. In listessu modu, pudemu dì à elli à sguassà, o aghjurnà, da solu cambià state. Nota chì per i rails per travaglià cù postgresql, avemu bisognu di u pacchettu postgresql-contrib, chì avemu installatu attualmente. In novu, avete bisognu di sapè è fà questu, ansible da ellu stessu ùn farà micca questu.

Pruvate torna u playbook è verificate chì i pacchetti installati.

Creazione di novi utilizatori.

Per travaglià cù l'utilizatori, Ansible hà ancu un modulu - user. Aghjunghjite un compitu più (aghju ammucciatu e parti digià cunnisciute di u playbook daretu à i cumenti per ùn copià micca sanu sanu ogni volta):

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

Creemu un novu utilizatore, stabilisce una cunchiglia è una password per ellu. È dopu avemu incuntrà parechji prublemi. E se i nomi d'utilizatore duveranu esse sfarenti per diversi hosts? Iè, è almacenà a password in testu chjaru in u playbook hè una idea assai mala. Per principià, avemu da piglià u nome d'utilizatore è a password in variàbili, è versu a fine di l'articulu vi mustraraghju cumu si cripta a password.

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

E variabili sò stabilite aduprendu parentesi doppia curly in playbooks.

Avemu da specificà i valori di e variàbili in u schedariu d'inventariu:

123.123.123.123

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

Attenti à a direttiva [all:vars] - ella dice chì u prossimu bloccu di testu hè variàbili (vars) è sò appiicati à tutti l'ospiti (tutti).

Ancu un disignu interessante "{{ user_password | password_hash('sha512') }}". U puntu hè chì ansible ùn stabilisce micca l'utilizatori via user_add cum'è avete fattu manualmente. È salva tutti i dati direttamente, chì hè per quessa chì avemu ancu bisognu di cunvertisce a password in un hash in anticipu, chì questu cumanda faci.

Aghjunghjemu u nostru utilizatore à u gruppu sudo. Tuttavia, prima di quessa, avete bisognu di assicurà chì un tali gruppu esiste perchè nimu hà da fà questu per noi:

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

Hè abbastanza simplice, avemu ancu un modulu di gruppu per creà gruppi, cù una sintassi assai simili à apt. Dopu questu, hè abbastanza per registrà stu gruppu à l'utilizatore (groups: "sudo").
Hè ancu utile per aghjunghje una chjave ssh à questu utilizatore in modu chì pudemu login senza password:

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

In questu casu, a custruzzione "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - copia u cuntenutu di u schedariu id_rsa.pub (u vostru nome pò esse diversu), vale à dì, a parte publica di a chjave ssh è a carica in a lista di chjavi autorizati per l'utilizatore nantu à u servitore.

Ruoli

Tutti i trè compiti per creà l'usu pò esse facilmente attribuiti à u stessu gruppu di travagliu, è saria bellu di mantene stu gruppu separatu da u playbook principale per ùn cresce micca troppu. Per questu, ansible hà roli.
Sicondu a struttura di u schedariu indicata à u principiu, i roli devenu esse posti in un repertoriu di roli separati, per ogni rolu ci hè un repertoriu separatu cù u stessu nome, in u repertoriu di funzioni, schedari, mudelli, etc.
Creemu una struttura di file: ./ansible/roles/user/tasks/main.yml (principale hè u schedariu principale chì serà caricatu è eseguitu quandu u rolu hè cunnessu à u playbook, altri schedarii di rolu ponu esse cunnessi in questu). Avà vi ponu trasfiriri tutti i compiti riguardanti lu utilizatori à stu schedariu:

# 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

In u playbook principale, duvete specificà per utilizà u rolu d'utilizatore:

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

Inoltre, pò esse sensu per aghjurnà u sistema prima di tutti l'altri travaglii, per questu pudete rinominà u bloccu tasks in quale sò definiti in pre_tasks.

Configurazione di nginx

Avemu digià avè installatu Nginx, avemu bisognu di cunfigurà è eseguisce. Facemu subitu in u rolu. Crea una struttura di file:

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

Avà avemu bisognu di schedari è mudelli. A diffarenza trà elli hè chì ansible copia direttamente i schedari, cum'è. È i mudelli anu da avè l'estensione j2 è pudete aduprà i valori di variàbili in elli usendu i stessi doppi ricci.

Abilitemu nginx in main.yml schedariu. Per questu avemu u modulu systemd:

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

Quì ùn dicemu micca solu chì nginx deve esse iniziatu (vale à dì, avemu principiatu), ma immediatamente dicemu chì deve esse attivatu.
Avà copiemu i schedarii di cunfigurazione:

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

Creemu u schedariu principale di cunfigurazione nginx (pudete piglià direttamente da u servitore, o scrivite sè stessu). È ancu u schedariu di cunfigurazione per a nostra applicazione in u repertoriu sites_available (questu ùn hè micca necessariu ma utile). In u primu casu, usemu u modulu di copia per copià i schedari (u schedariu deve esse in /ansible/roles/nginx/files/nginx.conf). In u sicondu, copiamu u mudellu, sustituendu i valori di e variàbili. U mudellu deve esse in /ansible/roles/nginx/templates/my_app.j2). È pò esse simile à questu:

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

Prestate attenzione à l'inserzioni {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} sò tutte e variàbili chì i valori chì anu da rimpiazzà in u mudellu prima di cupià. Questu hè utile se utilizate un libru di ghjocu per diversi gruppi di ospiti. Per esempiu, pudemu aghjunghje à u nostru schedariu d'inventariu:

[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

Se eseguimu u nostru playbook avà, eseguirà i travaglii specificati per i dui ospiti. Ma à u stessu tempu, per l'ospitu di staging, i variàbili seranu diffirenti da quelli di pruduzzione, è micca solu in roli è playbooks, ma ancu in nginx configs. {{ inventory_hostname }} ùn deve esse specificatu in u schedariu d'inventariu - questu Variabile speciale ansible è l'ospite per quale u playbook hè attualmente in esecuzione hè almacenatu quì.
Se vulete avè un schedariu d'inventariu per parechji ospiti, ma eseguite solu per un gruppu, pudete fà cusì cù u cumandimu seguente:

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

un'altra opzione hè di avè schedarii d'inventariu separati per i diversi gruppi. O pudete cumminà i dui approcci si avete parechji ospiti diffirenti.

Riturnemu à a stallazione di nginx. Dopu avè copiatu i schedarii di cunfigurazione, avemu bisognu di creà un ligame simbolicu in sitest_enabled à my_app.conf da sites_available. È riavvia 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

Tuttu hè simplice quì - dinò moduli ansible cù una sintassi abbastanza standard. Ma ci hè un mumentu. Riavvià nginx ogni volta ùn hà micca sensu. Avete nutatu chì ùn scrivemu micca cumandamenti cum'è: "fate questu cusì", a sintassi s'assumiglia più "questu deve avè un statu cusì". È più spessu questu hè cumu funziona ansible. Se u gruppu esiste digià, o u pacchettu di u sistema hè digià stallatu, allora ansible verificarà questu è salta u compitu. Inoltre, i schedari ùn saranu micca copiati s'ellu currispondenu cumplettamente ciò chì hè digià in u servitore. Pudemu prufittà di questu è riavvia nginx solu se i schedarii di cunfigurazione anu cambiatu. Ci hè una direttiva di registru per questu:

# 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

Se unu di i schedarii di cunfigurazione cambia, allora una copia serà fatta è una variabile serà registrata restart_nginx. È solu se sta variabile hè stata registrata, u serviziu serà riavviatu.

E, sicuru, avete bisognu di aghjunghje u rolu nginx à u playbook principale.

installazione di postgresql

Avemu bisognu di attivà postgresql cù systemd cum'è avemu fattu cù nginx, è ancu creà un utilizatore chì avemu aduprà per accede à a basa di dati è a basa di dati stessu.
Creemu un rolu /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 }}"

Ùn scriveraghju micca cumu aghjunghje variàbili à l'inventariu, questu hè digià fattu parechje volte, è ancu a sintassi di i moduli postgresql_db è postgresql_user. Più infurmazione pò esse truvata in a documentazione. Eccu a direttiva più interessante become_user: postgres. U fattu hè chì per automaticamente, solu l'utilizatore di postgres hà accessu à a basa di dati postgresql è solu in u locu. Questa direttiva ci permette di eseguisce cumandamenti in nome di questu utilizatore (se avemu accessu, sicuru).
Inoltre, pudete avè bisognu di aghjunghje una linea à pg_hba.conf per permette un novu accessu d'utilizatori à a basa di dati. Questu pò esse fattu da a listessa manera chì avemu cambiatu a cunfigurazione nginx.

E sicuru, avete bisognu di aghjunghje u rolu di postgresql à u playbook principale.

Installazione di ruby ​​​​via rbenv

Ansible ùn hà micca moduli per travaglià cù rbenv, ma hè stallatu clonendu u repository git. Per quessa, stu compitu diventa u più micca standard. Creemu un rolu per ella /ansible/roles/ruby_rbenv/main.yml è cuminciate à riempie:

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

Avemu dinò aduprà a direttiva di diventà_utente per travaglià sottu à l'utilizatore chì avemu creatu per questu scopu. Perchè rbenv hè stallatu in u so cartulare di casa, micca in u mondu. È avemu ancu aduprà u modulu git per clone u repository specificendu repo è dest.

Dopu, avemu bisognu di aghjunghje rbenv init à bashrc è aghjunghje rbenv à PATH in u stessu locu. Per questu avemu u modulu 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 -)"'

Allora avete bisognu di stallà ruby_build:

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

È infine stallà ruby. Questu hè fattu attraversu rbenv, vale à dì basta bash cù u cumandimu:

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

Dicemu quale cumandamentu per eseguisce è cun quale. In ogni casu, quì sbatteremu nantu à u fattu chì ansible ùn eseguisce micca u codice cuntenutu in bashrc prima di eseguisce cumandamenti. Questu significa chì rbenv duverà esse definitu direttamente in u stessu script.

U prossimu prublema hè chì u cumandamentu di shell hè senza statu da u puntu di vista di ansible. Questu hè, ùn ci sarà micca un cuntrollu automaticu se sta versione di ruby ​​​​hè installata o micca. Pudemu fà noi stessi:

- 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

È resta à stallà u bundler:

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

È torna aghjunghje u nostru rolu ruby_rbenv à u playbook principale.

I schedarii spartuti.

In generale, stu paràmetru pò esse cumpletu. Tandu resta à eseguisce capistrano è copià u codice stessu, creà i cartulari necessarii è lanciari l'applicazione (se tuttu hè cunfiguratu bè). Tuttavia, capistrano spessu bisognu di schedarii di cunfigurazione supplementari, cum'è database.yml o .env Puderanu esse copiati cum'è i schedari è mudelli per nginx. Ci hè solu una suttilità. Prima di cupià i schedari, avete bisognu di creà una struttura di cartulare per elli, qualcosa cum'è questu:

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

specifiemu solu un repertoriu è ansible creerà automaticamente u genitore se necessariu.

Ansible Vault

Avemu digià stumbled in u fattu chì e variàbili ponu cuntene dati secreti cum'è a password di l'utilizatore. Sì avete creatu .env u schedariu di l'applicazione, è database.yml tandu ci deve esse ancu di più di tali dati critichi. Saria bellu piattà li da l'occhi indiscreti. Per questu, hè utilizatu volta ansible.

Crea un schedariu per variàbili /ansible/vars/all.yml (quì pudete creà diversi schedarii per diversi gruppi di ospiti, cum'è in u schedariu d'inventariu: production.yml, staging.yml, etc.).
Tutte e variàbili devenu esse trasferite à stu schedariu, chì deve esse criptatu cù a sintassi standard yml:

# 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

Dopu questu, stu schedariu pò esse criptatu cù u cumandimu:

ansible-vault encrypt ./vars/all.yml

Naturalmente, quandu cifrate, avete bisognu di stabilisce una password per a decryption. Pudete vede ciò chì serà in u schedariu dopu avè chjamatu stu cumandamentu.

Cù l'aiutu di ansible-vault decrypt u schedariu pò esse decriptatu, mudificatu è poi criptatu novu.

Ùn avete bisognu di decrypt u schedariu per travaglià. L'avete criptatu è eseguite u playbook cù l'argumentu --ask-vault-pass. Ansible dumandarà a password, uttene e variàbili, è eseguisce i travaglii. Tutti i dati restanu criptati.

U cumandamentu cumpletu per parechji gruppi d'ospiti è ansible vault parerebbe cusì cusì:

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

È ùn vi daraghju u testu sanu di i playbooks è i roli, scrivite sè stessu. Perchè l'ansible hè una tale cosa - sè ùn avete micca capitu ciò chì deve esse fattu, allora ùn vi farà micca.

Source: www.habr.com

Cumprate un hosting affidabile per i siti cù prutezzione DDoS, servitori VPS VDS 🔥 Cumprate un hosting di siti web affidabile cù prutezzione DDoS, servitori VPS VDS | ProHoster