[Перевод] Ansible и ChatOps или как управлять 100+ серверами из чата
Что такое ChatOps?
ChatOps все еще свежее и редкое явление в мире DevOps, когда работа с инфраструктурой переносится в общий чат. Вы можете запускать команды прямо из чата, при этом разработчики/сисадмины видят что происходит в режиме реального времени, могут просматривать историю изменений, запускать свои команды, поддерживать коммуникацию вокруг работы и даже обмениваться опытом. Таким образом информация и рабочий процесс принадлежит всей команде —, а это несет в себе много преимуществ.
Можно придумать такие вещи как деплой кода или развертывание серверов из чата, просмотр графиков мониторинга, отправку SMS, управление кластерами или просто запуск shell команд. ChatOps может быть высокоуровневым представлением вашей действительно сложной CI/CD системы, неся простоту с помощью команды в чате вроде: !deploy
. Такой подход делает чудеса для улучшения видимости и снижения сложности вокруг процесса развертываний.
Улучшенный 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/armab/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
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 наш основной язык). Так же есть коммьюнити где можно задать вопрос или поделиться своим опытом, IRC:
#StackStorm
на freenode.net и публичный Slack канал, а еще мы любим GitHub ✮ звездочки.
Спасибо за внимание, надеюсь получилось осветить особенности этого достаточно нового подхода в мире DevOps.
А для каких случаев вы бы использовали ChatOps? Прошу делиться идеями в комментариях.