Comments 19
Нельзя Skype. На странице проекта отмечено, что MS закрыли API и нету гарантии работоспособности адаптера. Последний коммит 1 год назад!
В связи с Jabber внезпано пришла такая сумасшедшая вещь вроде умного дома:
— Поднимаем собственный Jabber сервер
— Настраиваем систему и команды
— Управляем домом из Jabber как с удаленного терминала
— Заставляем Jabber слать нам уведомления в зависимости от событий: «В доме выключили воду», «Кот запрыгнул на елку», «Позвонили в дверь в 15:32».

Можно собирать данные с сенсоров, вешать свои обработчики событий if -> then -> else, все на легко читаемом Python-e.
Потом дополнительно в веб-панель все завернуть, но терминал все равно надо оставить.

А если интернет временно не доступен на мобильном — как только появится, сообщение с Jabber-a все равно прийдет.

Есть такие паки для всякой электроники и IoT (интернета вещей):


Вплоть до какой-то промыленной автоматизации.
Конечно, идея прекрасная. Но, справедливости ради, она не нова.
И даже, давно проработана.
Не удивительно, — очень много одинаковых идей но с разной реализацией.
Можно кстати вкратце, какие-то примеры/ссылки, тк. я от электроники отошел лет 6 назад. Совсем не слежу, но интересно.

Я не думаю что мы пооффтопим здесь, речь об автоматизации.
Кстати есть человек который умный дом построил, взяв за контрольный центр st2 (те вся обработка событий построена на этой платформе, что фактически Yaml + Python). Камеры повсюду, сенсоры, админка для доступа извне, https, ключи авторизации (слышал еще пугает заходящих на территорию котов включением автополива газона, что тоже не ново).
Чат на node.js с NoSQL БД для управлению консолью, в которой запускается Ansible Playbook на Python, который управляет серверами по SSH, выполняя команды в их консоли. Брр, это уже какой-то перебор.
Я только ЗА Ansible — штука чертовски удобная для управления «зоопарком» серверов, но я категорически против 100500 новых точек отказа, горы потенциальных уязвимостей и отсутствующей непонятно какой безопасности доступа к такому чатику.
image
Да, вполне справедливый комментарий.
На самом деле много споров на эту тему в западном сегменте, есть аргументы как за так и против.

За:
  • Есть RBAC/Auth Hubot плагин.
  • Можно разрешить определенную группу команд кому надо, запретить кому не надо — очень эффективное и гибкое решение.
  • Можно ли сказать: вот я вам даю ключи и root, пожалуйста выполняйте только 3 команды. С ChatOps так можно сделать.
  • В чат-сервисах вроде Slack можно выставить 2-х факторную аутентификацию. Это значительно повышает безопасность. Учитывая что SSH ключи могут увести, — иногда ChatOps с 2х факторной бывает даже более безопасным решением на практике.

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

Против:
  • Чат сервис могут взломать. Но скорее всего вы об этом узнаете в новостях и вероятность что взломают Slack чтоб выполнять команды у вас на серверах — очень мала
  • Много прокладок и посредников (кстати интересно какая будет шумиха если взломают GitHub)
  • Насчет против думаю вы меня еще дополните. Вопрос интересный, хочется взглянуть со всех сторон.


Как безопасно приготовить ChatOps — это пожалуй целая тема для отдельной статьи.
Update по поводу безопасности:
В англоязычной ветке обсуждения справедливо заметили, что пример у HipChat есть корпоративная версия, те. чат полностью на своем сервере внутри организации.

В Slack enterprise версия «coming soon in 2015».

Скорее всего есть и другие сервисы с hosted версией.
Категорически согласен. Помимо кучи точек отказа, это просто игрушка. Решить серьезную проблему таким образом нельзя, а попытки ее решить таким образом отнимут много времени. Игрушка подойдет для саппорта, чтобы перезагружать сервисы. Каких-то других вменяемых кейсов я не вижу. Ansible — да, штука хорошая и приятная. Но это явно перебор. В последнее время растет количество каких-то неадекватных технологий. Люди сами стараются усложнять себе жизнь.
Люди стараются упрощать себе жизнь, и это получается.
Вот более серьезный пример: Autoscaling showcase (можно запустить на Vagrant).

Что происходит:
  • Начинается все с ChatOps команды: !asg create name=test domain=domain.com min_nodes=1 expand_by=1
  • Создается Autoscaling группа с серверами в облаке (тут цепочка действий)
  • Платформа слушает состояние серверов через NewRelic API (заменить на свой мониторинг)
  • Дальше происходит интересное, если какой-то сервер в группе падает:
    • 1. система получает триггер из NewRelic что какой-то из серверов упал
    • 2. убирает сервер из Autoscaling группы
    • 3. заменяет его на другой только что поднятый сервер

  • Система сама себя вылечила, вы спите спокойно. Profit!

Видео на английском (листать на 5 минуту, где начинается интересное).

Кстати человек бывший GitHub-овец. Можно конечно «обидить хужожника» и сказать что GitHub, Rackspace, Puppet labs, Box итд просто фигней занимаются с этим ChatOps, но коммьюнити сейчас делится на тех, кто это использует и тихонько получает c этого выгоду, и всех остальных.
Вот гитхаб с вами не согласится. Они с помощью бота не боятся управлять такими вещами как репликация mysql или роутинг.
Кстати, кто из крупных компаний точно использует ChatOps:

  • Github (сами придумали, — сами и используют)
  • RackSpace Сloud
  • Puppet Labs
  • Box.com
  • HP
  • много средних стартапов вроде 500px.com, Pagerduty, VictorOps итд.

Вероятно много других компаний используют или хотя бы пробуют в различных подразделениях (но не разглашают), потому что когда скорость реакции, производительность команды увеличивается в х3-х10 раз — это огромные для такого уровня бизнеса деньги.
Очень необычная идея, но вот практическая составляющая мне не понятна…
Коллега на работе рассказывал про возможность прикрутить к Астериску возможность запускать рандомные скрипты по добавочным номерам. Можно позвонить на номер фирмы, набрать добавочный код и выкатить новую ветку в продакшен :)))
Ребята, а как вы страхуетесь от выполнения неверной команды или скрипта, которая может на каком то из узлов что-нибудь испортить?
Как вы отлаживаете сценарии?
Хороший вопрос.

Отладка ChatOps команд и сценариев вручную:
Тестируем и хорошо проверяем в Vagrant и Docker: st2workroom, st2express ну и Code reviews, как обычно. Благо, благодаря декларативному подходу и вынесению высокоуровневой логики в Yaml файлы — читать и разбираться легче.

Автоматическое тестирование сценариев и команд:
Есть st2tests, дополнительные Acceptance тесты, когда платформа тестирует некоторые части самой себя с помощью самой себя (картинка выше напомнила). К примеру, вот тест, который проверяет процесс установки/удаления паков. Все это поставляется в виде отдельного пака, те тесты могут быть установлены из внешнего репозитория и запущены как обычный пак (плагин/расширение).

^^ Так же можно поступать для собственных сценариев, тестируя их своими же автоматическими тестами.
Итого, если делать все серьезно для продакшна, может получится 2 репозитория/пака: 1 с вашими командами и сценариями и 1 опциональный с тестами.

И последнее,
реальные команды — они чаще всего состоят из цепочек действий и условий (если случилось 1 -> значит делаем 2, потом 3, потом 4), те что-то массивное складывается в единую ChatOps команду. Чаще всего на продакшене таких команд немного, перепутать — трудно. Самое популярное — это деплой/развертывание.
То что указано в примере с uname -a из чата, когда можно выполнить любую shell конструкцию из чата — это только для простоты демонстрации. Обычно мало смысла такое ставить в продакшн.
Чтобы лучше понимать ChatOps.
Вот короткое (20 мин.), но очень энергичное видео о ChatOps опыте в GitHub (на английском):

ChatOps: Методология и Философия

Освещает такие вопросы:
  • Преимущества ChatOps
  • Использование в реально большой организации
  • C чего начать
  • Примеры из жизни
  • Вопросы безопасности
  • Что стоит делать с помощью ChatOps, а что нет


Only those users with full accounts are able to leave comments. Log in, please.