Покрываем плэйбуками ansible IaC в части предоставления доступа

Инфраструктура как код (Infrastructure-as-Code; Iac) — это подход для управления и описания инфраструктуры ЦОД через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие.

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

Я покажу своё видение структуры такой ansible-роли (далее — роль).

• Структура tasks/main.yml

• Особенности сбора фактов о текущем состоянии

• Порядок работы с сущностями

• Формирование отладочной информации

Начнем с tasks/main.yml:

--- # Проверка корректности конфигурационных  # файлов описанных в IaC # Проверки корректности и имен и взаимосвязей  - name: Check   include_tasks:     file: check.yml   tags: always   run_once: true  # Установка на целевой хост пакетов, # необходимых для работы  # ansible-модулей   - name: installing the required packages   apt:     name: "{{ item }}"   loop:     - required_package_1     - required_package_2  # Получение имени последнего коммита. # Его можно использовать в качестве темы письма, а также # проводить различные проверки на его содержание.  - name: get latest commit message   shell: git log --pretty="%s" -n1   register: latest_commit_message   tags: always   run_once: true   delegate_to: localhost   changed_when: false  # Сбор фактов о существующих сущностях  # на которые выдаются права  # и правах предоставленных пользователям  - name: Collect info about entities, roles   become: true   become_user: postgres   community.postgresql.postgresql_info:     login_unix_socket: '{{ pg_login_unix_socket }}'     db: postgres     filter:       - "databases"       - "roles"   register: "pg_exist" # Тегирование -  важный элемент формирования роли.  # Позволит нам изорировать работу с различным видом сущностей.   tags:     - pg_db_config     - pg_roles_config   run_once: true  # Последовательная работа с ролями  - name: Work with roles   include_tasks:     file: pg_roles.yml     apply:       tags: pg_roles_config   when: pg_roles_config   tags: pg_roles_config   run_once: true  # работа с сущностями  - name: Work with db   include_tasks:     file: pg_db.yml     apply:       tags: pg_db_config   when: pg_db_config   tags: pg_db_config   run_once: true  # работа с дополнительными механизмами,  # обеспечивающими доступ   - name: Work with pg_hba   include_tasks:     file: pg_hba.yml     apply:       tags: pg_hba_config   when: pg_hba_config   tags: pg_hba_config   # run_once: true  # Вывод ошибок полученных в рамках работ,  # естественно красным цветом  - name: Fail message   debug:     msg: "Не все конфиги были применены \n{{ rescue_msgs|to_nice_yaml }}"   failed_when: true   when: rescue_msgs != []   tags: always   run_once: true

Здесь приведен пример сбора фактов с использованием готового модуля (строка 35), однако если такового нет придется поработать шелом и жинжа фильтрами. После выполнения команды с модулем command/shell можно сохранить вывод в переменной с помощью параметра register. Это позволит использовать вывод в дальнейших задачах плейбука. Ansible позволяет использовать фильтры Jinja2 для обработки сохраненного вывода. Фильтры позволяют разбирать строки, извлекать подстроки, разделить текст на отдельные элементы и многое другое.

- name: Run a shell command and parse the output using regex   hosts: your_target_hosts   tasks:     - name: Execute the shell command       command: your_shell_command       register: shell_output      - name: Process the output using regex       debug:         msg: "{{ shell_output.stdout | regex_search('pattern') }}"

При сборе фактов формируем словари-списки идентичные тем, которые описаны в IaC. То есть для последующего сравнения мы должны получить пары:

pg_db_exist # существующие сущности pg_db_iac # сущности, описанные в IaC

На примере работы с базами данных рассмотрим порядок работы с сущностями.

--- # Формирование идентичного словаря - name: Parse db from output   set_fact:     pg_db_exist: |       {{pg_db_exist|combine({item.key: {'access_priv': item.value.access_priv|regex_replace("/.*\n","/")|split("/")|map('regex_search', '.*=.*')|select('string')|list, 'owner': item.value.owner}})}}   loop: "{{ pg_exist.databases|dict2items }}"   when: pg_exist.databases != {}  # Формирование словаря на сущностей для создания - set_fact:     db_dict_to_create: '{{ db_dict_to_create | combine({ item.key : item.value })}}'   loop: "{{ pg_db_iac|dict2items }}"   when: item.key not in pg_db_exist  # Формирование словаря на сущностей для изменения - set_fact:     db_dict_to_alter: '{{ db_dict_to_alter | combine({ item.key : item.value })}}'   loop: "{{ pg_db_iac|dict2items }}"   when: item.key in pg_db_exist and item.value != pg_db_exist[item.key]  # Формирование словаря на сущностей для удаления - set_fact:     db_dict_to_delete: '{{ db_dict_to_delete | combine({ item.key : item.value })}}'   loop: "{{ pg_db_exist|dict2items }}"   when: item.key not in pg_db_iac  # Защита от автоматического удаления  #  на проде - name: Verify required db   assert:     that: db_dict_to_delete == {}     fail_msg: "You need to delete databases. Set db_auto_delete=true"   when: not db_auto_delete 

# Вывод информации о том, что было,  # что будет, чем сердце успокоится # он поможет нам не только отлаживаться  # в рамках рутинной работы,  # но и сформировать первичный словарь/список,  # который будет внесен в IaC - debug:     msg: "pg_db_exist\n {{ pg_db_exist|to_yaml }}\n\n pg_db_iac\n {{ pg_db_iac|to_yaml }}\n\n/   {%- if db_dict_to_alter != {} -%}DB will be altered\n{{ db_dict_to_alter|to_yaml }}\n\n{% endif %}   {%- if db_dict_to_create != {} -%}DB will be created\n{{ db_dict_to_create|to_yaml }}\n\n{% endif %}   {%- if db_dict_to_delete != {} -%}DB will be deleted\n{{ db_dict_to_delete|to_yaml }}\n\n{% endif %}"  # Сами действия с сущностями - name: Delete databases   include: pg_db_action.yml   vars:     pg_db_action: 'absent'   loop: "{{ db_dict_to_delete|dict2items }}"   when: db_auto_delete and db_dict_to_delete != {}  - name: Create databases   include: pg_db_action.yml   vars:     pg_db_action: 'present'     pg_db_create: true     loop_access_priv: "{{ item.value.access_priv }}"   loop: "{{ db_dict_to_create|dict2items }}"   when: db_dict_to_create != {}  - name: Update databases   include: pg_db_action.yml   vars:     pg_db_action: 'present'     pg_db_update: "{{ pg_db_exist }}"     access_priv_out: "{{ pg_db_exist[item.key].access_priv | difference(item.value.access_priv) }}"     access_priv_in: "{{ item.value.access_priv | difference(pg_db_exist[item.key].access_priv) }}"   loop: "{{ db_dict_to_alter|dict2items }}"   when: db_dict_to_alter != {}

Формирование отладочной информации — важный этап, который поможет понять почему не отработали скрипты и где закралась ошибка. Понятное, дело чем больше кода мы покроем такой обработкой — тем больше отладочной информации получим. Рассмотрим пример.

# Работаем с блоками ansible - name: Block   block:     - name: Action {{ pg_db_action }} a database with name {{ item.key }}       become: true       become_user: postgres       community.postgresql.postgresql_db:         login_unix_socket: '{{ pg_login_unix_socket }}'         name: "{{ item.key }}"         state: "{{ pg_db_action }}"         owner: "{{ item.value.owner }}"       register: actionresult # В случае неудачи мы не падаем  # и выходим из роли,  # а продолжаем выполнение,  # записав ошибку в список ошибок, # который мы выводим в конце роли    rescue:     - set_fact:         rescue_msgs: "{{ rescue_msgs|default([]) +          [ 'Action '+pg_db_action+' a database with name '          + item.key+' unsucsessful because '+actionresult.msg] }}"

Надеюсь, что данная статья поможет структурировать мысли и оформить вашу инфраструкту.