Укажите пароль sudo для ansible

Настройка системы

В данном разделе мы рассмотрим процессы, которые больше подходят для категории настройки системы. 

1. Добавить задание в cron.

Выполняется с помощью модуля cron:

— name: Add Job for Run Command
  cron:
    name: Start Script
    job: «/scripts/command.sh»
    user: root
    minute: «0»
    hour: «*/6»
    day: «*»
    month: «*»
    weekday: «*»

* в данном примере мы создадим задание для запуска команды /scripts/command.sh каждый день, каждые 6 часов.

О cron: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/cron_module.html.

2. Добавить публичный ключ хоста в known_hosts.

Делается с помощью known_hosts. Пример из официальной документации:

— name: Tell the host about our servers it might want to ssh to
  known_hosts:
    path: /etc/ssh/ssh_known_hosts
    name: foo.com.invalid
    key: «{{ lookup(‘file’, ‘pubkeys/foo.com.invalid’) }}»

* в данном примере мы добавим ключ из файла pubkeys/foo.com.invalid в /etc/ssh/ssh_known_hosts.

О known_hosts: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/known_hosts_module.html.

3. Создание новых SSH-ключей для сервера.

Создание ключей реализуется с помощью модуля openssh_keypair:

— name: Generate New SSH Host Keys
  openssh_keypair:
    path: «/etc/ssh/ssh_host_` item`.`type `_key»
    owner: root
    state: present
    type: «` item`.`type `»
    size: «` item`.`size `»
    force: yes
  loop:
    — { type: dsa, size: 1024 }
    — { type: ecdsa, size: 521 }
    — { type: ed25519, size: 2048 }
    — { type: rsa, size: 2048 }

* в данном примере мы создадим 4 ключа разных типов: dsa, ecdsa, ed25519, rsa. Так как у каждого из них свои требования к размеру, перечень представлен в виде двумерного массива. Ключи будут созданы в каталоге /etc/ssh/.

О openssh_keypair: https://docs.ansible.com/ansible/latest/collections/community/crypto/openssh_keypair_module.html.

4. Работа с SSH authorized_key.

Данный файл содержит публичный ключ для подключения по SSH. Работа с ним через Ansible выполняется с помощью модуля authorized_key.

Пример добавления ключа:

— name: Set authorized key took from file
  authorized_key:
    user: root
    state: present
    key: ‘` item `’
  with_file:
    — files/key.pub

* в данном примере мы берем содержимое файла files/key.pub и устанавливаем его для пользователя root.

Об authorized_key: https://docs.ansible.com/ansible/2.4/authorized_key_module.html.

5. Создание системной учетной записи.

Для этого есть модуль user. У него много опций, но для создания системной учетной записи нам достаточно:

— name: Create User Consul
  user:
    name: consul
    system: yes
    comment: «Consul Agent»

* в данном примере будет создана учетная запись consul.

О user: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html.

6. Работа с systemd.

Для данной настройки есть одноименный модуль systemd. Рассмотрим варианты его использования.

а) перечитать конфигурацию (необходимо делать каждый раз, когда мы меняем настройки юнита):

— name: systemd reload
  systemd:
    daemon_reload: yes

б) разрешить сервис (автозапуск):

— name: mysql enable
  systemd:
    name: mysql
    enabled: yes

* для сервиса mysql.

в) перезапустить сервис:

— name: mysql reload
  systemd:
    name: mysql
    state: restarted

* для сервиса mysql.

О systemd: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/systemd_module.html.

7. Настройка брандмауэра.

Выполняется разными модулями в зависимости от используемой системы управления netfilter:

• firewalld
• iptables
• ufw

Рассмотрим небольшие примеры.

а) firewalld:

— name: permit traffic in default zone for https service
  firewalld:
    service: https
    permanent: yes
    state: enabled

Подробнее: https://docs.ansible.com/ansible/latest/collections/ansible/posix/firewalld_module.html.

б) iptables:

— name: Block specific IP
  iptables:
    chain: INPUT
    source: 8.8.8.8
    jump: DROP

Подробнее: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/iptables_module.html.

в) UFW.

Добавить 80 порт:

— name: Allow all access to tcp port 80
  ufw:
    rule: allow
    port: ’80’
    proto: tcp

Добавить порты с циклом:

— name: Allow Ports in Firewall
  ufw:
    rule: allow
    port: «` item`.`port `»
    proto: «` item`.`proto `»
    comment: «` item`.`comment `»
  loop:
    — { port: 5432, proto: tcp, comment: ‘PostgreSQL’ }

Подробнее: https://docs.ansible.com/ansible/latest/collections/community/general/ufw_module.html.

Allow passwordless sudo

Telling ansible ask for the password has the security advantage that only people who know what is the password can execute code
but it can be a bit inconvenient on the long run.

Instead we can configure the the remote user we use to be able to execute all, or certain commands using sudo even without supplying a password. In this case we need to protect the user account of the manager machine that has its public ssh-key installed on the remote server. Anyone who can access this machine would be able to control the remote servers.

Who can run sudo command, what are theses command and whether password is required is controlled in the /etc/suduers file. It can be edited manually using the visudo command or we can ask Ansible to edit it. You can also edit the file with any editor, but if you save an incorrectly formatted version, you can easily lock yourself out from user root. Hence it is strongly recommended that you use the visudo command that will validate the syntax of the file before you save it.

Manually editing the sudoers

ssh to the remote server.

$ ssh foo@192.168.56.11

On the remote server run:

$ sudo visudo

It will ask for your password and then open the default editor which happens to be nano these days.
The default version of file looks like this:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

We need to edit the line

%sudo   ALL=(ALL:ALL) ALL

and look like this:

%sudo  ALL=(ALL:ALL) NOPASSWD: ALL

We can save the file and exit.

In order to verify that it works properly log out from the server (e.g. type exit or press Ctrl-d.
Then ssh to the server again and run

sudo grep root /etc/shadow

We needed to logout and login again for the verification because normally even if sudo requires a password it retains the access rights for a few minutes or until you log out. So we wanted to make sure we can use sudo because of the change in the sudoers file and not because of this grace period.

We can now log out again and on the management machine run the ansible command again with -b but without -K

$ ansible -i inventory.cfg all -a "grep ^root: /etc/shadow"  -b

The result looks promising:

192.168.56.12 | FAILED! => {
    "changed": false,
    "module_stderr": "Shared connection to 192.168.56.12 closed.\r\n",
    "module_stdout": "sudo: a password is required\r\n",
    "msg": "MODULE FAILURE",
    "rc": 1
}
192.168.56.11 | SUCCESS | rc=0 >>
root:!:17596:0:99999:7:::

One machine where we changed the sudoers file worked as expected, the other one without the passwordless access
failed as expected.

(We could use the -K and then it would ask for a password again, but instead of that we’d like to allow passwordless
sudo commands on the other machine as well.

Запуск плейбука с зашифрованными данными

Каждый раз, когда вы запускаете плейбук, в котором используются данные, ранее зашифрованные с помощью ansible-vault, вам нужно будет указывать пароль хранилища в команде playbook.

Если вы использовали параметры по умолчанию и prompt  при шифровании данных плейбука, вы можете использовать опцию –ask-vault-pass, чтобы Ansible запрашивал пароль:

Если вы использовали файл пароля вместо prompt, вы должны использовать опцию –vault-password-file:

Если вы используете данные, зашифрованные с помощью ID, вам нужно указать тот же ID хранилища и источник пароля, который вы использовали при первом шифровании данных:

Если вы используете файл пароля с ID, вы должны указать метку, а затем полный путь к файлу пароля в качестве источника:

Если ваш play использует несколько хранилищ, вы должны добавить параметр –vault-id для каждого из них в произвольном порядке:

Пользовательский файл инвентаря

Файл инвентаря по умолчанию обычно находится в /etc/ansible/hosts, но вы можете использовать опцию -i для указания пользовательских файлов при запуске команд и плейбуков Ansible. Это удобный способ настройки индивидуального инвентаря для каждого проекта, который можно включить в системы контроля версий, такие как Git:

Такая опция действительна и для ansible-playbook:

Динамический файл инвентаря

Ansible поддерживает сценарии инвентаризации для создания динамических файлов. Это полезно, если ваш инвентарь часто меняется, когда серверы создаются и уничтожаются.

Вы можете найти ряд скриптов с открытым исходным кодом в официальном репозитории Ansible GitHub. После загрузки требуемого сценария на Ansible control machine и настройки необходимых параметров (например, учетных данных API) вы можете запустить исполняемый файл в качестве пользовательского инвентаря с любой командой Ansible, которая поддерживает эту опцию.

Следующая команда использует скрипт инвентаря my_inventory.py с командой ping для проверки подключения ко всем текущим активным серверам:

За более подробной информацией о том, как использовать динамические файлы инвентаризации, пожалуйста, обратитесь к официальной документации Ansible.

Ansible playbook to set passwordless sudo

This is the set_sudoer.yml file.

---
- hosts: all
  tasks:
    - lineinfile:
        path: /etc/sudoers
        state: present
        regexp: '^%sudo'
        line: '%sudo ALL=(ALL) NOPASSWD: ALL'
        validate: 'visudo -cf %s'

It says: work on the file in the given path.
Replace the line matched by regexp with the string in line.
Before saving the file run the validate command to verify that format is correct.

It will match the following line:

%sudo   ALL=(ALL:ALL) ALL

and replace it with this line:

%sudo  ALL=(ALL:ALL) NOPASSWD: ALL

We can run this with the following command:

$ ansible-playbook -i inventory.cfg --limit 192.168.56.12 set_sudoer.yml -b -K

• We only run it on the selected host.
• We provide the -b as we need to become root for this operation.
• We also supply -K because sudo still requires password.

The output looks like this:

SUDO password:

PLAY  ****************************************************************************************************************************

TASK  ****************************************************************************************************************
ok: 

TASK  *********************************************************************************************************************
changed: 

PLAY RECAP ****************************************************************************************************************************
192.168.56.12              : ok=2    changed=1    unreachable=0    failed=0

Once this is done, we can run the previous command without providing a password and it will run on both servers:

$ ansible -i inventory.cfg all -a "grep ^root: /etc/shadow"  -b

192.168.56.12 | SUCCESS | rc=0 >>
root:!:17596:0:99999:7:::

192.168.56.11 | SUCCESS | rc=0 >>
root:!:17596:0:99999:7:::

Запуск плейбука с зашифрованными данными

Каждый раз, когда вы запускаете плейбук, в котором используются данные, ранее зашифрованные с помощью ansible-vault, вам нужно будет указывать пароль хранилища в команде playbook.

Если вы использовали параметры по умолчанию и prompt  при шифровании данных плейбука, вы можете использовать опцию –ask-vault-pass, чтобы Ansible запрашивал пароль:

Если вы использовали файл пароля вместо prompt, вы должны использовать опцию –vault-password-file:

Если вы используете данные, зашифрованные с помощью ID, вам нужно указать тот же ID хранилища и источник пароля, который вы использовали при первом шифровании данных:

Если вы используете файл пароля с ID, вы должны указать метку, а затем полный путь к файлу пароля в качестве источника:

Если ваш play использует несколько хранилищ, вы должны добавить параметр –vault-id для каждого из них в произвольном порядке:

Шаг 2. Установите Docker и Docker Compose

AWX поддерживается и может запускаться только как контейнерное приложение с использованием образов Docker, развернутых в кластере OpenShift, кластере Kubernetes или docker-compose. В этом руководстве мы будем использовать Docker, чтобы запустить AWX.

Сначала загрузите файл репозитория Docker в /etc/yum.repos.d/docker-ce.repo и обновите кеш индекса RPM перед установкой Docker.

Запустите и включите Docker Service для запуска при загрузке и проверьте, работает ли он

Группа докеров создана, но в нее не добавляются пользователи. Добавьте своего пользователя в эту группу, чтобы запускать команды докеров без sudo.

Узнайте больше об установке Docker и Docker Compose в руководстве CentOS 8, чтобы установить Docker и docker-compose на ваш сервер Cent0S 8.

Затем мы будем использовать команду pip3, чтобы установить модуль docker-compose и docker python, как показано ниже.

Подтвердите установленную версию..

Использование ключа

Ввод пароля для подключения через SSH — раздражающая процедура. У меня почти никогда не получалось ввести его правильно с первого раза. Поэтому я начал искать информацию о том, как подключиться к серверу через SSH без пароля. Простое и безопасное решение — использование ключа. Почему это безопаснее? Потому что пароль можно подобрать. Чтобы исключить такую вероятность, многие пользователи выбирают авторизацию с помощью ключа. 

Суть процедуры в формировании двух ключей: публичного и приватного. Первый копируется на сервер, а второй остается на компьютере пользователя и не передается по сети. В таком случае пароль при подключении не требуется. Когда вы подключаетесь к серверу через SSH, публичный ключ взаимодействует с приватным и открывает доступ к удаленному управлению.

Генерирование ключа и подключение на Windows

Для удобства используем программу PuTTy. Вместе с ней устанавливается утилита PuTTYgen — в ней можно сгенерировать публичный и приватный ключи.

1. Запустите программу PuTTYgen.
2. Нажмите на кнопку Gengerate.
3. Водите курсором мышки по рабочему столу, чтобы сгенерировать случайные значения ключей.
4. Нажмите на кнопку Save private key, чтобы сохранить на жестком диске приватный ключ. Место хранения может быть любым — его нужно указать в параметрах PuTTY. Сделаем это позже. 
5. Скопируйте публичный ключ в буфер обмена (Ctrl + C) и закройте генератор ключей.

Теперь нужно перенести публичный ключ на сервер. Запустите программу PuTTY и подключитесь к серверу с помощью пароля. Затем последовательно введите следующие команды:

mkdir ~/.ssh

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys

Эти команды создают на сервере папку и файл для хранения ключей, а также ограничивают к ним доступ — получить его может только владелец.

Следующий шаг — вставка публичного ключа из буфера обмена в файл authorized_keys. Для этого используется команда cat > .ssh/authorized_keys. После ввода команды щелкните по окну терминала правой кнопкой, чтобы вставить скопированный ранее публичный ключ. Для завершения ввода нажмите на сочетание клавиш Ctrl+D.

Вернитесь в настройки PuTTY. Перейдите в раздел Connection — SSH — Auth. Нажмите на кнопку Browse и укажите путь к приватному ключу, который вы ранее сохранили на жестком диске.

Теперь для подключения к серверу через SSH пароль не нужен — достаточно указать логин и IP-адрес сервера.

Генерирование ключа и подключение на Linux и macOS

Теперь посмотрим, как подключиться через SSH ключи на Linux и macOS. 

1. Запустите терминал на локальном компьютере.
2. Выполните команду ssh-keygen, чтобы сгенерировать ключи.
3. Нажмите на Enter, чтобы сохранить ключи.

Генератор предложит также задать кодовую фразу для ключа. Это дополнительная мера безопасности: если кто-то получит доступ к вашей локальной машине, то все равно не сможет подключиться к серверу через SSH. Минус один — вам тоже придется постоянно вводить ключевую фразу. Можно отказаться от этой меры защиты, просто нажав на клавишу Enter. 

На этом процедура создания ключей завершена. Файлы d_rsa (приватный ключ) и id_rsa.pub (публичный ключ) хранятся в папке ~/.ssh/.  Осталось скопировать открытую часть ключа на сервер.

1. Вернитесь в терминал.
2. Выполните команду ssh-copy-id root@185.104.114.90, где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.

После выполнения этой команды публичный ключ будет скопирован на сервер. Теперь вы можете подключаться к удаленной машине с помощью логина и IP-адреса — например, ssh root@185.104.114.90. Ключи будут сопоставляться автоматически.

Отключение запроса пароля

Суть приватных ключей в том, что они хранятся на локальных компьютерах. Если вы попытаетесь подключиться к серверу с другой машины, на которой нет ключа, то снова увидите запрос на ввод пароля. Чтобы авторизоваться можно было только по ключу, запретите использование пароля.

1. Подключитесь к удаленному серверу.
2. Выполните команду sudo nano /etc/ssh/sshd_config. Файл sshd_config откроется во встроенном текстовом редакторе. 
3. Найдите строку PasswordAuthentication yes и измените ее на PasswordAuthentication no.
4. Сохраните изменения и перезапустите службу SSH командой sudo service ssh restart.

Авторизация по паролю отключена. Теперь подключиться к серверу можно только с помощью пары ключей.

Краткий словарь терминов Ansible

В этом руководстве широко используются такие термины Ansible:

• Control Machine (или Node): ведущая система, в которой установлен Ansible и откуда он может подключаться к нодам и выполнять на них команды.
• Нода: сервер, управляемый Ansible.
• Файл инвентаря: файл, который содержит информацию о серверах, которыми управляет Ansible, обычно находится в /etc/ansible/hosts.
• Плейбук (Playbook): файл, содержащий серию задач, которые нужно выполнить на удаленном сервере.
• Роль: коллекция плейбуков и других файлов, которые имеют отношение к цели (например, к установке веб-сервера).
• Play: полный набор инструкций Ansible. В play может быть несколько плейбуков и ролей, включенных в один плейбук, который служит точкой входа.

Если вы хотите попрактиковаться с командами, используемыми в этом руководстве, на рабочем плейбуке Ansible, Используйте плейбук из мануала Автоматизация начальной настройки сервера с помощью Ansible в Ubuntu 18.04. Вам понадобится как минимум один удаленный сервер в качестве ноды.

Разное

В данном разделе будет рассказано о дополнительных опциях, которые позволяют менять поведение выполнения задач, добавляет функциональности или все то, для чего не найдена отдельная подходящая категория.

1. Шифрование строки.

С помощью ansible-vault мы можем шифровать файлы и папки. Это позволит нам хранить секреты не в открытом виде. Данные расшифровываются в момент выполнения задач.

Данной командой мы получаем шифрованную строку:

ansible-vault encrypt_string

Система запросит ввести дважды пароль и предложит ввести строку, которую нужно зашифровать. После мы должны нажать 2 раза Ctrl + D — мы получим строку, которая начинается с !Vault и различные символы. 

Для того, чтобы в момент выполнения задачи ansible расшифровал данные, при запуске плейбука мы должны указать ключ —ask-vault-pass:

ansible-playbook … —ask-vault-pass

Об ansible-vault: https://docs.ansible.com/ansible/latest/user_guide/vault.html.

2. Игнорировать ошибки.

Если ansible столкнется с ошибкой при выполнении задачи, работа плейбука будет завершена. Иногда, нужно пропустить ошибку при выполнении определенной задачи, чтобы выполнение было продолжено. Для этого существует опция ignore.

а) чтобы пропустить ошибки выполнения, в настройка задачи используем:

— name: Bad Task
  …
  ignore_errors: yes 

б чтобы игнорировать ошибки при подключении к хосту:

— name: Bad Task
  …
  ignore_unreachable: yes 

3. Начинать выполнение с определенной задачи.

При выполнении отладки, полезно запустить плейбук, но начать выполнение с определенной задачи. Остальные пропустить. 

Это можно сделать с помощью опции —start-at-task:

ansible-playbook … —start-at-task=»Start Job»

* в данном примере плейбук начнет выполнять задания с задачи Start Job.

4. Завершить выполнение плейбука после определенной задачи.

С помощью данной конструкции:

— meta: end_play

5. Зависимые роли.

С помощью файла meta/main.yml в роли мы можем определить пред-роль, от которой зависит выполнение текущей роли. Для этого настраивается опция dependencies:

dependencies:
  — role: pred

6. Вставка роли и ее задач.

Позволяет в процессе выполнения задачи подключить роль. Делается при помощи include_role:

— name: «Include Other Role»
  include_role:
    name: other_role

А это пример, как подключить роль и сделать так, чтобы все ее задачи выполнились на определенном хосте:

— name: «Include Other Role»
  include_role:
    name: other_role
    apply:
      delegate_to: «` deploy_vm`.`instance`.`ipv4 `»

7. Повторы при выполнении задачи.

Мы можем управлять цикличностью выполнения задач с помощью retries (количиство повторов), delay (задержка в секундах).

Рассмотрим пример повтора выполнения задачи при возникновении ошибки:

— name: Run anything command
  command: /foo/bar/cmd
  register: result
  retries: 3
  delay: 60
  until: result is not failed

* в данном примере мы будем выполнять команду /foo/bar/cmd пока ее выполнение не закончится без ошибок. Количество повторов будет равен 3 с интервалом в 60 секунд.

Небольшой пример на странице .

8. Резервное копирование базы данных MySQL/MariaDB.

Работа с базой данных возможно с помощью коллекции mysql.mysql_db. Она не идет в комплекте к ansible и нам необходимо ее установить командой:

ansible-galaxy collection install community.mysql

Резервное копирование можно выполнить так:

— name: Dump mysql databases
  community.mysql.mysql_db:
    state: dump
    name:
      — db1
      — db2
    target: /tmp/dump.sql

* в данном примере мы создадим 2 дампа из баз db1 и db2 и сохраним результат в файл /tmp/dump.sql.

О mysql_db: https://docs.ansible.com/ansible/latest/collections/community/mysql/mysql_db_module.html.

9. Объединение задач в блоки.

Это позволит установить общие свойства и условие для нескольких задач. Такая форма записи уменьшит количиство строк и упростит восприятие.

Синтаксис записи:

— name: Block Name
  block:
     — name: Task 1
       …
     — name: Task 2
       …
     — name: Task 3
       …
  when: ansible_facts == ‘CentOS’
  become: true
  become_user: root
  ignore_errors: yes

* в данном примере будет выполнены 3 задачи, если выполнится одно условие, которое описывается не для задач, а для блока.

О block: https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html.

10. Перебор массива.

Предположим, нам нужно перебрать все элементы массива в шаблоне. Это можно сделать конструкцией:

{% for host in my_hosts %}
server «` host `»
{% endfor %}

* в данном примере мы сделаем перебор по переменной my_hosts. Для каждого элемента массива будет создана строка со значением server <значение переменной>.

Ansible Vault для хранения конфиденциальных данных

Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных

Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.

Создание нового зашифрованного файла

Вы можете создать новый зашифрованный файл Ansible с помощью:

Эта команда выполнит следующие действия:

1. Сначала вам будет предложено ввести новый пароль. Вам нужно будет указывать этот пароль при каждом доступе к содержимому файла, будь то редактирование, просмотр или просто запуск плейбука (или команд с использованием его значений).
2. Затем откроется редактор командной строки по умолчанию, чтобы вы могли заполнить файл требуемым содержимым.
3. Наконец, когда вы закончите редактирование, ansible-vault сохранит файл как зашифрованный.

Шифрование существующего файла Ansible

Чтобы зашифровать существующий файл Ansible, вы можете использовать следующую команду:

Эта команда запросит у вас пароль, который вам нужно будет вводить при каждом доступе к файлу credentials.yml.

Просмотр содержимого зашифрованного файла

Если вы хотите просмотреть содержимое файла, который ранее был зашифрован с помощью ansible-vault, и вам не нужно изменять его содержимое, вы можете использовать команду:

Она предложит вам указать пароль, который вы выбрали при первом шифровании файла с помощью ansible-vault.

Редактирование зашифрованного файла

Чтобы изменить содержимое файла, который ранее был зашифрован с помощью Ansible Vault, выполните:

Эта команда предложит вам указать пароль, который вы выбрали при первом шифровании файла credentials.yml. После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести нужные изменения. По завершении вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено и зашифровано.

Расшифровка файлов

Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:

Эта команда предложит вам ввести тот пароль, который использовался при первом шифровании файла. После проверки пароля содержимое файла будет сохранено на диск в виде незашифрованных данных.

Создание роли

Роли в Ansible используются для логического разделения плейбука. Они имеют строгий синтаксис и файловую структуру. Таким образом, конфигурация становится более упорядоченной и понятной для дальнейшей поддержки.

И так, для ролей должна быть четкая файловая структура — создаем каталоги:

mkdir -p /etc/ansible/roles/nginx/tasks

mkdir -p /etc/ansible/roles/epel/tasks

* в данном случае мы создали каталоги nginx, epel и tasks внутри каталога roles. В ansible это означает, что мы создали роли с названием nginx и epel, а файл main.yml, который мы поместим в каталоги tasks будет описывать задачи данных ролей.

Создаем файл с описанием задач для роли nginx:

vi /etc/ansible/roles/nginx/tasks/main.yml

—
— name: Install Nginx Web Server on RedHat Family
  yum:
    name=nginx
    state=latest
  when:
    ansible_os_family == «RedHat»
  notify:
    — nginx systemd
— name: Install Nginx Web Server on Debian Family
  apt:
    name=nginx
    state=latest
  when:
    ansible_os_family == «Debian»
  notify:
    — nginx systemd

* где 

• — — начало файла YAML; 
• name — название для роли (может быть любым);
• yum/apt — используемый модуль для установки приложения; 
• yum/apt name — название пакета, которое мы устанавливаем; 
• yum/apt state — состояние пакета, которое должно контролироваться ролью;
• when — условие, при котором данная роль будет выполняться;
• notify — обработчик, который будет вызван в случае успешного выполнения задачи. При необходимости, можно задать несколько обработчиков;

* В данном примере мы создали простую задачу для роли по развертыванию nginx. На системы RPM установка выполняется с помощью модуля yum, на deb — apt. Версия должна быть последней (latest); после установки пакета, необходимо разрешить автозапуск сервиса и запустить его.
* при установке пакетов также следует учитывать, что некоторые могут иметь разные названия в разных системах. Например, Apache в RMP-системах называется httpd, в deb — apache2.

Создаем файл с описанием задач для роли epel:

vi /etc/ansible/roles/epel/tasks/main.yml

—
— name: Install EPEL Repo
  yum:
    name=epel-release
    state=present

Обратите внимание, что в плейбуке выше мы задействовали notify, но не задали handlers — в качестве примера, мы вынесем его в отдельный файл:

mkdir /etc/ansible/roles/nginx/handlers

vi /etc/ansible/roles/nginx/handlers/main.yml

—
— name: nginx systemd
  systemd:
    name: nginx
    enabled: yes
    state: started

* handlers — описание обработчика, который может быть вызван с помощью notify; systemd — модуль для управления юнитами systemd; systemd enabled — разрешает или запрещает сервис; systemd state — состояние, которое должно быть у сервиса. В данном примере мы указываем, что у демона nginx должно быть состояние started и разрешен автозапуск (enabled).

Создание плейбука

Создаем файл для playbook:

vi /etc/ansible/play.yml

—
— hosts: redhat-servers
  become:
    true
  become_method:
    su
  become_user:
    root
  remote_user:
    ansible
  roles:
   — epel
   — nginx
— hosts: debian-servers
  become:
    true
  become_method:
    sudo
  become_user:
    root
  remote_user:
    ansible
  roles:
   — nginx

* где:

• — — начало файла YAML. Данный формат имеет строгую структуру  — важен каждый пробел; 
• hosts — группа хостов, к которым будут применяться правила плейбука (если мы хотим, чтобы правила применялись ко всем хостам, указываем hosts: all); 
• become — указывает на необходимость эскалации привилегий; 
• become_method — метод эскалации привилегий; 
• become_user — пользователь под которым мы заходим с помощью become_method; 
• remote_user — пользователь, под которым будем подключаться к удаленным серверам; 
• roles — список ролей, которые будут применяться для плейбука.

* В данном случае мы задействуем нашу группы хостов, которые создали в самом начале; повышаем привилегии методом su под пользователем root (su — root) для группы redhat-servers и методом sudo для debian-servers; подключение к серверам выполняется от пользователя ansible; используем созданную нами роль nginx (саму роль мы создадим позже). Для систем RPM сначала выполним роль epel — она будет отвечать за установку репозитория EPEL, так как в стандартном репозитории nginx нет.

Стоит отдельно уделить внимание вопросу повышения привилегий. IT-среды могут применять разные политики относительно безопасности

Например, на серверах CentOS, по умолчанию, нет sudo и повышать привилегии нужно с помощью su. В Ubuntu наоборот — по умолчанию есть sudo, а su не работает, так как пароль на root не устанавливается. В данном случае есть несколько путей при работе с Ansible:

1. Как в нашем примере, разделить группы хостов на разные семейства операционных систем и применять к ним разные методы повышения привилегий. Чтобы данный плейбук корректно отработал, учетная запись, под которой идет удаленное подключение к серверу (в нашем примере ansible) должна иметь такой же пароль, как у пользователей root на серверах семейства Red Hat. Данный метод удобен с точки зрения отсутствия необходимости приводить к единому виду безопасность серверов разного семейства. Однако, с точки зрения безопасности лучше, чтобы пароли у root и ansible были разные.
2. Использовать метод для создания плейбука, как описан выше, но запускать его с ключом —limit, например, ansible-playbook —limit=debian-servers … — таким образом, мы запустим отдельные задания для каждого семейства операционных систем и сможем ввести индивидуальные пароли для каждого случая.
3. Мы можем на всех серверах deb установить пароль для пользователя root, таким образом, получив возможность для become_method: su.
4. И наконец, можно для серверов Red Hat установить sudo и проходить become с помощью метода sudo.