Поставување сервер за распоредување на апликацијата Rails со помош на Ansible

Неодамна ми требаше да напишам неколку Ansible Playbook за да го подготвам серверот за распоредување на апликацијата Rails. И, изненадувачки, не најдов едноставен прирачник чекор-по-чекор. Не сакав да копирам туѓа книга без да разберам што се случува, и на крајот морав да ја прочитам документацијата, собирајќи сè сам. Можеби можам да помогнам некому да го забрза овој процес со помош на оваа статија.

Првото нешто што треба да се разбере е дека ansible ви обезбедува удобен интерфејс за извршување на претходно дефинирана листа на дејства на оддалечен сервер(и) преку SSH. Нема магија овде, не можете да инсталирате приклучок и да добиете нула прекин на распоредување на вашата апликација со докер, мониторинг и други добрини надвор од кутијата. За да напишете книга за игри, мора да знаете што точно сакате да правите и како да го направите тоа. Затоа не сум задоволен со готови книги за играње од GitHub или написи како: „Копирај и стартувај, ќе работи“.

Што ни треба?

Како што веќе реков, за да напишете книга за игри треба да знаете што сакате да правите и како да го направите тоа. Ајде да одлучиме што ни треба. За апликација на Rails ќе ни требаат неколку системски пакети: nginx, postgresql (redis, итн.). Покрај тоа, ни треба специфична верзија на рубин. Најдобро е да го инсталирате преку rbenv (rvm, asdf...). Извршувањето на сето ова како root корисник е секогаш лоша идеја, па затоа треба да креирате посебен корисник и да ги конфигурирате неговите права. После ова, треба да го поставите нашиот код на серверот, да ги копирате конфигурациите за nginx, postgres итн и да ги стартувате сите овие услуги.

Како резултат на тоа, редоследот на дејствата е како што следува:

1. Најавете се како root
2. инсталирајте системски пакети
3. креирајте нов корисник, конфигурирајте права, клуч ssh
4. конфигурирајте системски пакети (nginx итн) и стартувајте ги
5. Ние создаваме корисник во базата на податоци (можете веднаш да креирате база на податоци)
6. Најавете се како нов корисник
7. Инсталирајте rbenv и рубин
8. Инсталирање на пакетот
9. Поставување на кодот на апликацијата
10. Стартување на серверот Puma

Покрај тоа, последните фази може да се направат со користење на capistrano, барем надвор од кутијата може да го копира кодот во директориумите за издавање, да го префрли изданието со символик по успешното распоредување, да копира конфигурации од споделен директориум, да ја рестартира puma итн. Сето ова може да се направи со помош на Ansible, но зошто?

Структура на датотека

Ansible има строги структура на датотека за сите ваши датотеки, па затоа е најдобро да се чува сето тоа во посебен директориум. Покрај тоа, не е толку важно дали ќе биде во самата апликација за шини или одделно. Можете да складирате датотеки во посебно складиште за git. Лично, најпогодно ми беше да создадам ансибилен директориум во директориумот /config на апликацијата rails и да складирам сè во едно складиште.

Едноставна Playbook

Playbook е yml-датотека која, користејќи специјална синтакса, опишува што треба да прави Ansible и како. Ајде да ја создадеме првата книга за игри што не прави ништо:

---
- name: Simple playbook
  hosts: all

Овде едноставно велиме дека нашата игротека се вика Simple Playbook и дека неговата содржина треба да биде извршена за сите хостови. Можеме да го зачуваме во директориумот /ansible со името playbook.yml и обидете се да трчате:

ansible-playbook ./playbook.yml

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

Ansible вели дека не познава домаќини што одговараат на сите список. Тие мора да бидат наведени во посебен инвентар датотека.

Ајде да го создадеме во истиот директориум:

123.123.123.123

Вака едноставно го одредуваме домаќинот (идеално домаќинот на нашиот VPS за тестирање, или можете да регистрирате localhost) и го зачувуваме под името inventory.
Може да се обидете да извршите ansible со датотека со запис:

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

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

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

Ако имате ssh пристап до наведениот хост, тогаш ansible ќе се поврзе и собира информации за далечинскиот систем. (стандардна ЗАДАЧА [Собирање факти]) по што ќе даде краток извештај за извршувањето (PLAY RECAP).

Стандардно, врската го користи корисничкото име под кое сте најавени на системот. Најверојатно нема да биде на домаќинот. Во датотеката Playbook, можете да одредите кој корисник да се користи за поврзување користејќи ја директивата remote_user. Исто така, информациите за далечинскиот систем честопати може да ви бидат непотребни и не треба да губите време собирајќи ги. Оваа задача исто така може да се оневозможи:

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

Обидете се повторно да ја стартувате Playbook и проверете дали врската работи. (Ако сте го навеле root корисникот, тогаш треба да ја наведете и директивата стане: вистинска за да стекнете зголемени права. Како што е напишано во документацијата: become set to ‘true’/’yes’ to activate privilege escalation. иако не е сосема јасно зошто).

Можеби ќе добиете грешка предизвикана од фактот дека ansible не може да го одреди толкувачот на Python, тогаш можете рачно да го наведете:

ansible_python_interpreter: /usr/bin/python3 

Можете да дознаете каде имате python со командата whereis python.

Инсталирање системски пакети

Стандардната дистрибуција на Ansible вклучува многу модули за работа со различни системски пакети, така што не мора да пишуваме баш скрипти од која било причина. Сега ни треба еден од овие модули за да го ажурираме системот и да инсталираме системски пакети. Имам Ubuntu Linux на мојот VPS, па за да инсталирам пакети користам apt-get и модул за тоа. Ако користите различен оперативен систем, тогаш можеби ќе ви треба друг модул (запомнете, на почетокот реков дека треба однапред да знаеме што и како ќе правиме). Сепак, синтаксата најверојатно ќе биде слична.

Ајде да ја дополниме нашата игротека со првите задачи:

---
- 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 е токму задачата што Ansible ќе ја изврши на оддалечените сервери. На задачата и даваме име за да можеме да го следиме нејзиното извршување во дневникот. И ние опишуваме, користејќи ја синтаксата на одреден модул, што треба да направи. Во овој случај apt: update_cache=yes - вели за ажурирање на системските пакети користејќи го модулот apt. Втората команда е малку покомплицирана. Додаваме листа на пакети на apt модулот и велиме дека се state треба да стане present, односно велиме да ги инсталираме овие пакети. На сличен начин, можеме да им кажеме да ги избришат или да ги ажурираме со едноставно менување state. Ве молиме имајте предвид дека за шините да работат со postgresql ни треба пакетот postgresql-contrib, кој го инсталираме сега. Повторно, треба да го знаете и да го направите ова; разумниот сам по себе нема да го стори тоа.

Обидете се повторно да ја стартувате Playbook и проверете дали пакетите се инсталирани.

Создавање нови корисници.

За работа со корисници, Ansible има и модул - корисник. Ајде да додадеме уште една задача (позади коментарите ги скрив веќе познатите делови од книгата за да не ја копирам целосно секој пат):

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

Ние создаваме нов корисник, поставуваме шема и лозинка за него. И тогаш наидуваме на неколку проблеми. Што ако корисничките имиња треба да бидат различни за различни хостови? И складирањето на лозинката во јасен текст во книгата за игри е многу лоша идеја. За почеток, ајде да ги ставиме корисничкото име и лозинката во променливи, а кон крајот на статијата ќе покажам како се шифрира лозинката.

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

Променливите се поставени во книгите за игри со помош на двојни кадрави загради.

Ќе ги означиме вредностите на променливите во датотеката со залихи:

123.123.123.123

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

Обрнете внимание на директивата [all:vars] - вели дека следниот блок текст се променливи (vars) и тие се применливи за сите хостови (сите).

Интересен е и дизајнот "{{ user_password | password_hash('sha512') }}". Работата е што ansible не го инсталира корисникот преку user_add како што би го направиле тоа рачно. И директно ги зачувува сите податоци, поради што мораме однапред да ја претвориме лозинката во хаш, што го прави оваа команда.

Ајде да го додадеме нашиот корисник во групата sudo. Сепак, пред ова треба да се увериме дека постои таква група бидејќи никој нема да го направи ова за нас:

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

Сè е прилично едноставно, имаме и групен модул за креирање групи, со синтакса многу слична на apt. Тогаш доволно е да ја регистрирате оваа група на корисникот (groups: "sudo").
Исто така, корисно е да додадете ssh клуч на овој корисник за да можеме да се најавиме користејќи го без лозинка:

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

Во овој случај, дизајнот е интересен "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" — ја копира содржината на датотеката id_rsa.pub (вашето име може да е различно), односно јавниот дел од клучот ssh и го прикачува на списокот со овластени клучеви за корисникот на серверот.

Улоги

Сите три задачи за креирање употреба може лесно да се класифицираат во една група задачи и би било добра идеја оваа група да се складира одделно од главната книга за да не расте премногу. За таа цел, Ansible има улоги.
Според структурата на датотеката наведена на самиот почеток, улогите мора да бидат сместени во посебен директориум со улоги, за секоја улога има посебен директориум со исто име, во директориумот задачи, датотеки, шаблони итн.
Ајде да создадеме структура на датотека: ./ansible/roles/user/tasks/main.yml (главна е главната датотека што ќе се вчита и ќе се изврши кога некоја улога е поврзана со книгата за игри; со неа може да се поврзат и други датотеки со улоги). Сега можете да ги префрлите сите задачи поврзани со корисникот во оваа датотека:

# 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

Во главната книга, мора да наведете да ја користите улогата на корисникот:

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

Исто така, може да има смисла да се ажурира системот пред сите други задачи; за да го направите ова, можете да го преименувате блокот tasks во кој се дефинирани во pre_tasks.

Поставување на nginx

Веќе треба да имаме инсталирано Nginx; треба да го конфигурираме и да го извршиме. Ајде да го направиме тоа веднаш во улогата. Ајде да создадеме структура на датотека:

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

Сега ни требаат датотеки и шаблони. Разликата меѓу нив е што ansible директно ги копира датотеките, како што е. И шаблоните мора да имаат наставка j2 и тие можат да користат променливи вредности користејќи ги истите двојни кадрави загради.

Ајде да го овозможиме nginx во main.yml датотека. За ова имаме системски модул:

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

Овде не само што велиме дека nginx мора да се стартува (т.е. го лансираме), туку веднаш велиме дека мора да биде овозможен.
Сега ајде да ги копираме конфигурациските датотеки:

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

Ние ја креираме главната конфигурациска датотека nginx (можете да ја земете директно од серверот или да ја напишете сами). И, исто така, конфигурациската датотека за нашата апликација во директориумот sites_available (ова не е неопходно, но корисно). Во првиот случај, ние го користиме модулот за копирање за копирање датотеки (датотеката мора да биде внатре /ansible/roles/nginx/files/nginx.conf). Во втората, го копираме шаблонот, заменувајќи ги вредностите на променливите. Шаблонот треба да биде внатре /ansible/roles/nginx/templates/my_app.j2). И може да изгледа вака:

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

Обрнете внимание на влошките {{ app_name }}, {{ app_path }}, {{ server_name }}, {{ inventory_hostname }} - ова се сите променливи чии вредности Ansible ќе ги замени во шаблонот пред да ги копира. Ова е корисно ако користите книга за игри за различни групи на домаќини. На пример, можеме да ја додадеме нашата датотека со инвентар:

[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

Ако сега ја стартуваме нашата книга за игри, таа ќе ги изврши наведените задачи за двата домаќини. Но, во исто време, за домаќин на сцена, променливите ќе се разликуваат од продукциските, и не само во улоги и книги, туку и во конфигурации на nginx. {{ inventory_hostname }} не треба да се специфицира во датотеката со залихи - ова специјална ансибилна променлива и таму е зачуван домаќинот за кој моментално работи Playbook.
Ако сакате да имате инвентар датотека за неколку хостови, но да работи само за една група, ова може да се направи со следнава команда:

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

Друга опција е да имате посебни датотеки со залихи за различни групи. Или можете да ги комбинирате двата пристапа ако имате многу различни домаќини.

Да се ​​вратиме на поставувањето на nginx. По копирањето на конфигурациските датотеки, треба да создадеме симврска во sitest_enabled до my_app.conf од sites_available. И рестартирајте го 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

Овде сè е едноставно - повторно достапни модули со прилично стандардна синтакса. Но, има една точка. Нема смисла да се рестартира nginx секој пат. Дали забележавте дека не пишуваме команди како: „направи го вака“, синтаксата повеќе изгледа како „ова треба да ја има оваа состојба“. И најчесто вака функционира ansible. Ако групата веќе постои или системскиот пакет е веќе инсталиран, тогаш ansible ќе го провери ова и ќе ја прескокне задачата. Исто така, датотеките нема да се копираат ако целосно се совпаѓаат со она што е веќе на серверот. Можеме да го искористиме ова и да го рестартираме nginx само ако конфигурациските датотеки се сменети. Постои директива за регистар за ова:

# 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

Ако се промени една од конфигурациските датотеки, ќе се направи копија и променливата ќе биде регистрирана restart_nginx. И само ако оваа променлива е регистрирана, услугата ќе се рестартира.

И, се разбира, треба да ја додадете улогата nginx во главната книга.

Поставување postgresql

Треба да го овозможиме postgresql користејќи systemd на ист начин како што направивме со nginx, а исто така да создадеме корисник што ќе го користиме за пристап до базата на податоци и самата база на податоци.
Ајде да создадеме улога /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 }}"

Нема да опишам како да додавам променливи на залихите, ова е веќе направено многу пати, како и синтаксата на модулите postgresql_db и postgresql_user. Повеќе информации може да најдете во документацијата. Овде е најинтересната директива become_user: postgres. Факт е дека стандардно, само корисникот на postgres има пристап до базата на податоци postgresql и само локално. Оваа директива ни овозможува да извршуваме команди во име на овој корисник (ако имаме пристап, се разбира).
Исто така, можеби ќе треба да додадете линија на pg_hba.conf за да дозволите пристап на нов корисник до базата на податоци. Ова може да се направи на ист начин како што ја сменивме конфигурацијата nginx.

И, се разбира, треба да ја додадете улогата postgresql во главната книга за игри.

Инсталирање на рубин преку rbenv

Ansible нема модули за работа со rbenv, но се инсталира со клонирање на git складиште. Затоа, овој проблем станува најнестандарден. Ајде да создадеме улога за неа /ansible/roles/ruby_rbenv/main.yml и да почнеме да го пополнуваме:

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

Повторно ја користиме директивата ben_user за да работиме под корисникот што го создадовме за овие цели. Бидејќи rbenv е инсталиран во неговиот домашен директориум, а не глобално. И ние исто така го користиме модулот git за клонирање на складиштето, наведувајќи repo и dest.

Следно, треба да го регистрираме rbenv init во bashrc и да додадеме rbenv на PATH таму. За ова го имаме модулот 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 -)"'

Потоа треба да инсталирате ruby_build:

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

И конечно инсталирај рубин. Ова се прави преку rbenv, односно едноставно со командата 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

Кажуваме која команда да ја извршиме и со што. Меѓутоа, овде се среќаваме со фактот дека ansible не го извршува кодот содржан во bashrc пред да ги изврши командите. Ова значи дека rbenv ќе треба да се дефинира директно во истата скрипта.

Следниот проблем се должи на фактот што командата на школка нема состојба од разбирлива гледна точка. Тоа е, нема да има автоматска проверка дали оваа верзија на рубин е инсталирана или не. Ние можеме сами да го направиме ова:

- 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

Останува само да се инсталира пакет:

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

И повторно, додајте ја нашата улога ruby_rbenv во главната книга.

Споделени датотеки.

Во принцип, поставувањето може да се заврши овде. Следно, останува само да се изврши capistrano и тој самиот ќе го копира кодот, ќе ги создаде потребните директориуми и ќе ја стартува апликацијата (ако сè е правилно конфигурирано). Сепак, capistrano често бара дополнителни конфигурациски датотеки, како на пр database.yml или .env Тие можат да се копираат исто како датотеките и шаблоните за nginx. Има само една суптилност. Пред да копирате датотеки, треба да креирате структура на директориуми за нив, нешто како ова:

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

ние назначуваме само еден директориум и ansible автоматски ќе креира родител доколку е потребно.

Ansible свод

Веќе наидовме на фактот дека променливите можат да содржат тајни податоци како што е лозинката на корисникот. Ако сте создале .env датотека за апликацијата, и database.yml тогаш мора да има уште повеќе вакви критични податоци. Би било добро да ги скриете од љубопитните очи. За таа цел се користи ансибилен свод.

Ајде да создадеме датотека за променливи /ansible/vars/all.yml (Тука можете да креирате различни датотеки за различни групи на хостови, исто како во датотеката со инвентар: production.yml, staging.yml, итн.).
Сите променливи што мора да се шифрираат мора да се пренесат во оваа датотека користејќи стандардна 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

После тоа оваа датотека може да се шифрира со командата:

ansible-vault encrypt ./vars/all.yml

Природно, при шифрирање, ќе треба да поставите лозинка за дешифрирање. Можете да видите што ќе има во датотеката откако ќе ја повикате оваа команда.

Со помош на ansible-vault decrypt датотеката може да се дешифрира, модифицира и потоа повторно да се шифрира.

Не треба да ја дешифрирате датотеката за да работи. Го складирате шифрирано и ја стартувате Playbook со аргументот --ask-vault-pass. Ansible ќе побара лозинка, ќе ги врати променливите и ќе ги изврши задачите. Сите податоци ќе останат шифрирани.

Целосната команда за неколку групи на домаќини и ansible vault ќе изгледа вака:

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

Но, нема да ви го дадам целосниот текст на играчките и улогите, напишете го сами. Бидејќи ansible е таков - ако не разбирате што треба да се направи, тогаш тоа нема да го направи тоа за вас.

Извор: www.habr.com