Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда-то очень-очень давно помогал Jenkins, немного Vault, чуть-чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.

Самое время пройтись по каждому инструменту и рассказать, что с ним не так или почему возникают сложности с его применением в наших условиях.

Условия наши очень просты — это эксплуатация систем уровня MES в одном производственном направлении «Северстали».

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

История 1. Jenkins и все, все, все

Когда‑то много лет назад мы погрузились в волшебный мир Jenkins, который оказался настолько удивительным, что сразу как‑то и не нашлось причин от него отказаться. И тем не менее, ошибка номер один — это использование Jenkins для развёртывания ПО в нашей среде. Сегодня мы в нашей команде полностью от него отказались.

Всё же надо отдать должное этому инструменту. Он может практически всё, пусть это будет и не просто. Также он обладает великолепным и удобным UI. Из всех инструментов именно с Jenkins ваш Clickops будет самым приятным и незабываемым.

Даже если оставить культурную трансформацию, можно с уверенностью сказать, что он слишком сложный, а реализация интеграции между ним и GitLab делает конвейер слишком медленным и менее надёжным.

История 2. GitLab — наше всё

Вторая ошибка — это продолжение первой истории. Когда мы отказались от Jenkins, нам потребовался другой инструмент, самый лучший. Место Jenkins занял GitLab в части своего CI. Проблема с ним заключалась в том, что, применяя его, мы стали использовать те же подходы, что и в Jenkins: стали конфигурировать пайплайн визуальными средствами, стали добавлять все переменные для нашего супершаблона сборочной линии. Хорошо, что сразу отказались от программирования. Теперь же мы отказываемся и от конфигурирования с помощью переменных (на самом деле, мы отказываемся и от многих других вещей, но путь этот оказался тернист). Наверняка в архивных репозиториях где-то нет-нет да и встретится список переменных, да ещё и файл со скриптом какой-нибудь опытный умелец подгрузит. Скажет, что все так делают. Нет. Мы так не делаем. У нас здесь так не принято. 

История 3. Первое блюдо, которое почему-то подают холодным

Переходим к основному блюду — к оркестратору. Тут проблема заключается в том, что те парни, которые были до нас, оставили нам самый лучший инструмент на все времена — RKE. А сейчас выясняется, что установленная версия кубера устарела. Охотно верю. Хотя, если уж говорить откровенно, у нас с этим инструментом проблем нет. Ошибка номер три — мы не заложили ресурс по обновлению оркестратора в наших проектах MES. В мире легаси, из окна которого мы выглядываем, десяток‑другой лет эксплуатации одной версии программного продукта — это норма. Что ж, работаем с тем, что есть. 

История 4. Что за Helm!

Если Helm не использовал, значит, не видал красоты. С Helm всё вокруг становится приятнее. Добавил, что требуется, в папку.helm и о проблемах забыл. Хорошо, если проблемы забыли о тебе, но когда они возвращаются, приходится возвращаться и в папку.helm. Ошибка номер четыре — упаковке продукта не уделяли должного внимания. Теперь же эта упаковка выглядит, как «молодой Франкенштейн». Тут же и конфигурация для кубера, и настройки самого приложения, да ещё и среды, где оно разворачивается. Хорошо, что секретов нет. Для себя решили, что пока побудем с Helm-ом, а дальше двинемся своей дорогой.

История 5. Когда не хватило Vault-амперов

Куда делись секреты из прошлой истории? Здесь нужно упомянуть Vault. Система нужна для хранения секретов, вернее, чувствительных данных. По истечении некоторого времени у нас осталось твёрдое убеждение, что и данные наши не настолько чувствительные, да и способ их хранения не настолько удобный, как это заявлено. Поэтому ошибка номер пять — использовать инструмент, функциональность которого в наших условиях фактически оказалась невостребованной.

Отдельно поясню, что мне не нравится в нашей конфигурации Vault:

1. По дороге он конкретно так проливает секреты. Наши секреты теперь повсюду, но только не там, где ими можно удобно пользоваться. Тут стоит отметить, что речь ни в коем случае не идёт об утечках чувствительных данных. Если вас устраивает, как Kubernetes распоряжается вашими секретами, то и применение Vault вопросов не вызовет.

2. Интерфейс программы вызвал наше абсолютное разочарование. Понимаю, что вкусы у всех разные, и тем не менее.

3. Инструмент сконфигурирован очень неудобно. Неудобная авторизация через GitLab, неудобные пути, в которых зашиты названия кластеров и сервисов. Отчасти, я полагаю, что это следствие слабого UI.

История 6. Разработка, приятно познакомиться

Заканчивая блок проблем, посвящённых разработке, хочется отметить одну важную, на мой взгляд, вещь. Дело в том, что разработка для деплоя не представляет особого интереса. Наше кредо — это забегающий в проект на неделю девопс‑инженер. А дальше работайте с тем, что есть, сами. В будущем планируем разработке уделять больше времени. Хотя и сейчас стараемся контролировать параметры, которые разработка закладывает в систему. Код разработан, собран и развёрнут. Что дальше?

История 7. Вот здесь распишитесь

Следующая проблема — это логирование. У нас за это отвечает общий инфраструктурный инструмент Graylog. У нас там все логи наших приложений, их очень много. Поэтому нам для них всегда не хватает памяти. И не важно, что всего‑то нужна дополнительная капля‑другая мегабайт, для тебя в мире Graylog‑а нет ничего сверх семи или десяти отпущенных тебе дней. Вывод здесь неутешительный — когда запускаются проекты, требующие логирования, то всегда говорят о гибкости системы логирования, подобной Graylog, но забывают, что эта гибкость потребует от вас колоссальных ресурсов, которых на нефункциональные истории в проектах просто нет. Седьмая ошибка — уделять недостаточно внимания логированию и мониторингу.

История 8. Чашка с PAAS-ом

В прошлом абзаце мы вплотную подошли к проблемам использования платформенных сервисов. У вас, наверняка, есть платформа. У нас тоже есть платформа, туда коллеги кладут всё, что им любо‑дорого. Это не PAAS в чистом виде, но от работы этих сервисов напрямую зависит работа нашей функциональности. Следует отметить, что эксплуатацией этих сервисов занимаются другие команды. В нашем случае одним из таких сервисов стал брокер сообщений. Со временем влияние брокера стало таким значимым, что мы стали замечать цену его обслуживания. Восьмая ошибка, с которой мы столкнулись, — это дополнительные затраты на обслуживание подобных сервисов. Стоит отметить, что в итоге брокер мы включили в состав нашего приложения и не пожалели об этом. Не все внешние команды справляются с нашим требованием по уровню доступности сервиса для бизнеса.

История 9. Redis — это не овощ

Кстати, в наших проектах есть вещи, которые так и не успели уйти в платформу. Для примера возьмём базу данных, размещаемых в памяти, Redis. Для использования внешних компонентов, для которых нет команды эксплуатации, приходится накапливать собственную экспертизу, необходимо тратить дополнительные ресурсы. И пока мы разбирались и стабилизировали этот сервис, нас поджидали разные сюрпризы. Пожалуй, девятая ошибка – это недооценивать возможные затраты на такие компоненты. Периодически приходится к ним возвращаться, настраивать параметры, обновлять версии, конфигурировать требуемые ресурсы.

Вместо заключения. Обернулись посмотреть

Вот мы и подошли к концу нашего путешествия. Предлагаю продолжить делиться подробностями своихвесёлых и грустных историй в комментариях, можем пообщаться и в переписке или в следующих статьях. А здесь я хочу отметить, что десятая ошибка — это избегать поиска причин проблем и не делать из этого выводов. Когда найдена и устранена причина, тогда ошибка переходит в опыт. Мы оглядываемся и говорим: «Работаем с тем, что есть».