Управление обновлениями

Поскольку обновление системы редко сводится к простому yum update -y, управление обновлениями — это роль Ansible для удобного управления процессом обновления и всем, что с этим связано, для серверов с операционными системами RedHat, CentOS, Debian или Ubuntu.

В процессе управления обновлениями, если вы хотите:

• установить цель в режим обслуживания в вашем мониторинге
• отправить сообщение в начале или в конце процесса
• реагировать на ошибки
• и т.д.

эта роль упростит вашу жизнь.

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

Требования

Никаких особых требований.

Функции

• Делать заметки о системе — IP-адрес и маршруты, запущенные процессы, точки монтирования (для устранения неполадок! Не забудьте об этом!)
• Выполнять пользовательские задачи для всех серверов (смотрите переменную pm_before_update_tasks_file)
• Выполнять пользовательские задачи для целевого сервера (смотрите примеры в главе о плейбуках)

Наша основная цель:

• Обновить сервер с помощью apt или yum

А потом:

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

Переменные роли

• pm_restart_after_update: по умолчанию true

Должен ли целевой сервер перезапуститься после управления обновлениями? Это гарантирует, что послед ядро работает и что сервер и его службы могут перезапуститься. Рассмотрите возможность выполнения этого регулярно.

• pm_logpath: по умолчанию /etc/ansible/facts.d/PM.log

Где хранить дату успешных или неудачных обновлений?

• pm_date_format: по умолчанию "{{ ansible_date_time.date }}-{{ ansible_date_time.time }}"

Как отформатировать дату в фактах и пути к логам?

• pm_fact_name: по умолчанию pm

Какое имя факта мы хотим?

• pm_set_env_variable: по умолчанию true
• pm_env_file_path: по умолчанию /etc/profile.d/last_pm_date.sh

Устанавливаем ли мы переменную окружения с датой последнего обновления и где хранить скрипт?

• pm_manage_yum_clean_all: по умолчанию true

Запуская yum clean all перед обновлением. Вы должны установить false, если, например, вы когда-либо скачивали RPM.

• pm_manage_apt_clean: true

Запускает apt clean перед обновлением.

• pm_manage_apt_autoremove: true

Автоматическое удаление deb-пакетов.

• pm_apt_verbose_package_list: false

Печатает список результатов apt.

• pm_before_update_tasks_file:

Например, custom_tasks/pm_before_update_tasks_file.yml. Вы можете настроить роль на выполнение этого файла задач перед обновлением сервера. Каждая задача в целевом файле будет выполнена.

Рассмотрите возможность добавления таких задач, как отправка сообщения, создание снимка, установка режима обслуживания и т.д.

• pm_after_update_tasks_file:

Например, custom_tasks/pm_after_update_tasks_file.yml. Вы можете настроить роль на выполнение этого файла задач до обновления сервера. Каждая задача в целевом файле будет выполнена.

Пример Плейбука

Настроить плейбук довольно просто, как вы можете видеть:

- name: Начать управление обновлениями
  hosts: servers
  vars:
    pm_before_update_tasks_file: custom_tasks/pm_before_update_tasks_file.yml
    pm_after_update_tasks_file: custom_tasks/pm_after_update_tasks_file.yml
  tasks:
    - name: "Включить управление обновлениями"
      include_role:
        name: "alemorvan.patchmanagement"

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

В отличие от переменных pm_before_update_tasks_file и pm_after_update_tasks_file (которые нацелены на выполнение действий для всех целевых серверов), эти файлы сосредоточены на действиях, специфичных для одного сервера.

В директории плейбука создайте директорию custom_tasks и файлы с именами before_pm_{{ inventory_hostname_short }}_custom_tasks.yml и after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.

  - name: Выполнить пользовательские задачи для этого сервера, определенные с помощью файла after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.
    debug:
      msg: "Эта задача — пользовательская задача, определенная в файле after_pm_{{ inventory_hostname_short }}_custom_tasks.yml"

Тестирование с помощью Molecule

Вы можете протестировать эту роль с помощью Molecule и Docker:

  $ molecule test

Смотрите molecule/default/converge.yml для хорошего примера того, как использовать эту роль.

Лицензия

MIT

Информация об авторе

Эта роль была изначально написана Антуаном Ле Морваном для Vivalto Sante на основе работы Николаса Мартина и команды Ansible в Claranet France / BU RMP (Исмаэль Уатарра и Эли Делуме).