В этой статье я бы хотел рассказать про свой личный опыт работы в качестве DevOps инженера, спустя 3 года работы. Безусловно можно долго говорить о сроках, различных кейсах и ситуациях. Но я хочу поделиться конкретными моделями взаимодействия программного обеспечения для начала в НЕБОЛЬШОЙ компании, а далее в КРУПНОЙ компании. Ну и в конце, как вишенка на торте, будет попытка сравнить эти 2 модели, оценить их минусы и плюсы, удобства и эффективность. Статья большая и ее кому-то возможно будет трудно читать, но я надеюсь на интерес.
DevOps Experience в малой компании
В первую очередь условимся, что малая компания — это компания, которая насчитывает менее 1000 сотрудников в штате. Итак, давайте перейдем к делу. Как таковых CI/CD практик изначально не было в явном виде. И связано это было с тем, что имелся определенный отдел системных администраторов, которые занимались установкой хотфиксов, тестировали в минимальном виде какой-то функционал командами в терминале, работу API элементарными запросами и т.д.
По факту все средства для реализации беспрерывной доставки и интеграции имеются. Весь код и бинарники хранились в SVN, исполняемый код компилировался на агентах TeamCity, и далее сборка выгружалась в качестве артефакта. Отчасти что-то хранилось в корпоративном Gitlab, который использовался различными командами менее активно. Инфраструктура была разношерстной, Windows + Linux использовался максимально активно. Один продукт сочетал в себе backend обработчики на Linux и весь Frontend на Windows.
Тестирование так же было реализовано с помощью TeamCity. Прежде, чем продукт собирался и выгружался как артефакт, для начала должны были быть реализованы все UI тесты, которые запускались автоматически, когда запускалась сборка продукта.
То есть схема была примерно такая:
Спринты были длиной в неделю. По прошествии этой недели ветка workspace сливалась в ветку trunk, так называемый предпродакшн, которая далее сливалась в ветку Prom. После чего запускалась таска на тимсити, которая выгружала Product Artifact уже с промовскими параметрами на файловую шару и проставлялась ссылкой в задаче Jira, для администраторов. Они уже в свою очередь вручную выкачивали обновленную версию продукта, разносили ее по всем нодам продукта и устанавливали. Согласитесь, такой подход не очень эффективен, но в виду небольших масштабов, управление продуктовыми системами было не очень сложным. Давайте оценим плюсы и минусы такой системы
Плюсы:
- Отсутствие явно оформленных pull-request-ов, что позволяет сразу отследить поведение продукта в тестовой среде и не ждать проверки коллег.
- Быстрая доставка кода в дев и тестовые среды.
- Эффективная проверка кода автотестами, которые запускаются в случае срабатывания VCS при любом коммите.
- Небольшие масштабы системы, которые управляются человеком.
- Простой дебаг.
- Простая логика в установке обновлений (ручная работа по инструкции).
- Интеграция Jira + TeamCity.
- Правильно настроенные зависимости. Продукт собирался в определенном порядке, например — сначала базы, далее бекэнд, и если предыдущие билды удачны, то только потом фронт.
- Простая в обслуживании схема интеграции с дев и тест средами.
- Вся информация о тестовых пользователях и значения для файлов конфигов (фронта и бека) хранилась в специальных мета-файлах конфигурации. В логике билдов с помощью Kotlin была реализована подстановка значений из этих конфигов.
- Схема Infrastructure-As-Code имеет массу преимуществ. Можно управлять средами с помощью кода — это прекрасно, быстро и удобно.
Минусы:
- Проверка кода осуществлялась одним человеком, максимум двумя, что могло повлечь за собой скрытые ошибки в коде, до которых не добрался проверяющий.
- Отсутствие алгоритма установки обновлений на ПРОМ среде, что влекло за собой ошибки при ручной установке.
- Отсутствие изоляции между продуктами, соответственно агенты были забиты разными продуктами.
- Проблемы хранения дистрибутивов и библиотек в одном лишь месте. Сильно раздутый SVN заставлял ждать сборки по полчаса, а то и больше.
- Вечные очереди на TeamCity.
- Слишком быстрое изменение продуктов, что не позволяло автотестерам успевать за изменениями и адаптировать тесты. Как результат часто красные тесты.
- Прерывная беспрерывная доставка — администраторы сами писали средства доставки и установки обновлений с помощью PowerShell в силу отсутствия доступа к настройке TeamCity. В итоге беспрерывная доставка обрывалась на этапе выгрузки артефакта на файловую шару, и возобновлялась скриптом администраторов, по запросу, и далее уже устанавливался (либо вручную, либо автоматически). Кстати, когда я и сам был администратором, то написал вот такую штуку — Автоматизация установки обновлений. Как раз из-за отсутствия удобных инструментов управления поставками.
Из явных минусов, которые сильно бросались в глаза перечислил вроде все. Тем не менее люди привыкли работать по такой схеме, хоть и неоднократно находились противники системы, но против толпы не попрешь. А я попер…
Меня бесил тот факт, что админам не дают нормальный инструмент установки обновлений, ведь когда-то я и сам был админом, который руками ставил поставки. В итоге я предложил все-таки обновлять промышленный контур с помощью TeamCity. Когда удалось этот момент продавить, был заказан отдельный сервер teamcity, для него 3 бесплатных агента, которые занимались только обновлением. Процесс сборки и тестирования остался на тимсити, который был привязан в SVN. Новый тимсити хранил операционный код в GitLab. Полная изоляция от конфигураций, только функции на PS.
Дополненная схема:
Это избавило администраторов от ручной установки обновлений на промышленных серверах, что на мой взгляд являлось прорывом. К тому же поддержка на уровне PS + Kotlin оказалась очень легкой.
Алгоритм такой схемы был примерно следующим:
- Таска на предпром ТС выгружает готовую ПРОМ сборку на файловую шару
- Разархивирует ее на ключевым серверах (каждый компонент на целевом сервере) в папочки product_component_new.
- Остановка веб-приложения/сервиса.
- Создание папки product_component_old — своего рода актуальный бэкап с предыдущей версией.
- Переименование папки product_component_new в product_component.
- Запуск веб-приложения/сервиса.
На удивление все эти этапы выполнялись быстро и без отказов. 40 секунд на обновление веб-приложения, и в районе 20 секунд обновление сервиса, базы данных обновлялись быстро с прикрученным Roundhouse — 10 секунд. Что удивительно нам подмаслили ситуацию тем, что было прикручено автоматическое переключение мастер-сервера, при обновлении нод. Соответственно, пока полностью не поднимался интанс на одной ноде, второй инстанс не выключался. Каждый инстанс компонента обновлялся поочередно.
Апогеем стало сравнение ручной работы, против реализованной схемы. Администраторы вручную занимались обновлениями продукта до получаса, но не менее 15 минут. При реализованной схеме прототипа CI/CD все это действо занимало не более 2 минут.
Более крупный продукт — более 50 серверов обычно обновлялся 90 и более минут скриптом на PS, написанным администраторами. При реализованной схеме процесс сократился до 12 минут. Результат на лицо. Я был очень рад достигнутым цифрам.
Безусловно были и ошибки, но их удавалось быстро исправлять, так как никто более не влезал в алгоритмы промышленных обновлений и можно было до идеала полировать оптимизацию и максимально быстро исправлять ошибки билдов.
Что я бы добавил?
- Во-первых установка софта на агенты. В качестве решения отлично подошел бы Ansible для более тонкой настройки тимситевых лошадок. К ансиблу впилил бы пакетный менеджер chocolatey.
- Разделение хранения кода, библиотек и дистрибутивов. В качестве решения для хранения кода я бы предложил bibucket — быстрая интеграция с TeamCity, отличный менеджмент кода от pull request-ов, до изолирования пользователей работать в определенных проектах. Для дистрибутивов и библиотек — 2 ноды Sonatype Nexus или другие внутренние репозитории.
Наверное на этом все. Теперь перейдем к крупной компании и софту, который используется внутри.
DevOps Experience в крупной компании
С ходу начать можно с того, что сильно бесит просто нереальное количество бюрократии и отсутствие свободы в технических мощностях. Понятное дело, что каждая копейка на счету, но иметь даже 1 сервер для тестирования новшеств — невозможно. Есть тестовые стенды, но команда DevOps-ов выступает в качестве поддержки софта, с учетом того, что у каждого проекта есть прикладной администратор. Но это уже мои тараканы… Давайте к инфраструктуре.
Около 1500 тимсити агентов. 3 TeamCity. Каждый агент привязан к своему пулу. Наличие такого понятия как проектная область. Это совокупность элементов системы в разных инструментах, работа которых интегрирована друг с другом. Доступ к проектам осуществляется при наличии определенных групп в ldap. Присутствует ldap синхронизация между различными сегментами (доменами).
Шикарное решение, для хранения кода и его менеджмента. Позволяет изолировать проекты друг от друга. Да и в целом инструмент является на мой взгляд если не лучшим, то точно одним из лучших в разработке. В том числе все наши конструкции, которые мы используем в работе хранятся там же.
Внутренние репозитории это вообще отличное решение для команд. Во-первых это изоляция от внешних атак. Во-вторых, каждый пользователь работает в своей проектной области. В-третьих — удобное управление версиями. 2 инстансах нексуса — один для дистрибутивов, второй для библиотек.
В отличии от ТС-а, который используется практически для всего, в малой компании, в крупной есть чёткое разграничение. Так например, нет никаких тестов, они выполняются в другом инструменте. Каждый продукт имеет свой пул агентов с необходимым для сборки набором софта.
Используется для подключения агентов к голове тимсити, инициализации в нужном пуле, для создания пользователя с ограниченными правами, предустановкой стандартного ПО и совсем недавно мы с помощью связки chocolatey + nexus +teamcity реализовали джобу по установке кастомного софта.
Пакетный менеджер, который по запросу дёргает и устанавливает софт из внутреннего репозитория, в качестве установщика были реализованы nuget пакеты, которые хранятся в нексусе.
Алгоритм использования:
- На голове тимсити описаны шаги по сборке дистрибутива из нексуса.
- В битбакете описан код самого дистрибутива.
- В нексусе хранятся дистрибутивы и необходимые для их работы модули.
- При коммитах тестировщиков и разработчиков, сборки стартуют только в своих проектах.
- Код берется из BB.
- Модули берутся из Nexus.
- Артефакт выгружается за агенте.
Давайте оценим плюсы и минусы работы и обслуживания такой системы.
Плюсы:
- Чёткое разграничение проектов.
- Отсутствие случайных ошибок из-за жёсткой изоляции.
- Отсутствие очередей на TeamCity.
- Сведение количества ошибок при сборках к минимуму.
- Чёткое разграничение инструментов по задачам.
- Наличие серьёзной системы менеджмента при коммитах.
- Лёгкая поддержка аварий из-за разграничения инструментов по задачам.
- Модель continuos upgrade. Любое новшество и обновление не затрагивает работу и доставку продукта на пром.
- Лёгкая масштабируемость.
- Простые в изучении инструменты. Честно говоря удалось все осилить за 2 месяца.
- Полная CI/CD модель.
Минусы:
- Большое количество инструментов и балансировщиков, что создаёт трудности поддержки на начальном этапе.
- Большое количество сегментов, которые тяжело поддаются мониторингу.
- Отсутствие центральной системы мониторинга всех инструментов в принципе.
- Забытые/простаивающие мощности. Многие сервера и агенты в конечном итоге начинают простаивают со временем потери тренда на продукт. Он начинает устаревать и выделенные мощности как результат используются не рационально.
- Много обсуждений целевой модели «Конвейера» и мало времени на саму работу.
- Отсутствие понятия Infrastructure-As-Code, что порождает проблемы при администрировании проектов в TeamCity.
Снова повторюсь, из явных и сильно бросающихся в глаза пунктов выделил вроде все. Безусловно такая система имеет больше преимуществ, нежели минусов в сравнении с системой в малой компании, но условиться можно на том, что выбор на софт падает исходя из задач и возможностей. Что я бы добавил? Больше свободы DevOps-ам, так как очень сильно закручены гайки относительно свободы действий. С технической точки зрения есть где разгуляться, так как нет предела совершенству и мы все об этом знаем.
Где на мой взгляд лучше?
Зарплату во внимание брать не буду, так как ответ очевиден. Относительно интереса — скажу, что есть в какую сторону расти и двигаться, что является одним из главным критериев лично для меня. Тяжело работать с большим потоком технических (и не очень) задач. Много времени работая в крупной компании приходится тратить на вопросы пользователей, но что самое интересное — в техническом плане, ты выполняешь не тривиальные задачи, а работаешь на улучшение системы. То есть ищешь пути решения каких-то технических ограничений или проблем, которые позволяют подойти к процессу творчески.
Про работу в малой компании — здесь тоже есть куда двинуться. Ведь многое вокруг тебя быстро устаревает, особенно если компания пользуется старыми «проверенными» решениями. Здесь меньше волокиты по согласованиям, тебе можно заказывать сервера под свои задачи. Соответственно ты можешь быстро и легко приносить новые решения, модернизируя систему и делая ее лучше. Но безусловно, одним из явных аргументов работы здесь для тебя будут деньги. Ты видишь свой прогресс, свое развитие, а платят тебе так же, как год назад, когда ты только пришел. Если тебя это устраивает, то набирайся опыта и продолжай проявлять инициативу. Ведь в крупной компании за тебя это будут делать начальники, которые «истинно правы».
Итог:
Для меня это очень интересный опыт и направление. Я не называю себя супер-крутым DevOps-инженером и некоторые решения, которые я узнал за последние 3 года были для меня открытием. Все дело в том, зачем вы гонитесь, за опытом, деньгами, интересом, впечатлениями? По сути каждый инженер этой сферы — двигатель прогресса. Наша задача облегчить коммуникацию тестировщиков, разработчиков и администраторов… Так было раньше, теперь наша задача сделать так, чтобы несколько кликов и хранящийся код превратились в продукт сразу в том месте, которое ему было выделено. И сделать это необходимо быстро. В этом и есть главный интерес. Лично для меня. Мне видится будущее в автоматизации ручных задач, я думаю что вся DevOps инженерия в целом движется в этом направлении, ведь на поддержку пользователей, есть служба поддержки пользователей.
Безусловно, инженеры всегда будут частью СПП, но и это мы когда-нибудь сможем автоматизировать. А что вы думаете по этому поводу? Если вам не хватает какой-то информации, задавайте вопросы в комментариях. В дальнейшем я обязательно вернусь более развернуто к вопросам взаимодействия компонентов между собой. Спасибо за внимание! Наша группа в ВК и YouTube-канал. Надеюсь вы под достоинству оцените эту статью 🙂