Ansible и ChatOps или как управлять 100+ серверами из чата

Обновлено: 21 февраля 2017

Что такое ChatOps?

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

Можно придумать такие вещи как деплой кода или развертывание серверов из чата, просмотр графиков мониторинга, отправку SMS, управление кластерами или просто запуск shell команд. ChatOps может быть высокоуровневым представлением вашей действительно сложной CI/CD системы, неся простоту с помощью команды в чате вроде: !deploy that thing. Такой подход делает чудеса для улучшения видимости и снижения сложности вокруг процесса развертываний.

Улучшенный ChatOps

StackStorm — OpenSource проект с особым вниманием к автоматизации и ChatOps. Платформа связывает то огромное количество существующих DevOps инструментов вроде управления конфигурацией, мониторинга, графиков, оповещения итд. вместе, позволяя править всем из единого контрольного пункта. И это идеально с точки зрения ChatOps, — можно создавать и автоматизировать мыслимые и немыслимые рабочие процессы, контролируя любые наборы инструментов прямо из чата.

В StackStorm есть Ansible интеграция и начиная с <1.0 версий добавлено еще больше ChatOps возможностей в 1.2 и 1.4 релизах, что открывает дорогу для реального применения ChatOps, не просто постинг фотографий забавных котиков с помощью бота. В этом материале мы расскажем как заставить работать ChatOps и Ansible с помощью StackStorm платформы.

Кстати, StackStorm как и Ansible декларативен, написан на Python и использует Yaml + Jinja, что позволит вам легче во всем разобраться.

План

Вначале мы собираемся установить контрольную машину, которая будет работать под Ubuntu 14. Затем мы настроим на ней StackStorm платформу, в том числе пакеты управления Ansible и ChatOps фреймворком Hubot. И наконец, мы подключим всю систему к Slack чату, и покажем несколько простых, но реальных примеров интерактивного использования Ansible.

Давайте начнем, а заодно проверим как далеко мы зашли и наступила ли технологическая сингулярность, давая root доступ каким-то чат ботам и позволяя им управлять нашими 100+ серверами или даже датацентрами (кстати RackSpace работают с ChatOps).

Шаг 0. Подготовка Slack

Как уже было сказано, мы будем использовать Slack.com как чат платформу (хотя доступны другие интеграции). Зарегистрируйте Slack аккаунт, если у вас его еще нет. Включите интеграцию Hubot в настройках.

Hubot — фреймворк бота от GitHub, созданный специально для ChatOps

В итоге Slack выдаст вам API токен вроде:

HUBOT_SLACK_TOKEN=xoxb-5187818172-I7wLh4oqzhAScwXZtPcHyxCu

Далее мы настроим StackStorm платформу, покажем реальные примеры использования, и конечно же, расскажем как создать собственные ChatOps команды.
Но подождите, есть простой способ!

Для самых ленивых

Для тех кто ленив (большинство DevOps разработчиков такие), есть специально подготовленный репозиторий с Vagrant, который установит все необходимое с помощью простейших bash скриптов, доставив вас с линии старта прямо на финиш, давая возможность после автоматической установки сразу запускать ChatOps команды из Slack чата showcase-ansible-chatops:

# Замените на свой токен
export HUBOT_SLACK_TOKEN=xoxb-5187818172-I7wLh4oqzhAScwXZtPcHyxCu
git clone https://github.com/StackStorm/showcase-ansible-chatops.git
cd showcase-ansible-chatops

vagrant up

Для тех же кому интересны подробности — переключимся из автоматического режима в ручной и пройдемся по всем шагам. Просто имейте ввиду, если что-то не получается — сверьтесь с примерами из ansible & chatops демо репозитория.

Шаг 1. Установка StackStorm

Установка проста. Всего 1 команда:

curl -sSL https://stackstorm.com/packages/install.sh | sudo bash -- --user=demo --password=demo

Имейте ввиду, это для демонстрационных целей. При развертывании продакшена используйте Ansible плейбуки, сверяйте подписи и не доверяйте установочным командам в одну строчку! Подробности установки описаны в документации: docs.stackstorm.com/install/deb.html

Шаг 2. Установка StackStorm плагина: Ansible

Идея интеграционных паков (плагинов) в StackStorm такова, что они связывают систему с другими инструментами и внешними сервисами.
Итак, нам нужен Ansible пак, устанавливаем:

st2 pack install ansible

Cам Ansible будет доступен в Python virtualenv: /opt/stackstorm/virtualenvs/ansible

Полный список интеграций: exchange.stackstorm.org, среди них: AWS, GitHub, RabbitMQ, Pagerduty, Jenkins, Nagios, Docker, — всего более 100+!

Шаг 3. Настройка ChatOps

Теперь необходимо настроить /opt/stackstorm/chatops/st2chatops.env файл с переменными окружения. Вот так он выглядел для Slack бота с именем stanley:

# Bot name
export HUBOT_NAME=stanley
export HUBOT_ALIAS='!'

# StackStorm API key
# Use: `st2 apikey create -k` to generate
# Replace with your key (!)
export ST2_API_KEY="123randomstring789"

# ST2 AUTH credentials
# Replace with your username/password (!)
export ST2_AUTH_USERNAME="demo"
export ST2_AUTH_PASSWORD="demo"

# Configure Hubot to use Slack
export HUBOT_ADAPTER="slack"

# Replace with your token (!)
export HUBOT_SLACK_TOKEN="xoxb-5187818172-I7wLh4oqzhAScwXZtPcHyxCu"

После изменений, не забываем перезапустить сервис:

sudo service st2chatops restart

Шаг 4. Первый ChatOps опыт

На данном этапе Stanley бот должен быть онлайн в чате. Чтобы пригласить его в определенную Slack комнату:

/invite @stanley

Получить список доступных команд:

!help

Наверняка вам понравится shipit:

!ship it

Вдоволь наигравшись с существующими командами, займемся действительно серьезными вещами.

Шаг 5. Создание собственных ChatOps команд

Одна из возможностей StackStorm — это способность создавать простые алиасы/обертки вокруг команд, упрощая работу с ChatOps. Вместо того чтобы набирать длинную команду, вы можете просто забиндить ее на что-то более дружественное и легкое, синтаксический сахар.

Итак, создадим свой собственный StackStorm пак который будет содержать нужные нам команды. Форкните StackStorm template pack на GitHub. Наш первый action alias aliases/ansible.yaml:

---
name: "chatops.ansible_local"
action_ref: "ansible.command_local"
description: "Run Ansible command on local machine"
formats:
  - display: "ansible <command>"
    representation:
      - "ansible {{ args }}"
result:
  format: |
    Ansible command `{{ execution.parameters.args }}` result: {~}
    {% if execution.result.stderr %}*Stdout:* {% endif %}
    ```{{ execution.result.stdout }}```
    {% if execution.result.stderr %}*Stderr:* ```{{ execution.result.stderr }}```{% endif %}
  extra:
    slack:
      color: "{% if execution.result.succeeded %}good{% else %}danger{% endif %}"

Для справки: вышеуказанный алиас использует ansible st2 integration pack

Отправляем изменения в недавно созданный GitHub репозиторий и можно устанавливать наш пак. Для этого уже есть ChatOps алиас:

!pack install https://github.com/armab/st2_chatops_aliases

Теперь можно запускать простые Ansible ad-hoc команды прямо из Slack чата:

!ansible "uname -a"

На низком уровне это тоже самое что:

/opt/stackstorm/virtualenvs/ansible/bin/ansible all --connection=local --args='uname -a' --inventory-file='127.0.0.1,'

Но давайте рассмотрим более полезные примеры интерактивного ChatOps.

Пример 1. Получаем статус серверов

У Ansible есть ping модуль который подключается к хостам и возвращает pong в случае успеха. Простой, но мощный пример, позволяющий понять состояние серверов прямо из чата за считанные секунды без необходимости заходить в терминал.

Для этого создадим в нашем паке action, запускающий реальную команду и action alias, являющийся синтаксическим сахаром для экшна и позволяющий создать такую ChatOps конструкцию:

!status 'web'

Action actions/server-status.yaml:

---
name: server_status
description: Show server status by running ansible ping ad-hoc command
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    description: "Run command with sudo"
    type: boolean
    immutable: true
    default: true
  kwarg_op:
    immutable: true
  cmd:
    description: "Command to run"
    type: string
    immutable: true
    default: "/opt/stackstorm/virtualenvs/ansible/bin/ansible {{hosts}} --module-name=ping"
  hosts:
    description: "Ansible hosts to ping"
    type: string
    required: true

Кстати, кроме bash скриптов, Action может работать с Python runner либо вообще любым бинарником, способным возвращать json, — здесь вся гибкость использования.

Action alias aliases/server_status.yaml:

---
name: chatops.ansible_server_status
action_ref: st2_chatops_aliases.server_status
description: Show status for hosts (ansible ping module)
formats:
  - display: "status <hosts>"
    representation:
      - "status {{ hosts }}"
      - "ping {{ hosts }}"
result:
  format: |
    Here is your status for `{{ execution.parameters.hosts }}` host(s): {~}
    ```{{ execution.result.stdout }}```
  extra:
    slack:
      color: "{% if execution.result.succeeded %}good{% else %}danger{% endif %}"
      fields:
        - title: Alive
          value: "{{ execution.result.stdout|regex_replace('(?!SUCCESS).', '')|wordcount }}"
          short: true
        - title: Dead
          value: "{{ execution.result.stdout|regex_replace('(?!UNREACHABLE).', '')|wordcount }}"
          short: true
      footer: "{{ execution.id }}"
      footer_icon: "https://stackstorm.com/wp/wp-content/uploads/2015/01/favicon.png"

Убедитесь, что вы добавили нужные хосты в Ansible inventory файл: /etc/ansible/hosts

После отправки кода в репозиторий, не забудьте перезагрузить ваш пак из чата:

!pack install armab/st2_chatops_aliases

Очень удобно что мы можем хранить все наши ChatOps настройки в виде st2 пака и подхватывать изменения из репозитория, — инфраструктура как код.

Результат только что созданной команды в Slack:


Это действительно удобно, даже ваш CEO может посмотреть статус не имея доступа к серверам! С таким подходом общение, развертывание и работа вокруг инфраструктуры может происходить прямо в чате: находитесь ли вы в офисе или работаете удаленно (некоторые из нас могут работать прямо с пляжа).

Пример 2. Перезагрузка сервисов

С вами когда-то случалось так, что простая перезагрузка сервиса помогала? Не идеальный способ, но зачастую быстрое решение просто необходимо. Давайте создадим ChatOps команду которая бы перегружала указанный сервис на определенных серверах.
Задача получить такую конструкцию:

!service restart "rabbitmq-server" on "mq-01"

Для этого в уже существующем st2 паке создайте actions/service_restart.yaml:

---
name: service_restart
description: Restart service on remote hosts
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    description: "Run command with sudo"
    type: boolean
    immutable: true
    default: true
  kwarg_op:
    immutable: true
  cmd:
    description: "Command to run"
    type: string
    immutable: true
    default: "/opt/stackstorm/virtualenvs/ansible/bin/ansible {{hosts}} --become --module-name=service --args='name={{service_name}} state=restarted'"
  hosts:
    description: "Ansible hosts"
    type: string
    required: true
  service_name:
    description: "Service to restart"
    type: string
    required: true

ChatOps алиас aliases/service_restart.yaml:

---
name: chatops.ansible_service_restart
action_ref: st2_chatops_aliases.service_restart
description: Restart service on remote hosts
formats:
  - display: "service restart <service_name> on <hosts>"
    representation:
      - "service restart {{ service_name }} on {{ hosts }}"
result:
  format: |
    Service restart `{{ execution.parameters.service_name }}` on `{{ execution.parameters.hosts }}` host(s): {~}
    {% if execution.result.stderr %}
    *Exit Status*: `{{ execution.result.return_code }}`
    *Stderr:* ```{{ execution.result.stderr }}```
    *Stdout:*
    {% endif %}
    ```{{ execution.result.stdout }}```
  extra:
    slack:
      color: "{% if execution.result.succeeded %}good{% else %}danger{% endif %}"
      fields:
        - title: Restarted
          value: "{{ execution.result.stdout|regex_replace('(?!SUCCESS).', '')|wordcount }}"
          short: true
        - title: Failed
          value: "{{ execution.result.stdout|regex_replace('(?!(FAILED|UNREACHABLE)!).', '')|wordcount }}"
          short: true
      footer: "{{ execution.id }}"
      footer_icon: "https://stackstorm.com/wp/wp-content/uploads/2015/01/favicon.png"

Результат:

И знаете что? Благодаря мобильному приложению Slack вы можете перезагружать сервисы прямо с вашего телефона!

Пример 3. MySQL processlist

Мы хотим создать простую Slack команду, которая бы отображала список выполняемых SQL запросов на MySQL сервере:

!show mysql processlist

Action actions/mysql_processlist.yaml:

---
name: mysql_processlist
description: Show MySQL processlist
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    immutable: true
    default: true
  kwarg_op:
    immutable: true
  cmd:
    description: "Command to run"
    type: string
    immutable: true
    default: "/opt/stackstorm/virtualenvs/ansible/bin/ansible {{ hosts }} --become --become-user=root -m shell -a \"mysql --execute='SHOW PROCESSLIST;' | expand -t 10\""
  hosts:
    description: "Ansible hosts"
    type: string
    default: db

Action alias для ChatOps: aliases/mysql_processlist.yaml:

---
name: chatops.mysql_processlist
action_ref: st2_chatops_aliases.mysql_processlist
description: Show MySQL processlist
formats:
  - display: "show mysql processlist <hosts=db>"
    representation:
      - "show mysql processlist {{ hosts=db }}"
      - "show mysql processlist on {{ hosts=db }}"
result:
  format: |
    {% if execution.status == 'succeeded' %}MySQL queries on `{{ execution.parameters.hosts }}`: ```{{ execution.result.stdout }}```{~}{% else %}
    *Exit Code:* `{{ execution.result.return_code }}`
    *Stderr:* ```{{ execution.result.stderr }}```
    *Stdout:* ```{{ execution.result.stdout }}```
    {% endif %}

Заметьте, что мы сделали hosts параметр опциональным (db по умолчанию), так что эти две команды эквивалентны:

!show mysql processlist
!show mysql processlist 'db'

Ваш DBA будет счастлив!

Пример 4. Получаем HTTP статистику из nginx

Мы хотим получить массив HTTP статус кодов из nginx лога, отсортировать их в зависимости от количества и красиво отобразить в чате, чтоб понять как много 200 или 50x ошибок на веб серверах, находятся ли они в пределах нормы или нет:

!show nginx stats on 'web'

Для этого создадим action, который запускает shell команду, actions/http_status_codes.yaml:

---
name: http_status_codes
description: Show sorted http status codes from nginx logs
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    immutable: true
    default: true
  kwarg_op:
    immutable: true
  cmd:
    description: "Command to run"
    type: string
    immutable: true
    default: "/opt/stackstorm/virtualenvs/ansible/bin/ansible {{ hosts }} --become -m shell -a \"awk '{print \\$9}' /var/log/nginx/access.log|sort |uniq -c |sort -k1,1nr 2>/dev/null|column -t\""
  hosts:
    description: "Ansible hosts"
    type: string
    required: true

Alias aliases/http_status_codes.yaml:

---
name: chatops.http_status_codes
action_ref: st2_chatops_aliases.http_status_codes
description: Show sorted http status codes from nginx on hosts
formats:
  - display: "show nginx stats on <hosts>"
    representation:
      - "show nginx stats on {{ hosts }}"
result:
  format: "```{{ execution.result.stdout }}```"

Спасибо Brian Coca, Ansible core разработчику за великолепную идею!

Все больше и больше это выглядит как контрольный центр управления полетами. Вы можете запускать целые цепочки команд на серверах прямо из чата и каждый может видеть результат в режиме реального времени. Отлично!

Пример 5. Security patching

Представьте что вам необходимо срочно устранить очередную критическую уязвимость вроде Shellshock. Для этого надо обновить bash на всех серверах. Ansible пожалуй идеальный инструмент для таких атомарных операций. Но вместо запуска однострочной ansible команды, давайте создадим добротный playbook:
playbooks/update_package.yaml:

---
- name: Update package on remote hosts, run on 25% of servers at a time
  hosts: "{{ hosts }}"
  serial: "25%"
  become: True
  become_user: root
  tasks:
    - name: Check if Package is installed
      command: dpkg-query -l {{ package }}
      register: is_installed
      failed_when: is_installed.rc > 1
      changed_when: no

    - name: Update Package only if installed
      apt: name={{ package }}
        state=latest
        update_cache=yes
        cache_valid_time=600
      when: is_installed.rc == 0

Playbook обновит пакет только если он уже установлен, операция производится на 20% хостов за раз, те в 5 шагов. Полезно, когда надо обновить что-то более серьезное вроде nginx на действительно большом количестве серверов. Таким образом мы не отправляем весь веб кластер в даун. Дополнительно можно добавить отключение от балансировщика нагрузки группами. Пример из реальной жизни.

Видно, что playbook переменные {{hosts}} и {{package}} приходят откуда-то извне, а именно из экшена в нашем StackStorm паке actions/update_package.yaml:

---
name: update_package
description: Update package on remote hosts
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    immutable: true
    default: true
  kwarg_op:
    immutable: true
  timeout:
    default: 6000
  cmd:
    description: "Command to run"
    immutable: true
    # эта строчка
    default: "/opt/stackstorm/virtualenvs/ansible/bin/ansible-playbook /opt/stackstorm/packs/${ST2_ACTION_PACK_NAME}/playbooks/update_package.yaml --extra-vars='hosts={{ hosts }} package={{ package }}'"
  hosts:
    description: "Ansible hosts"
    type: string
    required: true
  package:
    description: "Package to upgrade"
    type: string
    required: true

Action alias, дающий возможность запускать playbook в виде простой ChatOps команды,
aliases/update_package.yaml:

---
name: chatops.ansible_package_update
action_ref: st2_chatops_aliases.update_package
description: Update package on remote hosts
formats:
  - display: "update <package> on <hosts>"
    representation:
      - "update {{ package }} on {{ hosts }}"
      - "upgrade {{ package }} on {{ hosts }}"
result:
  format: |
    Update package `{{ execution.parameters.package }}` on `{{ execution.parameters.hosts }}` host(s): {~}
    {% if execution.result.stderr %}
    *Exit Status*: `{{ execution.result.return_code }}`
    *Stderr:* ```{{ execution.result.stderr }}```
    *Stdout:*
    {% endif %}
    ```{{ execution.result.stdout }}```
  extra:
    slack:
      color: "{% if execution.result.succeeded %}good{% else %}danger{% endif %}"
      fields:
        - title: Updated nodes
          value: "{{ execution.result.stdout|regex_replace('(?!changed=1).', '')|wordcount }}"
          short: true
        - title: Executed in
          value: ":timer_clock: {{ execution.elapsed_seconds | to_human_time_from_seconds }}"
          short: true
      footer: "{{ execution.id }}"
      footer_icon: "https://stackstorm.com/wp/wp-content/uploads/2015/01/favicon.png"

Вот она:

!update 'bash' on 'all'

Важная часть работы DevOps инженера — это улучшение процессов, делая работу разработчиков проще, общение в команде лучше, диагностику проблем быстрее за счет автоматизации и использования правильных инструментов, — все для того, чтобы сделать компанию успешнее.
ChatOps помогает решить эти проблемы совершенно новым, эффективным способом!

В завершение. Священная корова

Как вы знаете, у Ansible известная любовь к утилите cowsay. Давайте перенесем ее в ChatOps!

Установим для начала саму утилиту:

sudo apt-get install cowsay

Экшн actions/cowsay.yaml:

---
name: cowsay
description: Draws a cow that says what you want
runner_type: local-shell-cmd
entry_point: ""
enabled: true
parameters:
  sudo:
    immutable: true
  kwarg_op:
    immutable: true
  cmd:
    description: "Command to run"
    type: string
    immutable: true
    default: "/usr/games/cowsay {{message}}"
  message:
    description: "Message to say"
    type: string
    required: true

Alias aliases/cowsay.yaml:

---
name: chatops.cowsay
action_ref: st2_chatops_aliases.cowsay
description: Draws a cow that says what you want
formats:
  - display: "cowsay <message>"
    representation:
      - "cowsay {{ message }}"
ack:
  enabled: false
result:
  format: |
    {% if execution.status == 'succeeded' %}Here is your cow: ```{{ execution.result.stdout }}``` {~}{% else %}
    Sorry, no cows this time {~}
    Exit Code: `{{ execution.result.return_code }}`
    Stderr: ```{{ execution.result.stderr }}```
    Hint: Make sure `cowsay` utility is installed.
    {% endif %}

Вызов священной ChatOps коровы:

!cowsay 'Holy ChatOps Cow!'

Для справки: Все результаты выполнения команд можно посмотреть в панели управления StackStorm
https://chatops/ логин: demo пароль: demo
(замените hostname на IP если не воспользовались Vagrant демо):

Не останавливайтесь на достигнутом!

Это были простые, но боевые примеры использования. Более сложные вещи когда несколько DevOps инструментов соединены в динамический рабочий процесс будут показаны в следующих статьях. Здесь StackStorm демонстрирует всю свою мощь, принимая решения в зависимости от ситуации: это называется событийно-ориентированной архитектурой вроде самовосстанавливающихся после инцидента систем.

Если не нашли нужного функционала в StackStorm, предложите идею или добавьте Pull Request на GitHub (Python наш основной язык). Так же есть коммьюнити где можно задать вопрос или поделиться своим опытом: публичный Slack канал (с предустановленным демо ботом) и IRC: #StackStorm на freenode.net.

Спасибо за внимание, надеюсь получилось осветить особенности этого достаточно нового подхода в мире DevOps.
А для каких случаев вы бы использовали ChatOps? Прошу делиться идеями и историями (мы любим истории).