ProHoster > Bloc > Administració > Configuració d'un servidor per desplegar una aplicació Rails mitjançant Ansible

Configuració d'un servidor per desplegar una aplicació Rails mitjançant Ansible

No fa molt, vaig necessitar escriure diversos llibres de jugades d'Ansible per preparar el servidor per desplegar una aplicació Rails. I, sorprenentment, no vaig trobar un manual senzill pas a pas. No volia copiar el llibre de jocs d'una altra persona sense entendre què passava, i al final vaig haver de llegir la documentació, recollint-ho tot jo mateix. Potser puc ajudar algú a accelerar aquest procés amb l'ajuda d'aquest article.

El primer que cal entendre és que ansible us proporciona una interfície convenient per dur a terme una llista predefinida d'accions en un servidor remot mitjançant SSH. Aquí no hi ha màgia, no podeu instal·lar un connector i obtenir un desplegament de temps d'inactivitat zero de la vostra aplicació amb Docker, monitorització i altres avantatges fora de la caixa. Per escriure un llibre de jocs, has de saber què vols fer exactament i com fer-ho. És per això que no estic satisfet amb llibres de jugades preparats de GitHub o articles com: "Copia i executa, funcionarà".

Què necessitem?

Com ja he dit, per escriure un llibre de jocs cal saber què vols fer i com fer-ho. Anem a decidir què necessitem. Per a una aplicació Rails necessitarem diversos paquets de sistema: nginx, postgresql (redis, etc.). A més, necessitem una versió específica de rubí. El millor és instal·lar-lo mitjançant rbenv (rvm, asdf...). Executar tot això com a usuari root sempre és una mala idea, de manera que cal crear un usuari independent i configurar els seus drets. Després d'això, heu de pujar el nostre codi al servidor, copiar les configuracions de nginx, postgres, etc. i iniciar tots aquests serveis.

Com a resultat, la seqüència d'accions és la següent:

  1. Inicieu sessió com a root
  2. instal·lar paquets del sistema
  3. crear un nou usuari, configurar drets, clau ssh
  4. configureu els paquets del sistema (nginx, etc.) i executeu-los
  5. Creem un usuari a la base de dades (podeu crear una base de dades immediatament)
  6. Inicieu sessió com a usuari nou
  7. Instal·leu rbenv i ruby
  8. Instal·lació del bundler
  9. Carregant el codi de l'aplicació
  10. Llançament del servidor Puma

A més, les últimes etapes es poden fer amb capistrano, almenys fora de la caixa pot copiar codi als directoris de llançament, canviar la versió amb un enllaç simbòlic després d'un desplegament correcte, copiar configuracions d'un directori compartit, reiniciar puma, etc. Tot això es pot fer amb Ansible, però per què?

Estructura de fitxers

Ansible té estricte estructura de fitxers per a tots els vostres fitxers, així que el millor és mantenir-ho tot en un directori separat. A més, no és tan important si serà a la pròpia aplicació de rails o per separat. Podeu emmagatzemar fitxers en un repositori git separat. Personalment, em va semblar més convenient crear un directori ansible al directori /config de l'aplicació rails i emmagatzemar-ho tot en un sol dipòsit.

Llibre de jocs senzill

Playbook és un fitxer yml que, utilitzant una sintaxi especial, descriu què hauria de fer Ansible i com. Creem el primer llibre de jugades que no fa res:

---
- name: Simple playbook
  hosts: all

Aquí simplement diem que el nostre llibre de jugades es diu Simple Playbook i que el seu contingut s'hauria d'executar per a tots els amfitrions. El podem desar al directori /ansible amb el nom playbook.yml i intenta córrer:

ansible-playbook ./playbook.yml

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

Ansible diu que no coneix cap amfitrió que coincideixi amb la llista de tots. Han de figurar en un especial arxiu d'inventari.

Creem-lo al mateix directori ansible:

123.123.123.123

Així és com simplement especifiquem l'amfitrió (idealment l'amfitrió del nostre VPS per a la prova, o podeu registrar localhost) i el desem amb el nom inventory.
Podeu provar d'executar ansible amb un fitxer d'inventari:

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

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

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

Si teniu accés ssh a l'amfitrió especificat, ansible es connectarà i recopilarà informació sobre el sistema remot. (TASCA per defecte [Recollida de fets]) després del qual donarà un breu informe sobre l'execució (REPRODUCIR RECUPERACIÓ).

De manera predeterminada, la connexió utilitza el nom d'usuari amb el qual heu iniciat sessió al sistema. El més probable és que no estigui a l'amfitrió. Al fitxer del llibre de jocs, podeu especificar quin usuari utilitzareu per connectar-vos mitjançant la directiva remote_user. A més, la informació sobre un sistema remot sovint pot ser innecessària per a vostè i no hauríeu de perdre temps recollint-la. Aquesta tasca també es pot desactivar:

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

Proveu de tornar a executar el llibre de jocs i assegureu-vos que la connexió funciona. (Si heu especificat l'usuari root, també haureu d'especificar la directiva become: true per obtenir drets elevats. Tal com està escrit a la documentació: become set to ‘true’/’yes’ to activate privilege escalation. encara que no està del tot clar per què).

Potser rebreu un error causat pel fet que ansible no pot determinar l'intèrpret de Python, llavors podeu especificar-lo manualment:

ansible_python_interpreter: /usr/bin/python3

Podeu esbrinar on teniu Python amb l'ordre whereis python.

Instal·lació de paquets del sistema

La distribució estàndard d'Ansible inclou molts mòduls per treballar amb diversos paquets del sistema, de manera que no hem d'escriure scripts bash per cap motiu. Ara necessitem un d'aquests mòduls per actualitzar el sistema i instal·lar paquets del sistema. Tinc Ubuntu Linux al meu VPS, així que per instal·lar els paquets que faig servir apt-get и mòdul per a això. Si utilitzeu un sistema operatiu diferent, és possible que necessiteu un mòdul diferent (recordeu, vaig dir al principi que hem de saber per endavant què farem i com farem). Tanmateix, la sintaxi probablement serà similar.

Complementem el nostre llibre de jugades amb les primeres tasques:

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

La tasca és exactament la tasca que Ansible realitzarà als servidors remots. Donem un nom a la tasca perquè puguem fer un seguiment de la seva execució al registre. I descrivim, utilitzant la sintaxi d'un mòdul concret, què ha de fer. En aquest cas apt: update_cache=yes - diu que actualitzeu els paquets del sistema mitjançant el mòdul apt. La segona ordre és una mica més complicada. Passem una llista de paquets al mòdul apt i diem que ho són state hauria de convertir-se present, és a dir, diem instal·lar aquests paquets. De la mateixa manera, podem dir-los que els suprimeixin o que els actualitzin simplement canviant state. Tingueu en compte que perquè els rails funcionin amb postgresql necessitem el paquet postgresql-contrib, que estem instal·lant ara. Una vegada més, cal saber-ho i fer-ho; ansible per si sol no ho farà.

Proveu de tornar a executar el llibre de jocs i comproveu que els paquets estiguin instal·lats.

Creació de nous usuaris.

Per treballar amb usuaris, Ansible també disposa d'un mòdul - usuari. Afegim una tasca més (he amagat les parts ja conegudes del llibre de jocs darrere dels comentaris per no copiar-lo completament cada vegada): 

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

Creem un nou usuari, establim un schell i una contrasenya. I després ens trobem amb diversos problemes. Què passa si els noms d'usuari han de ser diferents per a diferents amfitrions? I emmagatzemar la contrasenya en text clar al llibre de jugades és una molt mala idea. Per començar, posem el nom d'usuari i la contrasenya en variables, i cap al final de l'article mostraré com xifrar la contrasenya.

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

Les variables s'estableixen als llibres de jugades mitjançant claus dobles.

Indicarem els valors de les variables al fitxer d'inventari:

123.123.123.123

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

Tingueu en compte la directiva [all:vars] - diu que el següent bloc de text són variables (vars) i són aplicables a tots els hosts (tots).

El disseny també és interessant "{{ user_password | password_hash('sha512') }}". El cas és que ansible no instal·la l'usuari via user_add com ho faries manualment. I guarda totes les dades directament, per això també hem de convertir la contrasenya en un hash per endavant, que és el que fa aquesta ordre.

Afegim el nostre usuari al grup sudo. Tanmateix, abans d'això hem d'assegurar-nos que aquest grup existeix perquè ningú ho farà per nosaltres:

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

Tot és força senzill, també disposem d'un mòdul de grup per crear grups, amb una sintaxi molt semblant a l'apt. Aleshores n'hi ha prou amb registrar aquest grup a l'usuari (groups: "sudo").
També és útil afegir una clau ssh a aquest usuari perquè puguem iniciar sessió utilitzant-la sense contrasenya:

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

En aquest cas, el disseny és interessant "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — copia el contingut del fitxer id_rsa.pub (el vostre nom pot ser diferent), és a dir, la part pública de la clau ssh i la puja a la llista de claus autoritzades per a l'usuari al servidor.

Funcions

Les tres tasques per crear ús es poden classificar fàcilment en un grup de tasques, i seria una bona idea emmagatzemar aquest grup per separat del llibre de jocs principal perquè no creixi massa. Amb aquesta finalitat, Ansible té paper.
Segons l'estructura de fitxers indicada al principi, els rols s'han de col·locar en un directori de rols separat, per a cada rol hi ha un directori separat amb el mateix nom, dins del directori de tasques, fitxers, plantilles, etc.
Creem una estructura de fitxers: ./ansible/roles/user/tasks/main.yml (main és el fitxer principal que es carregarà i s'executarà quan un rol estigui connectat al llibre de jugades; es poden connectar altres fitxers de rol). Ara podeu transferir totes les tasques relacionades amb l'usuari a aquest fitxer:

# 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

Al manual principal, heu d'especificar per utilitzar el rol d'usuari:

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

A més, pot tenir sentit actualitzar el sistema abans de totes les altres tasques; per fer-ho, podeu canviar el nom del bloc tasks en què es defineixen en pre_tasks.

Configuració de nginx

Ja hauríem de tenir instal·lat Nginx; hem de configurar-lo i executar-lo. Fem-ho de seguida en el paper. Creem una estructura de fitxers:

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

Ara necessitem fitxers i plantilles. La diferència entre ells és que ansible copia els fitxers directament, tal com són. I les plantilles han de tenir l'extensió j2 i poden utilitzar valors variables utilitzant les mateixes claus dobles.

Activem nginx main.yml dossier. Per a això tenim un mòdul systemd:

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

Aquí no només diem que nginx s'ha d'iniciar (és a dir, l'iniciem), sinó que de seguida diem que s'ha d'habilitar.
Ara copiem els fitxers de configuració:

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

Creem el fitxer de configuració principal de nginx (pots agafar-lo directament del servidor o escriure'l tu mateix). I també el fitxer de configuració de la nostra aplicació al directori sites_available (això no és necessari però útil). En el primer cas, utilitzem el mòdul de còpia per copiar fitxers (el fitxer ha d'estar a /ansible/roles/nginx/files/nginx.conf). En el segon, copiem la plantilla, substituint els valors de les variables. La plantilla hauria d'estar dins /ansible/roles/nginx/templates/my_app.j2). I podria semblar una cosa així:

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

Preste atenció a les insercions {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — Aquestes són totes les variables els valors de les quals Ansible substituirà a la plantilla abans de copiar. Això és útil si utilitzeu un llibre de jocs per a diferents grups d'amfitrions. Per exemple, podem afegir el nostre fitxer d'inventari:

[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

Si ara iniciem el nostre llibre de jugades, realitzarà les tasques especificades per als dos amfitrions. Però al mateix temps, per a un amfitrió de posada en escena, les variables seran diferents de les de producció, i no només en rols i llibres de joc, sinó també en configuracions nginx. {{ inventory_hostname }} no cal que s'especifiquen al fitxer d'inventari, això variable ansible especial i s'emmagatzema allà l'amfitrió per al qual s'està executant el llibre de jocs.
Si voleu tenir un fitxer d'inventari per a diversos amfitrions, però només s'executa per a un grup, això es pot fer amb l'ordre següent:

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

Una altra opció és tenir fitxers d'inventari separats per a diferents grups. O podeu combinar els dos enfocaments si teniu molts amfitrions diferents.

Tornem a configurar nginx. Després de copiar els fitxers de configuració, hem de crear un enllaç simbòlic a sitetest_enabled a my_app.conf des de sites_available. I reinicieu 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

Aquí tot és senzill: de nou mòduls ansibles amb una sintaxi bastant estàndard. Però hi ha un punt. No té sentit reiniciar nginx cada vegada. T'has adonat que no escrivim ordres com: "fes això així", la sintaxi s'assembla més a "això hauria de tenir aquest estat". I sovint així és exactament com funciona ansible. Si el grup ja existeix, o el paquet del sistema ja està instal·lat, llavors ansible ho comprovarà i saltarà la tasca. A més, els fitxers no es copiaran si coincideixen completament amb el que ja hi ha al servidor. Podem aprofitar-ho i reiniciar nginx només si s'han canviat els fitxers de configuració. Hi ha una directiva de registre per a això:

# 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

Si canvia un dels fitxers de configuració, es farà una còpia i es registrarà la variable restart_nginx. I només si aquesta variable s'ha registrat, es reiniciarà el servei.

I, per descomptat, heu d'afegir el paper nginx al llibre de jocs principal.

Configuració de postgresql

Hem d'habilitar postgresql utilitzant systemd de la mateixa manera que ho vam fer amb nginx, i també crear un usuari que utilitzarem per accedir a la base de dades i a la base de dades.
Creem un paper /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 }}"

No descriuré com afegir variables a l'inventari, això ja s'ha fet moltes vegades, així com la sintaxi dels mòduls postgresql_db i postgresql_user. Podeu trobar més informació a la documentació. La directiva més interessant aquí és become_user: postgres. El fet és que, per defecte, només l'usuari de postgres té accés a la base de dades postgresql i només localment. Aquesta directiva ens permet executar ordres en nom d'aquest usuari (si tenim accés, és clar).
A més, potser haureu d'afegir una línia a pg_hba.conf per permetre l'accés d'un nou usuari a la base de dades. Això es pot fer de la mateixa manera que vam canviar la configuració de nginx.

I, per descomptat, heu d'afegir el rol postgresql al llibre de jocs principal.

Instal·lació de ruby ​​via rbenv

Ansible no té mòduls per treballar amb rbenv, però s'instal·la clonant un repositori git. Per tant, aquest problema es converteix en el més no estàndard. Anem a crear un paper per a ella /ansible/roles/ruby_rbenv/main.yml i comencem a omplir-lo:

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

Tornem a utilitzar la directiva become_user per treballar amb l'usuari que hem creat amb aquests propòsits. Com que rbenv està instal·lat al seu directori d'inici, i no globalment. I també fem servir el mòdul git per clonar el repositori, especificant repo i dest.

A continuació, hem de registrar rbenv init a bashrc i afegir-hi rbenv a PATH. Per a això tenim el mòdul 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 -)"'

Aleshores heu d'instal·lar ruby_build:

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

I finalment instal·leu Ruby. Això es fa mitjançant rbenv, és a dir, simplement amb l'ordre bash:

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

Diem quina comanda executar i amb què. Tanmateix, aquí ens trobem amb el fet que ansible no executa el codi contingut a bashrc abans d'executar les ordres. Això vol dir que rbenv s'haurà de definir directament en el mateix script.

El següent problema es deu al fet que l'ordre del shell no té cap estat des d'un punt de vista ansible. És a dir, no hi haurà cap verificació automàtica de si aquesta versió de Ruby està instal·lada o no. Això ho podem fer nosaltres mateixos:

- 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

Només queda instal·lar bundler:

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

I de nou, afegiu el nostre paper ruby_rbenv al llibre de jugades principal.

Fitxers compartits.

En general, la configuració es podria completar aquí. A continuació, només queda executar capistrano i copiarà el propi codi, crearà els directoris necessaris i llançarà l'aplicació (si tot està configurat correctament). Tanmateix, capistrano sovint requereix fitxers de configuració addicionals, com ara database.yml o .env Es poden copiar igual que fitxers i plantilles per a nginx. Només hi ha una subtilesa. Abans de copiar fitxers, heu de crear una estructura de directoris per a ells, una cosa així:

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

especifiquem només un directori i ansible en crearà automàticament els pares si cal.

Ansible Vault

Ja hem trobat el fet que les variables poden contenir dades secretes com la contrasenya de l'usuari. Si has creat .env fitxer de la sol·licitud, i database.yml llavors hi ha d'haver encara més dades tan crítiques. Seria bo amagar-los de mirades indiscretes. Amb aquesta finalitat s'utilitza volta ansible.

Creem un fitxer per a variables /ansible/vars/all.yml (aquí podeu crear diferents fitxers per a diferents grups d'amfitrions, igual que al fitxer d'inventari: production.yml, staging.yml, etc.).
Totes les variables que s'han de xifrar s'han de transferir a aquest fitxer utilitzant la sintaxi yml estàndard:

# 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

Després d'això, aquest fitxer es pot xifrar amb l'ordre:

ansible-vault encrypt ./vars/all.yml

Naturalment, en xifrar, haureu d'establir una contrasenya per al desxifrat. Podeu veure què hi haurà dins del fitxer després de cridar aquesta ordre.

Mitjançant ansible-vault decrypt el fitxer es pot desxifrar, modificar i tornar a xifrar.

No cal que desxifrau el fitxer per funcionar. L'emmagatzemeu xifrat i executeu el llibre de jocs amb l'argument --ask-vault-pass. Ansible demanarà la contrasenya, recuperarà les variables i executarà les tasques. Totes les dades romandran encriptades.

L'ordre completa per a diversos grups d'amfitrions i volta ansible tindrà un aspecte semblant a això:

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

Però no us donaré el text complet dels llibres de teatre i els papers, escriviu-lo vosaltres mateixos. Perquè ansible és així: si no enteneu el que s'ha de fer, no ho farà per vosaltres.

Font: www.habr.com

Afegeix comentari