Как я написал свой ChatOps: опыт выпускника курса по Python
Меня зовут Константин Кулишов, я работаю DevOps-инженером в компании, которая предоставляет комплексное сопровождение клиента от разработки до поддержки и продвижения.
В этой статье я кратко опишу ChatOps и расскажу, как вдохновился и написал приложение https://github.com/KKulishov/chatops.
Почему нам понадобился ChatOps
Наша компания практикует современный стек в разработке и в поддержке. Мы используем оркестрацию контейнеров Kubernetes для крупных клиентов, в работе с которыми оправдана эта технология. Также мы используем облачные платформы, по согласованию с клиентом. В моем примере рассмотрим Yandex.Cloud.
Так как мы используем Yandex.Cloud, оплата почасовая и держать runner постоянно включенным финансово не оправдано. Его можно выключать с 20:00 до 9:00 и на субботу и воскресенье. Это неудобно, если разработчик хочет поработать в выходной или ему, как Менделееву, среди ночи пришло просветление. Ведь он захочет не только запушить свои изменения, но и увидеть результат своей работы на stage-ветке. Для таких целей и было реализовано приложение.
Нужен ли команде ChatOps — вопрос спорный. Каждая команда сама решает, насколько для них это ценная фича. В моем примере errbot используется с интеграцией в телеграм, чтобы перехватывать команды и выполнять их. Выбрал телеграм, потому что у нас в компании в нем все общение.
Мое приложение было создано для того, чтобы облегчить жизнь отделу разработки. Приложение может выводить логи миграции в БД. Вы можете сказать, что надо смотреть в Grafana, но у нас собираются логи через Fluent Bint и складываются в Elasticsearch, но когда приходит «failed» от job по миграции, разработчикам проще посмотреть через телеграм.
Вот часть примеров ситуаций, в которых нам помогает ChatOps. Напишите в комментариях, что вы решаете с помощью него.
Как я писал свое приложение
Знания по Kubernetes я черпал из книг, официальной документации и курсов. Последним, который я прошел, был курс от Слёрм по Python для devops-инженеров. Моей основной целью было систематизировать фундаментальные знания, и увидеть, как на практике взаимодействуют Python и Kubernetes.
Я решил чтобы что-то понять, нужно написать самому. Поэтому я решил использовать errbot, Kubernetes Client, Yandex API, Python-Gitlab.
Errbot используется для интерактивного взаимодействия в телеграме. С помощью Kubernetes Client я получаю логи миграции БД по namespace. Вызывается довольно просто:
/logs_migrated --namespace work
Логи берутся с отдельного пода, который выполняет задачи миграции, отбирается по (^pre-migrate-db-(.*) , где pre-migrate-db-xxxx имя пода), можно переопределить в plugins/err-prod/rights.py.
Yandex API использовал для запуска build_runner и поднятия его ресурсов. Пример ввода команд: /list build vm. Здесь выводиться список машин и их имена которые участвуют в build и их статус и описание тех. характеристик.
/start vm --name_vm buildfront (старт машины по указанному имени buildfront)
/stop vm --name_vm buildfront (стоп машины)
/upgrade vm --name_vm buildfront --core 4 --mem 8 (тут мы даем команду на увелечения до 4 ядер и 8 ГБ ОЗУ для машины под именем buildfront)
Нужно уточнить, что выборка машин из списка при вызове list build vm выбирает машины только те, которые начинаются со слова build, но это можно скорректировать в коде plugins/err-prod/mylib.py. Тут нужно уточнить, что выборка машин из списка при вызове list build vm выбирает машины только те которые начинаются со слова build, (отрабатывает след. регулярка ^build (.*)) , но это можно скорректировать в коде plugins/err-prod/mylib.py.
Чтобы запустить приложение, надо установить зависимости. Первое — это python 3.8 и выше. Потом установите:
pip3 install errbot errbot[telegram] paramiko kubernetes requests python-gitlab
git clone git@github.com:KKulishov/chatops.git && cd chatops
Дальше экспортировать переменные. Поскольку у меня и дома, и на работе Linux, я делаю так:
export ERRBOT_ENV="DEV"
Используется для отладки приложения, не запуская телеграм, просто в текстовом режиме консоли. Если нужен сразу telegram, вводим:
export ERRBOT_ENV="PROD"
API токен вашего бота:
export BOT_TOKEN="xxxxxxxxxxxxxxxxxxx"
Затем понадобятся данные по Яндекс API:
export CI_folderId="xxxxxxxxxxxxx" (переменная — ваш ID каталога в Яндекс.Облаке)
export CI_IAM_TOKEN="xxxxxxxxxxxx"
Если вы запускаете в режиме PROD, ID указывать не нужно, он сам возьмет, при условии, что приложение запускается на виртуальных машинах Yandex.Cloud и к машине привязан service account с полномочиями compute.admin. IAM_TOKEN выдаются не навсегда, а только на временной интервал. Токен для отладки можно получить через утилиту yc: iam create-token. Офф. доки по iam token API Yandex.Cloud в конце статьи.
Для взаимодействия с Kubernetes нужно создать service account, получить токен и сертификат. Прошу учесть, что кластерная роль view уже была создана.
kubectl create serviceaccount chatbot
kubectl create clusterrolebinding chatbot-cluster-view --clusterrole=view --serviceaccount=default:chatbot
значение вывод нужно указать в переменную тут указывается токен (где chatbot-token-xxxx имя Ваша секрета)
export KUBER_TOKEN_VIEWER=$(kubectl get secret chatbot-token-xxxx -o jsonpath="{['data']['token']}" | base64 -d)
а вот сертификат пришлось указать как физический файл
kubectl get secret chatbot-token-xj54b -o jsonpath="{['data']['ca\.crt']}" | base64 -d > plugins/err-prod/ca.crt
Тут можно было привязать его к service account в описании манифеста, когда приложение внутри кластера Kubernetes. Но вот для отладки (когда приложение еще не в кубере) мне показалось более наглядным.Тем более для локальной отладки можно использовать k3s или minikube.
Затем можно вызвать бота , командой:
errbot
В зависимости от того что вы выбрали: если DEV, то в качестве клиента будет использована командная строка (тут вызовы идут через знак! потом_команда):
А если PROD, тогда взаимодействия будет через Ваш telegarm bot, вот пример (через telegram вызовы команд идут через /) :
Вывод
Теперь разработчики могут быть не привязаны к рабочим и будним дням, и пушить изменения, с возможность сразу видеть результат своей работы на stage-ветке. Мы сэкономили на расходах в облаке и упрощаем жизнь команды разработки.
Весь код приложения с кратким описанием:
https://github.com/KKulishov/chatops
Официальные документы, которые использовал:
https://errbot.readthedocs.io/en/latest/
https://github.com/kubernetes-client/python
https://cloud.yandex.ru/docs/compute/api-ref/
https://python-gitlab.readthedocs.io/en/stable/
https://cloud.yandex.ru/docs/iam/operations/iam-token/create-for-sahttps://cloud.yandex.ru/docs/compute/api-ref/Instance/
Курс, который я проходил:
«Python для инженеров» от Слёрма.
Курс очень помог. Для меня официальный инструмент взаимодействия с Kubernetes через Python запутанный, а в доках https://github.com/kubernetes-client/python/tree/master/kubernetes/docs хоть и много примеров, но разобраться сложно. А на курсе можно писать преподавателю, он может не сразу ответить, зато разберет все нюансы. Темы насыщены полезными примерами, которые можно адаптировать под свои задачи. Хорошо описано взаимодействие с api через библиотеку requests, работа с errbot с реализацией управления ssh через paramiko, написание prometheus exporter.
Были и минусы: курсовые далеки от реалий, долгие стримы (там их было 3 по ansible, kubernetes и errbot), а я привык получать от Слёрма короткую и четкую информацию. Про Kubernetes была только одна неделя, это печально (хотелось бы больше выделенного времени по взаимодействию с api kubernetes). Надеюсь, авторы учтут мои замечания, потому что кроме них, курс один из немногих стоящих.
Книги, которые посоветовали во время прохождения курса:
«Изучаем Python», Марк Лутц том 1 и 2. Тоже очень помогли.
На этом все. Если статья будет интересна, могу добавить в Git репу описания dockerfile сборки и Kubernetes Chat описания ChatOps.