SSH vs DevOps

Традиционно в нашей компании отделы разработки и администрирования были разделены. По слухам, на то были вполне серъезные причины, но сие повествование не об этом. Весь мир движется в сторону методологии DevOps, хотя никто не понимает что это такое до конца. В этой статье я раскрою какие-то аспекты этого движения в нашей компании.

Что точно известно про DevOps:

  1. Нужно давать разработчикам больше доступа к operations, т.е. к тому как работает система в реальной жизни
  2. Нужно всё автоматизировать в широком смысле, и контейнеризировать, рассматривая последнее как частный случай автоматизации

Но перед тем как рассказать некоторые детали. Расскажу историю...

Мотивирущая история

Мы уже некоторое время разрабатываем свою систему выкатки проектов. Сегодня я взялся прикрутить её к нашим staging-серверам.

Для внешних пользователей поясню: мы используем "железные сервера", и соответственно ansible для выкатки базовой системы.

Значит беру я подготовленный админами playbook, добавляю туда одну из уже устоявшихся у нас ролей rsync. Накатываю этот playbook, чтобы проверить. И через минуту замечаю, что на машине был rsyncd.conf сделанный локально, не через ansible. И я его перетёр.

Восстановление заняло минут 40. Т.к. это были staging'и, впринципе никто сильно не прострадал. Кроме того, версия приложений, которая была запущена, продолжала работать. Сломался только CI который их обновлял. Но тем не менее проблема тут налицо.

Две школы Ops'ов

Мы вернёмся к истории позже. А пока стоит поговорить про извечный holy-war о том стоит ли разработчикам давать доступ к production-ceрверам.

Первая сторона говорит что, ни в коем случае не надо. Аргументируя это "принципом найменьших привилегий". Или тем что разработчики не достаточно грамотные. Или тем, что у них нет времени разбираться как оно там на production'е бывает. Или тем, что разработчик установит нужный пакет для своей
задачи, и не подумает про остальные проекты и другие сервера.

Вторая говорит -- обязательно надо. Как минимум только для чтения. Т.к. это дает возможность разработчику понять как работает система, и отлаживать сложные баги. Риск при этом достаточно низкий, т.к. код этого разработчика и так бежит в той же системе. Соответственно странно доверять разработчику код, но не доверять read-only SSH-доступ.

Есть даже организации, которые считают, что разработчики создающие приложения должны также дежурить в режиме 24х7, и принимать сообщения о поломках системы. Ну и конечно же быть в состоянии их починить. Таким образом считается что ошибки будут исправляться быстрее, а разработчики будут относиться к своей работе ответственней.

Вот например можно об этом починать на serverfault и на quora

Оба подхода ошибочны

Как правило если есть два противоположных подхода, считается что истина находится где-то по середине. Но в данном случае это не так.

Помните историю выше? Именно таких ошибок опасаются админы от программистов. Но именно такую же ошибку допустили сами.

По-этому правильный подход простой: SSH-доступа не должно быть ни у кого.

Ну ладно, я преувеличиваю. SSH-доступ должен быть у админов, но и они должны им пользоваться в совершенно исключительных случаях.

Жизнь без SSH

И так что делать без SSH:

  1. Выкатывать базовую систему с помощью ansible
  2. Проекты должны выливаться в контейнерах, по возможности в контейнерах вообще не должно быть bash'а (или какого бы то ни было shell'а)
  3. Всё окружение проекта должно быть фиксировано в конфигах, которые лежат в git'е
  4. Вся отладочная информация должна быть в:
    • Cистемных метриках
    • Метриках приложения
    • Логах

Тут стоит заметить, что да, ansible работает по SSH. И да, это допустимый способ использования SSH (просто как транспорт). То что не нужно делать ни админам, ни разработчикам (а именно этого они обычно просят) -- это интерактивные SSH сессии, где можно посмотреть процессы, файлы, TCP-соединения в данный момент и пр.)

Можно ли обойтись вообще без SSH?

С одной стороны опыт heroku, google app engine и других подобных решений, намекает что можно.

С другой стороны их ужасная огранниченность и редкое использование в жизни, как-бы этому противоречит. Даже, можно сказать, доказывая что так жить нельзя.

Но так или иначе это точка к которой мы стремимся. Возможно даже недостижимый идеал. Важно, чтобы мы делали правильные шаги. Подробнее чуть ниже...

Что есть сейчас?

Перед тем как перейти к интересному, давайте сделаем скучный перечень. Фактически он здесь для того, чтобы к нему обращаться при прочтении следующего раздела. Вот что у нас есть:

  1. У нас есть система сбора метрик cantal и система их отрисовки
    graphana. Cantal автоматически собирает базовые метрики по каждому контейнеру. По факту, собираем намного больше метрик, чем отображаем. Cantal, например, по-умолчанию собирает количество TCP соденинений на каждый порт в системе, или метрики TCP стека, такие как потеря пакетов.
  2. Cantal также позволяет фактически без накладных расходов передавать метрики приложения в graphana'у. По умолчанию передаются все правильно маркированные метрики.
  3. Система контейнеризации lithos не только делает контейнер независимым от внешнего окружения, но и заставляет конфигурировать все параметры запуска внутри контейнера, т.е. держать их в git'е.
  4. Система логирования syslog -> logstash -> kibana, для хранения и поиска по логам

Подумайте как сделать систему прозрачнее

Конечно, критичные баги нужно чинить быстро, и в случае необходимости даже заходить по SSH. Но, после того как баг починен сделайте следующее: подумайте какой должен быть инструмент, чтобы таки проблемы выявлялись быстрее.

Вот некоторые вещи которые можно сделать:

  1. Добавить дополнительных метрик в приложение. Например, добавить счётчик ошибок обращения к другому сервису. Это даст быстро понять что ошибки не в этом сервисе.
  2. Отслеживать количество занятых worker'ов, чтобы понять когда они все зависли ожидая ответа от сервиса в блокирующем режиме.
  3. Добавить дополнительный логгинг. Иногда метрик (количества событий в секунду не достаточно чтобы понять что же не так). Логи могут позволить получить большее информации. Хорошие логи, как правило делают strace не нужным в production'е.
  4. Добавить системных метрик. SSH-утилиты top, vmstat, netstat и множество других вполне хорошо заменяются метриками.
  5. Если есть ошибки которые не попадают в syslog (скажем инициализация системы логгирования сама по себе), нужно сделать возможность их ослеживания другими путями (например, забирать из файла утилитой rsyslog).

Важно после ошибок делать рефлексию. Анализировать не только метод их излечения и последствия, но и придумывать как подобные ошибки отслеживать в дальнейшем.

Чем метрики лучше ssh + some-command, спросите вы? Есть несколько вещей:

  1. Они будут работать после того как вы разлогинитесь
  2. Их можно остлеживать за длительное время, можно предсказывать многие ошибки зараннее
  3. Часто вы можете секономить время, применяя те же метрики в следущем проекте, и избежать наступания на те же грабли
  4. И в конце концов, вам не нужны специальные навыки, чтобы их посмотреть и при этом ничего не сломать. Вы даже можете сбросить прямую ссылку на них коллеге.

Итоги

Есть гораздо более правильная альтернатива SSH-доступу, а именно -- постоение полностью автоматизированной системы выкладки, и хорошей системы мониторинга проектов. Для её построения нужно вникать в детали возникающих проблем, и строить систему с учётом того, что такие проблемы могут возникнуть и в дальнейшем. Разработчикам нужно усовершенствовать инструменты для отслеживания системных ошибок в самом приложении. А команде operations делать доступнее, прозрачнее, и более контролируемым всё, что находится за пределами кода разработчиков.

Paul Colomiets

Read more posts by this author.