Как мы победили сумрак между тестированием и эксплуатацией

[VGusev2007]

Отлично! Нам тоже понравился ansible, но встал вопрос GUI к этому делу. Как вы у себя решили задачу фронтэнда для ansible? Ведь иногда очень легко накосячить и с ansible… — Последствия будут фатальны. Мы используем rundeck для таких задач.

Я думаю, что компании Вашего уровня, ansible tower, может быть не очень дорогим, но цены у него во истину не демократичные. От 5тыс. долларов за год на 100 узлов.

[andshorin]

Благодарю за отзыв о компании. Также принимаю его как личный комплимент. Спасибо.

Что касается аудита запущенных плейбуков и результатов их работы, то в ansible.cfg мы прописали логгирование в определенный файл. И дописали callback plugin по логгированию действий: pastebin.com/3Kni2U1r

Поэтому если чье-то ошибочной действие привело к проблемам, мы сможем найти причину и время. И предпринять действия, чтобы избежать подобных проблем в будущем.

Что касается самих плейбуков Ansible, то чтобы там не сделать что-то неправильно, надо использовать тот самый тестовый стенд, на котором плейбук можно отладить. Кроме того, мы создали общий сценарий выкладки любого пакета. Таким образом, описание выкладки приложения выглядит следющим образом:

- include: common-head.yml hosts='some_group' role='null' rsyslog_role='some_group' okagent_role='some_group' actions='[ "deploy", "check", "restart" ]'

- hosts: some_group
  sudo: yes
  gather_facts: no
  serial: 1
  vars_files:
    - app_versions
  vars:
    role: some_role
    service_name:
      service: 'hh-service-name' # инит-скрипт
      on_config: restart
      configs:
        - { file: 'etc/hh-service-name/config_file.cfg', mode: '644' }
        - { file: 'etc/default/hh-service_name', mode: '644' }
      port: 999
      uri: '/status'
      list:
        - { pkg: 'libcurl3', ver: '{{ ver_libcurl }}' }
        - { pkg: 'python-tornado', ver: '{{ ver_tornado }}' }
        - { pkg: 'hh-service_name', ver: '{{ ver_hh_service_name }}' }

  tasks:
    - { include: '{{ inventory_dir }}/roles/common/tasks/dpkg-app.yml', pkg: '{{ service_name }}' }

  handlers:
    - { include: '{{ inventory_dir }}/roles/common/handlers/dpkg-app.yml', pkg: '{{ service_name }}' }

Общие для хостов задачи решаются в common-head. Когда дело доходит до выкладки приложения, то вот что делает dpkg-app, tasks + handlers:

• проверка, что версия пакета будет меняться
• выключение сервера из балансировщика
• обновление версии
• обновление конфигов
• если конфиги менялись, то выключение сервера из балансировщика; не дублируем, если уже отключали
• запуск (перезапуск) сервиса, если меняли версию или конфиги
• ожидание открытого порта
• ожидание удачного ответа на указанный uri
• включение в балансировщике

Поскольку плейбук такой простой, а «библиотека» dpkg-app хорошо отлажена, то проблем с косяками у нас не бывает.

Кроме того, изменения версий и конфиг-файлов приезжают в эксплуатацию уже протестированными, в том числе с плейбуками Ansible.

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

[andshorin]

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