Краткий сказ о неудавшемся администраторе

И снова долго не писал, в этот раз больше двух лет получается. Вроде даже мыслей и клёвых штук вокруг много, но как-то не мог себя заставить, но надо, иначе совсем зачахну. Решил начать с простого, рассказа о последних полутора годах моей работы. А работал я системным админимстратором, вернее оперейшен (в бывшем и могучем - это называлось оператор ЭВМ), вообщем автоматизировал и поддерживал инфраструктуру для hosted/ondemand/saas версии Targetprocess. Под катом краткая история с рассказом/перечислением интересных тулов с которыми пришлось поработать или просто читать.

В начале краткая история. Если кто ещё помнит, раньше я много писал на Java и странно, что стал администратором. Targetprocess достаточно известная компания в Белоруссии, так как продуктовых компаний у нас не так и много. Сейчас правда называется Taucraft, открытых вакансий, к слову, много. Вообщем сходил на собеседование, мне очень понравилась команда, но вначале отказали. Но потом пригласили и в марте 2012 пришёл. Дали работать над скриптами деплоймента приложения. Оно кстати на .net, так что это были powershell. Но потом, по моему под впечатлением QCon London или какой-то другой конференции решили перейти на Сonfiguration Management Tool. Чёрт. Снова много подробностей, вообщем автоматизировал provision серверов деплоймент, мониторинг. Не сказал бы что это было интересно. Поначалу не плохо, тем более как я сказал работать пришлось в очень крутой команде. Но со временем, когда все кастомеры были переведены на новые сервера управляемые этим делом, очень уж очень много времени стало уходить именно на оперейшен задачи. Если до этого мало кодил, то со временем ещё меньше. Да и работать в крутой команде не верно, скорее работать рядом. Трудно учится у классных программистов, если ты вместе с ними не программируешь. Опять лирика. В результате через год в марте этого года решил уйти. Уйти когда только ты знаешь инфраструктуру очень сложно, но мы таки нашли замену (а для автоматизации windows инфраструктуры - это было архисложно сделать) и в следующем году я буду на новом-старом месте, так как адски боюсь/не люблю интервью просто согласился на первый (ладно второй, но Сбербанк реально стремная контора) офер в свою прежнею компанию. Вот такая история. А теперь немного обещанной инфы по тулингу с которым пришлось поработать. Для тех кто в теме, наверное, это банальности, но может кому пригодится.

Есть ещё люди конфигурирующие сервера вручную? По моему очевидно зло - долго и рутинно, можно ошибиться, маленький bus factor. Вообщем есть прекрасные штуки Puppet или Chef. Концепция у них проста - правила на DSL (кастомны или eDSL от Ruby) которые описывают состояние сервера. Например что пакет nginx должен быть установлен, файл конфига для него сгенерирован с определённого шаблона и т.п. На самом деле просто хорошо структурированый набор скриптов на Ruby. Главный наверно плюс - есть готовые модули. Например package - может вам установить пакет из десятка всевозможных форматов - deb, rpm или даже специфичные для языков как gems. Теплейтный движок для генерации файлов. Не вижу большого смысла много рассказывать. Штуки достаточно простые и уйма статей/видео про них в интернетах. Написаны на Ruby, по сему с помощью его же и кастомизируются. Как можно заметить - делались больше для NIX систем. Поддержка Windows появилась позже и была так себе, теперь уже лучше, но у нас например было много кастомного руби кода из-за этого. Но для NIX всё просто. А github просто забит кучей модулей которые автоматизируют работу с различными application серверами, базами данных и прочим. Как и любой открытый код - надо найти алмаз или помочь людям допилить, но в целом есть много очень хороших, тем более сами разработчики продуктов начинают делать puppet/chef модули. Кстати, то что у puppet специфичный язык стало незаметным плюсом, так как он распознаётся github и можно по нему искать модули Trending Puppet repositories on GitHub today. Недавно наткнулся на SaltStack, но сильно не изучал, если есть впечатления - расскажите. Мы используем puppet. В целом довольны. Но ruby конечно доставляет геморроя на Ubuntu и даже RVM иногда не спасает. По крайней мере последний puppet на последнем RVM у меня не завёлся. Но больше всего доставляет винда. Там нет стандартных пакетов, есть вроде msi, но его не все используют. Всё конфигурится по разному - реестр, файлы, и, о боже мой, иногда COM. bash нам только снится. Есть powershell но он ужасен. Надо 5 строчек чтобы установить права на файл. Не используйте винду на серверах, без шуток.

Puppet/Chef поможет вам поставить и сконфиругить Application сервер на кучи чистых серверов. Теперь вам надо задеплоить туда ваш продукт. Мы это делаем так же с помощью puppet. У нас есть более абстрактное, нежели puppet манифесты описание наших серверов, например, какие релизы на каких серверах стоят и puppet его использует для деплоймента. Мне это сразу не нравилось и сейчас не нравится. Есть плюсы конечно - puppet всегда работает и поддерживает все сервера в этом состоянии. Минусов тоже достаточно, так как деплоймент - это скорее синхронная задача. А puppet - это просто агент, который с некоторым интервалом прогоняет все скрипты, поэтому в них появились костыли. Для синхронных вещей есть тоже отличные тулы - capistrano/fabric. Первая на злополучном Ruby, вторая на няшном Python. Это тоже скрипты, но они могут соединяться с вашей машины на сервер по ssh и делать там полезные вещи. У нас есть приложение для сбора и рисования аналитических графиков на node.js и оно деплоится capistrano. Получилось достаточно удобно. Разработчик в своём репозитории вызывает cap deploy и магия. Практически так же как у него было, когда приложение хостилось в каком-то PaaS. Но, как я сказал, работает всё по ssh и для основного виндового приложения не очень подходит, windows... Кстати, некоторые и сервера полностью сетапят через fabric. Но мне кажется puppet удобнее так как он сам запуститься всюду, а fabric надо не забыть запустить как скрипт поменяешь. Но это дело вкуса.

Ещё немного про тренды в деплоймент - это Docker. Правда это контейнер для приложений, но он упрощает этот самый деплоймент. Использовать его пока не приходилось, но много смотрю и читаю про него (хайп сейчас огромный) - выглядит интересно. И есть ещё одна похожая модель, которая мне попалась в одной из презентаций про Amazon Web Services. Как известно облака и IaaS сейчас невероятно популярны. Машины там сетапятся с образов, поэтому можно можно один раз настроить заготовку и поднять с неё хоть десяток, хоть сотню машин. Имеет место быть. Но puppet скрипты - это ещё и документация. А что же вы там в образе настроили - поди вспомни потом. Тем не менее - концепция имеет право на жизнь и даже имя Immutable server.

Маленький абзац про то чего так и не сделал - стейт. Как я говорил - иногда нужна метаинформация о серверах - например роль сервера, каких клиентов обслуживает. У нас это храниться в git репозитории который puppet забирает на все машины. Так себе солюшен. Я в своё время присматривался. Есть классная штука на старой доброй Java - Zookeeper. Большой, сложный, но многие используют его - поэтому есть готовые рецепты как организовать координацию. Но на пятки ему наступает молодёжь на молодом языке Go - etcd - это не совсем координатор, скорее KV хранилище, которое бы отлично подошло для метаинформации расшареной между серверами. Недавно ещё на клёвую штуку в этой же группе и тоже на go нарвался Serf. Мне напоминает Finagle от twitter. Вообщем способ устроить взаимодействие распределённых нод (erlang программисты ухмыляются от всех этих zookepeer'ов). На сайте проекта приводятся use cases как его использовать в роли zookepeer и даже puppet (но это уже перебор, хотя сделать свой puppet на его базе было бы интересно, а то ruby иногда на коня садит).

Сервера настроены, приложение работает. Надо бы это дело мониторить. Сразу советую NewRelic. У него один недостаток - стоит кабанских денег. Можно выбить скидок, но все равно много. Это мониторинг и лёгкий профайлинг самого приложения. Поддерживает много платформ/языков. Его профайлинг составляющая на производительности приложения сказывается не сильно, максимум 3-5% по моим замерам, но даёт отличные трейсы, медленные запросы в базу. Вообщем попробуйте однозначно. В дополнения может снимать немного железной информации с серверов - cpu, ram, io, net. Недавно прикрутили ещё для мобильников, не знаю, не используем. А совсем недавно сделали это всё платформой. Теперь можно делать свои плагины и сабмитать туда значения, а они по ним построят графики и будут хранить. Отдельных денег пока не просят. Уже много готовых плагинов для баз данных например. Если бы они это сделали два года назад... А так мы используем ещё один мониторинг, куда снимает больше инфы по железу и разной кастомной статистики. Эта ужасная тула и я её упоминать не буду, но она хорошо заточена под винду. В отличии от более вменяемых и популярных zabbix, nagios и иже с ними. Вообщем с мониторингом одно правило - снимайте как можно больше инфы, потом пригодится (главное не положите при этом сервер, у нас такое бывало - не смешно). Ещё пара интересных проектов в этом ключе. Keen - позволяет сабмитать им метрики и потом их анализировать и строить графики. Пробовал только для тестов - удобно, но работает только у них. А если вам надо такую штуку локально - то может пригодится (молодой) проект InfluxDB - это "distributed time series database". Вообщем можно туда загружать метрики и потом строить аналитику sql-like запросами. Оптимизирована как раз для временной информации.

Логи. С этим у нас плохо. Я знаю решения, и сейчас по пятницам, которые у нас отведены в свободное плаванье, если есть свободное время пытаюсь сделать. Солюшен очень популярный в интернетах - грузить их в ElasticSearch и у них есть отличный интерфейс для визуализации и поиска Kibana. Для загрузки есть классная штука Logstash - фактически это ETL (extract-transform-load) для логов - может потреблять контент из разных источников, например, лог файл, парсить/фильтровать и обрабатывать и загружать его, например, в упомянутый elasticsearch. Не обязательно так. Но это очень просто и удобно. log -> logstash -> elasticsearch -> kibana. Я правда по другому пытаюсь сделать, это тоже есть в рекомендуемых, logger адаптер который сабмитит логи в Redis, а logstash уже с ним работает. Потому что на винде конечно logstash не так шикарно работает. Но не только им едины, если вам не понравилось, я ещё видел неплохую альтернативу - Flume, но оно только в HDFS грузит и придётся иметь дело с замороченным Hadoop.

Status.IO - чтобы сделать доступную статус страницу для вашего сервиса. Я свою на коленке на scala/play слепил и в heroku бросили. Но потому что тогда этот сервис был очень сырой. Сейчас у них наконец можно слепить очень кастомный дизайн и они научились забирать метрики с NewRelic. Сейчас бы я попробовал его использовать. Хотя правда не такие они и HA, недавно падали... Но чтобы вовремя через эту статус страницу проинфомировать пользователей и всё быстро пофиксать - нужны алерты. У нас это рассылают описанные выше системы мониторинга. Не очень удобно, много попотел и все равно не достаточно гибко всё настроено. Я бы посоветовал Riemann.IO - позволяет обрабатывать потоки данных - агрегировать, фильтровать и т.п. В двух словах не описать, посмотрите примеры. Написано на clojure, поэтому их "powerful stream processing language" для тех кто не боится скобочек. Но штука действительно стоящая и не только для алертов, но и любой потоковой обработки событий (ещё есть Storm - вот он уже совсем общий фреймворк). Алерты посылать советую в Pagerduty. Это сервис координации. Я его использую, хотя нам он не сильно надо, так как в 99% случаев я реагирую на алерты. Но если у вас команда. Этот сервис позволит организовать например расписание дежурств и смс если что упало будет отсылать только дежурному. Мне он удобен как конвертов email в смс по определённым правилам.

Это всё были общие системы. Но многие продукты обладают этим всем но только заточным под себя - тот же Hadoop, на котором поднялась Cloudera и Hortonworks, которые делают системы для его развёртывания и мониторинга. Или вот у нас есть MongoDB и приходится использовать их сервис мониторинга. Собирать это в свои мониторинг тулы тоже можно - но надо попотеть и время, а там всё работает, но получается уже третья мониторинг тула, что плохо. Так что да, интеграция всего этого многообразия задача ещё та.

Спасибо кто до читал до конца, надеюсь нашли полезную ссылку для себя, а меня надеюсь это побудит дальше писать.