ProHoster > Log > administrasjon > Sette opp en server for å distribuere en Rails-applikasjon ved hjelp av Ansible

Sette opp en server for å distribuere en Rails-applikasjon ved hjelp av Ansible

For ikke lenge siden trengte jeg å skrive flere Ansible-spillebøker for å forberede serveren for å distribuere en Rails-applikasjon. Og overraskende nok fant jeg ikke en enkel trinn-for-trinn-manual. Jeg ville ikke kopiere andres spillebok uten å forstå hva som skjedde, og til slutt måtte jeg lese dokumentasjonen og samle alt selv. Kanskje jeg kan hjelpe noen fremskynde denne prosessen ved hjelp av denne artikkelen.

Det første du må forstå er at ansible gir deg et praktisk grensesnitt for å utføre en forhåndsdefinert liste over handlinger på en ekstern server(e) via SSH. Det er ingen magi her, du kan ikke installere en plugin og få en null nedetidsdistribusjon av applikasjonen din med docker, overvåking og andre godbiter ut av esken. For å skrive en lekebok, må du vite nøyaktig hva du vil gjøre og hvordan du gjør det. Det er derfor jeg ikke er fornøyd med ferdige spillebøker fra GitHub, eller artikler som: "Kopier og kjør, det vil fungere."

Det vi trenger?

Som jeg allerede sa, for å skrive en lekebok må du vite hva du vil gjøre og hvordan du gjør det. La oss bestemme hva vi trenger. For en Rails-applikasjon trenger vi flere systempakker: nginx, postgresql (redis, etc). I tillegg trenger vi en spesifikk versjon av rubin. Det er best å installere det via rbenv (rvm, asdf...). Å kjøre alt dette som en root-bruker er alltid en dårlig idé, så du må opprette en egen bruker og konfigurere rettighetene hans. Etter dette må du laste opp koden vår til serveren, kopiere konfigurasjonene for nginx, postgres osv. og starte alle disse tjenestene.

Som et resultat er handlingssekvensen som følger:

  1. Logg inn som root
  2. installere systempakker
  3. opprette en ny bruker, konfigurere rettigheter, ssh-nøkkel
  4. konfigurer systempakker (nginx osv.) og kjør dem
  5. Vi oppretter en bruker i databasen (du kan umiddelbart opprette en database)
  6. Logg inn som ny bruker
  7. Installer rbenv og ruby
  8. Montering av bunter
  9. Laster opp applikasjonskoden
  10. Starter Puma-serveren

Dessuten kan de siste stadiene gjøres ved hjelp av capistrano, i det minste ut av esken kan den kopiere kode til utgivelseskataloger, bytte utgivelsen med en symbolkobling ved vellykket distribusjon, kopiere konfigurasjoner fra en delt katalog, starte puma på nytt, etc. Alt dette kan gjøres ved hjelp av Ansible, men hvorfor?

Filstruktur

Ansible har strenge filstruktur for alle filene dine, så det er best å ha alt i en egen katalog. Dessuten er det ikke så viktig om det vil være i selve skinneapplikasjonen, eller separat. Du kan lagre filer i et eget git-lager. Personlig fant jeg det mest praktisk å lage en mulig katalog i /config-katalogen til rails-applikasjonen og lagre alt i ett depot.

Enkel Playbook

Playbook er en yml-fil som ved hjelp av spesiell syntaks beskriver hva Ansible skal gjøre og hvordan. La oss lage den første lekeboken som ikke gjør noe:

---
- name: Simple playbook
  hosts: all

Her sier vi rett og slett at lekeboken vår heter Simple Playbook og at innholdet skal kjøres for alle verter. Vi kan lagre den i /ansible-katalogen med navnet playbook.yml og prøv å kjøre:

ansible-playbook ./playbook.yml

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

Ansible sier at den ikke kjenner noen verter som samsvarer med alle-listen. De må være oppført i en spesiell inventarfil.

La oss lage den i samme katalog:

123.123.123.123

Dette er hvordan vi ganske enkelt spesifiserer verten (ideelt sett verten til vår VPS for testing, eller du kan registrere lokalverten) og lagrer den under navnet inventory.
Du kan prøve å kjøre ansible med en inventarfil:

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

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

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

Hvis du har ssh-tilgang til den angitte verten, vil ansible koble til og samle inn informasjon om det eksterne systemet. (standard OPPGAVE [Gathing Facts]) hvoretter den vil gi en kort rapport om utførelsen (PLAY RECAP).

Som standard bruker tilkoblingen brukernavnet som du er logget inn på systemet under. Det vil mest sannsynlig ikke være på verten. I playbook-filen kan du spesifisere hvilken bruker som skal brukes for å koble til ved hjelp av remote_user-direktivet. Dessuten kan informasjon om et eksternt system ofte være unødvendig for deg, og du bør ikke kaste bort tid på å samle den. Denne oppgaven kan også deaktiveres:

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

Prøv å kjøre spilleboken igjen og kontroller at tilkoblingen fungerer. (Hvis du spesifiserte root-brukeren, må du også spesifisere bli: true-direktivet for å få forhøyede rettigheter. Som skrevet i dokumentasjonen: become set to ‘true’/’yes’ to activate privilege escalation. selv om det ikke er helt klart hvorfor).

Kanskje du vil motta en feil som skyldes at ansible ikke kan bestemme Python-tolken, så kan du spesifisere den manuelt:

ansible_python_interpreter: /usr/bin/python3

Du kan finne ut hvor du har python med kommandoen whereis python.

Installere systempakker

Ansibles standarddistribusjon inkluderer mange moduler for å jobbe med ulike systempakker, så vi trenger ikke å skrive bash-skript av noen grunn. Nå trenger vi en av disse modulene for å oppdatere systemet og installere systempakker. Jeg har Ubuntu Linux på min VPS, så for å installere pakker bruker jeg apt-get и modul for det. Hvis du bruker et annet operativsystem, kan det hende du trenger en annen modul (husk, jeg sa i begynnelsen at vi må vite på forhånd hva og hvordan vi skal gjøre). Syntaksen vil imidlertid mest sannsynlig være lik.

La oss supplere lekeboken vår med de første oppgavene:

---
- 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 er akkurat den oppgaven som Ansible skal utføre på eksterne servere. Vi gir oppgaven et navn slik at vi kan spore utførelsen i loggen. Og vi beskriver, ved å bruke syntaksen til en spesifikk modul, hva den må gjøre. I dette tilfellet apt: update_cache=yes - sier å oppdatere systempakker ved å bruke apt-modulen. Den andre kommandoen er litt mer komplisert. Vi sender en liste over pakker til apt-modulen og sier at de er det state bør bli present, det vil si, vi sier installer disse pakkene. På lignende måte kan vi be dem om å slette dem, eller oppdatere dem ved ganske enkelt å endre state. Vær oppmerksom på at for at rails skal fungere med postgresql, trenger vi postgresql-contrib-pakken, som vi installerer nå. Igjen, du må vite og gjøre dette; ansible på egen hånd vil ikke gjøre dette.

Prøv å kjøre playbook på nytt og sjekk at pakkene er installert.

Opprette nye brukere.

For å jobbe med brukere har Ansible også en modul – bruker. La oss legge til en oppgave til (jeg gjemte de allerede kjente delene av spilleboken bak kommentarene for ikke å kopiere den helt hver gang): 

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

Vi oppretter en ny bruker, setter et skjema og passord for den. Og så støter vi på flere problemer. Hva om brukernavn må være forskjellige for forskjellige verter? Og å lagre passordet i klartekst i spilleboken er en veldig dårlig idé. Til å begynne med legger vi brukernavnet og passordet inn i variabler, og mot slutten av artikkelen vil jeg vise hvordan du krypterer passordet.

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

Variabler er satt i playbooks med doble krøllete klammeparenteser.

Vi vil indikere verdiene til variablene i inventarfilen:

123.123.123.123

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

Vær oppmerksom på direktivet [all:vars] - det står at den neste tekstblokken er variabler (vars) og de gjelder for alle verter (alle).

Designet er også interessant "{{ user_password | password_hash('sha512') }}". Saken er at ansible ikke installerer brukeren via user_add som du ville gjort det manuelt. Og den lagrer alle data direkte, og derfor må vi også konvertere passordet til en hash på forhånd, noe som er det denne kommandoen gjør.

La oss legge til brukeren vår i sudo-gruppen. Men før dette må vi sørge for at en slik gruppe eksisterer fordi ingen vil gjøre dette for oss:

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

Alt er ganske enkelt, vi har også en gruppemodul for å lage grupper, med en syntaks som ligner veldig på apt. Da er det nok å registrere denne gruppen til brukeren (groups: "sudo").
Det er også nyttig å legge til en ssh-nøkkel til denne brukeren slik at vi kan logge inn med den uten passord:

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

I dette tilfellet er designet interessant "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — den kopierer innholdet i filen id_rsa.pub (navnet ditt kan være annerledes), det vil si den offentlige delen av ssh-nøkkelen og laster den opp til listen over autoriserte nøkler for brukeren på serveren.

rolle

Alle tre oppgavene for å skape bruk kan enkelt klassifiseres i én gruppe oppgaver, og det vil være lurt å lagre denne gruppen separat fra hovedspilleboken slik at den ikke vokser seg for stor. For dette formålet har Ansible roller.
I henhold til filstrukturen som er angitt helt i begynnelsen, må roller plasseres i en egen rollekatalog, for hver rolle er det en egen katalog med samme navn, inne i mappen for oppgaver, filer, maler osv.
La oss lage en filstruktur: ./ansible/roles/user/tasks/main.yml (main er hovedfilen som skal lastes og kjøres når en rolle kobles til spilleboken; andre rollefiler kan kobles til den). Nå kan du overføre alle oppgaver relatert til brukeren til denne filen:

# 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

I hovedspilleboken må du spesifisere for å bruke brukerrollen:

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

Det kan også være fornuftig å oppdatere systemet før alle andre oppgaver; for å gjøre dette kan du gi nytt navn til blokken tasks der de er definert i pre_tasks.

Sette opp nginx

Vi burde allerede ha Nginx installert; vi må konfigurere det og kjøre det. La oss gjøre det med en gang i rollen. La oss lage en filstruktur:

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

Nå trenger vi filer og maler. Forskjellen mellom dem er at ansible kopierer filene direkte, som den er. Og maler må ha j2-utvidelsen, og de kan bruke variabelverdier ved å bruke de samme doble krøllete klammeparentesene.

La oss aktivere nginx main.yml fil. For dette har vi en systemmodul:

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

Her sier vi ikke bare at nginx må startes (det vil si at vi lanserer det), men vi sier umiddelbart at det må være aktivert.
La oss nå kopiere konfigurasjonsfilene:

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

- name: Copy the nginx.conf
  copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    backup: yes

- name: Copy template my_app.conf
  template:
    src: my_app_conf.j2
    dest: /etc/nginx/sites-available/my_app.conf
    owner: root
    group: root
    mode: '0644'

Vi lager hovedkonfigurasjonsfilen for nginx (du kan ta den direkte fra serveren, eller skrive den selv). Og også konfigurasjonsfilen for applikasjonen vår i sites_available-katalogen (dette er ikke nødvendig, men nyttig). I det første tilfellet bruker vi kopimodulen til å kopiere filer (filen må være i /ansible/roles/nginx/files/nginx.conf). I den andre kopierer vi malen, og erstatter verdiene til variablene. Malen skal være i /ansible/roles/nginx/templates/my_app.j2). Og det kan se omtrent slik ut:

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

Vær oppmerksom på innsatsene {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} — dette er alle variablene hvis verdier Ansible vil erstatte i malen før kopiering. Dette er nyttig hvis du bruker en spillebok for forskjellige grupper av verter. For eksempel kan vi legge til inventarfilen vår:

[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

Hvis vi nå lanserer spilleboken vår, vil den utføre de angitte oppgavene for begge vertene. Men på samme tid, for en iscenesettelsesvert, vil variablene være forskjellige fra produksjonsvariablene, og ikke bare i roller og spillebøker, men også i nginx-konfigurasjoner. {{ inventory_hostname }} trenger ikke spesifiseres i inventarfilen - dette spesiell mulig variabel og verten som spilleboken kjører for er lagret der.
Hvis du vil ha en inventarfil for flere verter, men bare kjøre for én gruppe, kan dette gjøres med følgende kommando:

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

Et annet alternativ er å ha separate inventarfiler for forskjellige grupper. Eller du kan kombinere de to tilnærmingene hvis du har mange forskjellige verter.

La oss gå tilbake til å sette opp nginx. Etter å ha kopiert konfigurasjonsfilene, må vi opprette en symbolkobling i sitest_enabled til my_app.conf fra sites_available. Og start nginx på nytt.

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

Alt er enkelt her - igjen mulige moduler med en ganske standard syntaks. Men det er ett poeng. Det er ingen vits i å starte nginx på nytt hver gang. Har du lagt merke til at vi ikke skriver kommandoer som: "gjør dette slik", syntaksen ser mer ut som "dette skal ha denne tilstanden". Og oftest er det akkurat slik ansible fungerer. Hvis gruppen allerede eksisterer, eller systempakken allerede er installert, vil ansible se etter dette og hoppe over oppgaven. Filer vil heller ikke bli kopiert hvis de stemmer helt overens med det som allerede er på serveren. Vi kan dra nytte av dette og starte nginx på nytt bare hvis konfigurasjonsfilene er endret. Det er et registerdirektiv for dette:

# 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

Hvis en av konfigurasjonsfilene endres, vil det bli laget en kopi og variabelen vil bli registrert restart_nginx. Og bare hvis denne variabelen er registrert vil tjenesten startes på nytt.

Og selvfølgelig må du legge til nginx-rollen i hovedspilleboken.

Sette opp postgresql

Vi må aktivere postgresql ved å bruke systemd på samme måte som vi gjorde med nginx, og også opprette en bruker som vi skal bruke for å få tilgang til databasen og selve databasen.
La oss skape en rolle /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 }}"

Jeg vil ikke beskrive hvordan du legger til variabler til inventar, dette har allerede blitt gjort mange ganger, samt syntaksen til postgresql_db og postgresql_user-modulene. Mer informasjon finnes i dokumentasjonen. Det mest interessante direktivet her er become_user: postgres. Faktum er at som standard er det bare postgres-brukeren som har tilgang til postgresql-databasen og kun lokalt. Dette direktivet lar oss utføre kommandoer på vegne av denne brukeren (hvis vi har tilgang, selvfølgelig).
Det kan også hende du må legge til en linje i pg_hba.conf for å gi en ny bruker tilgang til databasen. Dette kan gjøres på samme måte som vi endret nginx-konfigurasjonen.

Og selvfølgelig må du legge til postgresql-rollen i hovedspilleboken.

Installere ruby ​​via rbenv

Ansible har ikke moduler for å jobbe med rbenv, men den installeres ved å klone et git-lager. Derfor blir dette problemet det mest ikke-standardiserte. La oss skape en rolle for henne /ansible/roles/ruby_rbenv/main.yml og la oss begynne å fylle det ut:

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

Vi bruker igjen bli_bruker-direktivet for å jobbe under brukeren vi opprettet for disse formålene. Siden rbenv er installert i hjemmekatalogen, og ikke globalt. Og vi bruker også git-modulen til å klone depotet, spesifisere repo og dest.

Deretter må vi registrere rbenv init i bashrc og legge til rbenv til PATH der. For dette har vi lineinfile-modulen:

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

Deretter må du installere ruby_build:

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

Og til slutt installere rubin. Dette gjøres gjennom rbenv, det vil si ganske enkelt med bash-kommandoen:

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

Vi sier hvilken kommando vi skal utføre og med hvilken. Men her kommer vi over det faktum at ansible ikke kjører koden i bashrc før du kjører kommandoene. Dette betyr at rbenv må defineres direkte i samme skript.

Det neste problemet skyldes det faktum at shell-kommandoen ikke har noen tilstand fra et ansible synspunkt. Det vil si at det ikke blir noen automatisk sjekk om denne versjonen av ruby ​​er installert eller ikke. Vi kan gjøre dette selv:

- 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

Alt som gjenstår er å installere bundler:

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

Og igjen, legg til rollen ruby_rbenv i hovedspilleboken.

Delte filer.

Generelt kan oppsettet fullføres her. Deretter gjenstår det bare å kjøre capistrano, og det vil kopiere selve koden, opprette de nødvendige katalogene og starte applikasjonen (hvis alt er riktig konfigurert). Capistrano krever imidlertid ofte ekstra konfigurasjonsfiler, som f.eks database.yml eller .env De kan kopieres akkurat som filer og maler for nginx. Det er bare en subtilitet. Før du kopierer filer, må du lage en katalogstruktur for dem, noe som dette:

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

vi spesifiserer kun én katalog og ansible vil automatisk opprette overordnede kataloger om nødvendig.

Ansible Vault

Vi har allerede kommet over det faktum at variabler kan inneholde hemmelige data som brukerens passord. Hvis du har opprettet .env fil for søknaden, og database.yml da må det være enda flere slike kritiske data. Det ville være greit å skjule dem for nysgjerrige øyne. Til dette formålet brukes den ansible hvelv.

La oss lage en fil for variabler /ansible/vars/all.yml (her kan du lage forskjellige filer for forskjellige grupper av verter, akkurat som i inventarfilen: production.yml, staging.yml, etc).
Alle variabler som må krypteres må overføres til denne filen ved å bruke standard yml-syntaks:

# 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

Deretter kan denne filen krypteres med kommandoen:

ansible-vault encrypt ./vars/all.yml

Når du krypterer, må du naturligvis angi et passord for dekryptering. Du kan se hva som vil være inne i filen etter å ha kalt denne kommandoen.

Ved hjelp av ansible-vault decrypt filen kan dekrypteres, endres og deretter krypteres igjen.

Du trenger ikke dekryptere filen for å fungere. Du lagrer den kryptert og kjører spilleboken med argumentet --ask-vault-pass. Ansible vil be om passordet, hente variablene og utføre oppgavene. Alle data vil forbli kryptert.

Den komplette kommandoen for flere grupper av verter og mulig hvelv vil se omtrent slik ut:

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

Men jeg vil ikke gi deg hele teksten til lekebøker og roller, skriv det selv. Fordi ansible er slik - hvis du ikke forstår hva som må gjøres, vil det ikke gjøre det for deg.

Kilde: www.habr.com

Legg til en kommentar