Что такое ChatOps?

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

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

Улучшенный ChatOps

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

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

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

План

Вначале мы собираемся установить контрольную машину, которая будет работать под Ubuntu. Затем мы настроим на ней 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 -s https://downloads.stackstorm.net/releases/st2/scripts/st2_deploy.sh latest | sudo bash

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

После завершения установки (а StackStorm тянет кучу Python пакетов, RabbitMQ, PostgreSQL, MongoDB, OpenStack), для простоты демонстрации отключите механизм StackStorm авторизации в файле: /etc/st2/st2/conf. Можно выставить в секции [auth] вручную enable = False, либо воспользоваться магическим хаком:

sudo sed -i '/^\[auth\]$/,/^\[/ s/^enable = True/enable = False/' /etc/st2/st2.conf

Далее перезагрузим StackStorm:

sudo st2ctl restart

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

Поставим необходимые плагины от StackStorm, связывающие Ansible и Hubot:

sudo st2 run packs.install packs=hubot,ansible register=all

Кроме самих пакетов, будет еще установлен и сам Ansible в Python virtualenv: /opt/stackstorm/virtualenvs/ansible/bin

Шаг 3. Установка Hubot

Установим Hubot и плагины: Slack и StackStorm, позволяющие запускать команды в Slack чате и перенаправлять их в st2. Цепочка выглядит так:

Slack -> Hubot -> StackStorm -> Ansible

Redis — место, где Hubot держит свои мозги. Понимайте как хотите, но мозги нам нужны:

sudo apt-get install build-essential redis-server

Hubot сделан на Nodejs, необходимая зависимость:

curl -sL https://deb.nodesource.com/setup_0.12 | sudo bash -
sudo apt-get install nodejs

Установка самого Hubot:

sudo npm install -g hubot coffee-script yo generator-hubot

Создадим персональную hubot сборку из-под stanley linux юзера (он ранее был создан StackStorm). В будущем мы будем запускать бота с правами stanley:

sudo mkdir -p /opt/hubot
sudo chown stanley:stanley /opt/hubot
sudo -H -u stanley bash -c 'cd /opt/hubot && echo "n" | yo hubot --name=stanley --description="Stanley StackStorm bot" --defaults'

Установим npm плагины hubot-stackstorm и hubot-slack:

sudo -H -u stanley bash -c 'cd /opt/hubot && npm install hubot-slack hubot-stackstorm --save'

Для того чтобы hubot-stackstorm подгружался при старте бота, добавьте запись hubot-stackstorm в файл: /opt/hubot/external-scripts.json:

sed -i 's/.*\[.*/&\n  "hubot-stackstorm",/' /opt/hubot/external-scripts.json

И наконец, можно запускать бота (не забудьте заменить API токен на свой):

cd /opt/hubot && HUBOT_SLACK_TOKEN=xoxb-5187818172-I7wLh4oqzhAScwXZtPcHyxCu ST2_WEBUI_URL=http://chatops:8080 PORT=8181 bin/hubot --name "stanley" --adapter slack --alias !

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

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

/invite @stanley

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

!help

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

!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:
  - "ansible {{args}}"

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

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

!pack deploy st2-ansible-aliases repo_url=armab/st2-ansible-aliases

где repo_url — ваш github репозиторий.

Теперь можно запускать простые 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, — здесь вся гибкость использования.

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:
- "status {{hosts}}"

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

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

!pack deploy st2-chatops-aliases repo_url=armab/st2-chatops-aliases

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


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

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

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

!service restart "gearmand" on "MQ-server"

Для этого в уже существующем 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:
  - "service restart {{service_name}} on {{hosts}}"

Результат:

И знаете что? Благодаря мобильному приложению 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:
  - "show mysql processlist {{hosts=db}}"

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

!show mysql processlist
!show mysql processlist 'db'

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

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

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

!show nginx stats on 'web'

Для этого создадим action, который запускает bash команду, 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:
  - "show nginx stats on {{hosts}}"

Спасибо 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: "20%"
  sudo: yes
  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
      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:
  - "update {{package}} on {{hosts}}"

Вот она:

!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:
  - "cowsay {{message}}"

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

!cowsay 'Holy ChatOps Cow!'

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

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

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

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

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