Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Нужен ли каждому разработчику свой dev-сервер? Многие компании, опасаясь лишних расходов и проблем, даже не пробуют внедрить такой подход.
CarPrice развернул свои dev-серверы еще в те далекие времена, когда все работало на монолите. А после монолита пилил собственный сервис для оркестрации dev-серверов на базе Docker, затем разворачивал их на Minikube и постепенно пришел к Kubernetes.
На связи ведущий инженер отдела DevOps CarPrice Михаил Чешуин. В этой статье я расскажу, как мы запускали dev-серверы в разные периоды — и как все работает сейчас
Сразу оговорюсь: нам сложно судить, насколько разработчикам и тестировщикам хуже живется без dev-серверов. Мы все-таки используем их почти 10 лет — все время, пока существует CarPrice. Но по этой же причине мы готовы долго говорить об их плюсах и преимуществах :)
Пара примеров:
Dev-серверы помогают организовать работу на удаленке и аутсорс: окружение не нужно поднимать локально на персональном ПК. Разработчику понадобятся только ресурсы для IDE, а тестировщику будет достаточно браузера и вспомогательного отладочного ПО.
Dev-серверы дают возможность запускать сервис в окружении других связанных с ним проектов в легко повторяемой конфигурации, максимально приближенной к продуктовой. Для архитектуры с несколькими сотнями сервисов это существенный плюс.
Правда, за удобство приходится платить: компании требуются дополнительные затраты ресурсов, чтобы развернуть полное окружение для каждого разработчика. Здесь важно учесть и аренду оборудования, и время сотрудников, которое уйдет на регулярные мониторинг и поддержку.
И все-таки мы считаем dev-серверы отличным решением для небольших компаний на 20–30 разработчиков. Особенно при использовании микросервисной архитектуры.
Мы разворачиваем dev-серверы столько, сколько существует CarPrice, и прошли уже несколько этапов «серверной» эволюции. Рассказываем, как это было и чему стоит поучиться на нашем опыте.
Эпоха монолита: 2014 – 2016
Когда CarPrice стартовал, у нас все работало на монолите, основанном на базе Bitrix. Там было легко развернуть dev-окружение, и мы подумали — почему бы не сделать это централизованно? Все-таки организовать каждому VPS со своим окружением явно удобнее, чем локально поднимать Bitrix.
Так мы и поступили — и это был настоящий win-win: разработчики и тестировщики получали нужные инструменты, а системные администраторы — простое обслуживание. В качестве примера: если новому сотруднику требовался стенд для разработки или тестирования, достаточно было поднять из образа дополнительный виртуальный сервер.
Кроме того, в то время у нас еще были сотрудники на аутстафе, и тут виртуальные dev-серверы тоже оказались очень кстати. Мы обеспечивали ими всю команду — более 40 человек.
При этом нельзя сказать, что все работало идеально. Если образ, из которого разворачивали dev-сервер, устаревал, окружение требовало доработки — каждый разработчик самостоятельно обновлял и допиливал сервер под свои нужды. Но в целом, мы были довольны. Даже с учетом доработки все это занимало куда меньше времени, чем установка и настройка окружения на каждой машине с нуля.
Свой оркестратор докера: 2016 – 2018
Постепенно CarPrice развивался и масштабировался. Вместе с сервисом разрастался монолит — в 2016-м мы начали распиливать его с прицелом на микросервисную архитектуру. Но так как распил монолита дело дорогое и долгое, через какое-то время у нас были и монолит, и микросервисы, запускаемые в docker-контейнерах. Весь новый функционал также разрабатывался в виде отдельных сервисов. Пришло время модернизировать dev-серверы.
Основной задачей было предоставить разработчику или тестировщику возможность запускать на своем стенде необходимый набор микросервисов — формировать условия, максимально приближенные к проду. В этом, собственно, и заключается логика использования docker-контейнеров. Оставалось решить, каким образом управлять их запуском и конфигурацией — с учетом большого количества сервисов и пользователей. Для монолита при этом также было решено собрать отдельный docker-контейнер и запускать его вместе с остальными сервисами.
Мы оценили возможности существующих инструментов и решили написать собственный оркестратор для управления docker-сервисами на dev-серверах. У сервиса был уникальный UI, с помощью которого сотрудники могли управлять деплоем docker-сервисов на своих стендах. Для этого достаточно было выбрать в интерфейсе необходимые параметры. После этого приложение dev-сервера формировало и стартовало файлы конфигурации docker-compose. Но это в идеале — на практике контейнеры могли не стартовать, а упасть с ошибкой. В решении, к сожалению, было немало багов.
Чтобы поддерживать существующий функционал и добавлять что-то новое, требовались серьезные усилия. Иногда, например, ресурсов физического сервера становилось недостаточно, потому что количество микросервисов постоянно росло. Аккаунт нового пользователя в таком случае приходилось переносить на другой сервер — это был болезненный и трудозатратный процесс.
Еще мы сталкивались с проблемой свободных tcp/udp-портов.
Во-первых, так как на одном физическом сервере было запущено много docker-сервисов, требовались уникальные порты для каждого контейнера. Но иногда на один порт по ошибке запускали два docker-композа.
Во-вторых, иногда возникали ошибки, и docker-композы продолжали работать, когда разработчик останавливал сервис. Эти запущенные контейнеры занимали порты, которые система управления считала свободными, и никто ничего не мог туда задеплоить. У разработчиков и тестировщиков не было доступа к ssh-консоли хост-системы, поэтому DevOps-инженеру приходилось заходить на сервер и вручную тушить старые контейнеры.
В целом, разработчики были довольны — у них все это время сохранялась возможность работать на отдельных dev-серверах. Но вот у DevOps-инженеров значительно прибавилось работы. На протяжении двух лет, не без мучений, мы поддерживали решение с собственным оркестратором. Но затем признали, что эксперимент пора сворачивать и переходить к поиску более современного и стабильного решения.
Поиск новых решений с Kubernetes. Minikube: 2018 – 2022
В 2017 году стала все чаще звучать идея, что будущее микросервисной разработки за Kubernetes. Мы были согласны с этой точкой зрения и начали использовать Кубер еще до того, как это стало мейнстримом.
Чтобы упростить процесс развертывания dev-стендов, решили запускать Minikube — упрощенную реализацию полноценного Kubernetes-кластера. Мы запускали на виртуальных машинах один экземпляр для каждого разработчика. Была проведена большая работа: вместо набора docker-compose-файлов для каждого сервиса разработали helm-чарты, все это поместили в общий репозиторий и обернули несколькими bash-скриптами для упрощения деплоя.
Несколько лет решение неплохо работало, разработчики были довольны универсальным и относительно простым процессом запуска новых сервисов в Kubernetes. Бонусом можно было пользоваться Lens или Okteto. Однако при этом мы повысили порог входа для новых сотрудников. Помимо навыков разработки теперь требовалось базовое понимание, как работает Kubernetes, умение писать и разбираться в helm-чартах и работать в консоли.
Постепенно микросервисов становилось всё больше, а с ними росло количество подов и контейнеров, запущенных в рамках одного инстанса Minikube. Мы начали выходить за пределы рекомендованных лимитов в 110 подов на узел. Попытались увеличить значение параметра max-pods в настройках kubelet. Это помогло ненадолго — вскоре мы уперлись уже в движок контейнеризации. Начались проблемы в работе docker runtime. Kubelet тоже начал сильно тормозить, не успевая обрабатывать возросшее количество кронджоб.
Сталкивались и с ограничениями самого Minikube. Например, встроенный в Minikube nginx-ingress-контроллер не поддерживал grpc-протокол, тогда как версия ingress-контроллера для стандартного Kubernetes без проблем позволяла его использовать.
В конце концов мы осознали, что исчерпали возможности виртуальных машин с Minikube.
Kubernetes: 2022 – настоящее время
К 2022 году мы пришли к выводу, что нам пора переходить на полноценный Kubernetes. Сейчас у каждого разработчика есть свой Namespace, куда он деплоит микросервисы.
При переходе с Minikube на большой Kubernetes мы кое-что изменили в привычных процессах. Например, стали использовать BGP (Border Gateway Protocol) для маршрутизации между внутренней сетью Kubernetes и нашей основной сетью, а также организовали доступ из VPN-сети к DNS Кубера. В результате разработчик может напрямую, по имени сервиса, обратиться к любому своему контейнеру. Настраивать сервисы с типом NodePort, как это было в случае с dev-серверами на Minikube, больше не требуется.
Еще нам пришлось заняться тюнингом самого Kubernetes, так как мы вышли за рамки небольших развертываний, в которых все работает из коробки. Например, мы меняли модуль, отвечающий за обслуживание правил по пропуску трафика на нодах. Оказалось, что при нашем количестве сервисов (~3 000!) модуль iptables, который успешно работает в prod-кластере, просто не успевает обновлять правила в кластере dev. В результате мы перешли на рекомендованный при таких нагрузках модуль IPVS.
Другой момент, который стоит учитывать при развертывании — квоты и лимиты ресурсов для контейнеров. Без выставления реквестов и лимитов планировщик Kubernetes раскидывает поды по нодам буквально как попало, и это вызывает дисбаланс по нагрузкам.
Также в переходе на Кубер может скрываться еще одна проблема — кронджобы.
У нас в dev-окружении используется большое количество кронджоб — у каждого разработчика есть определенный пул, запущенный в неймспейсе. Если для планировщика не задать никаких правил, он будет массово запускать поды на ноде Kubernetes, у которой больше ресурсов. Поскольку многие кронджобы запускаются раз в минуту, то kubelet (демон Kubernetes, отвечающий за жизненный цикл пода) оказывается сильно перегружен. Разработчик что-то деплоит, его под попадает на ноду с толпой кронджоб, и из-за нагрузки на kubelet приходится по несколько минут ждать старта пода.
Проблему можно решить с помощью общей метки app-type: cronjob и инструкций topologySpreadConstraints.
Вот пример использования:
spec: |
После такой доработки планировщик стремится равномерно распределять кронджобы по узлам Kubernetes. Допустимый перекос мы контролируем с помощью переменной cronjob_max_skew.
Без подстройки параметров sysctl на узлах Kubernetes также не обошлось. Как уже упоминалось, наши разработчики используют Okteto для разработки в Kubernetes. Okteto синхронизирует файлы между репозиторием на компьютере разработчика с подом. Количество файлов в некоторых проектах довольно велико, что влечет за собой исчерпание ресурса max_user_watches и max_user_instances на узлах Kubernetes.
Мы решили проблему увеличением максимумов на каждом узле Kubernetes:
fs.inotify.max_user_watches=100485760 fs.inotify.max_user_instances=1280 |
Что дальше?
В будущем мы обязательно продолжим дорабатывать решение с dev-серверами. Планируем применить подход GitOps к развертыванию dev-микросервисов: использовать движок ArgoCD. Это позволит контролировать весь жизненный цикл манифестов, развернутых в Kubernetes. В целом, мы стремимся привести dev-окружение к уровню, максимально близкому к продуктовому.
Еще в планах сделать stage с автоматическим обновлением и автоматическим прогоном всевозможных UI end-to-end, integration, performance и penetration тестов. Но это, конечно, уже совсем другая история — расскажем ее чуть позже ;)
Если вы только готовитесь развернуть dev-сервисы, мы на связи и готовы ответить на любые вопросы. А с теми, кто уже делает dev-серверы своим разработчикам, всегда рады обменяться опытом.
