Контейнеры: технологии и процессы глазами разработчика

Слушайте выпуск на подкаст-площадках

Предлагаем вашему вниманию запись и расшифровку дискуссии.

Сергей Зинкевич. Для чего контейнеры разработчикам?

Михаил Гудов. Контейнеры решают две основных задачи в разработке. Первое — это повторяемость окружения, а второе — это центральный артефакт для деплоймента. Это решение в ситуации, когда разработчик что-то сделал локально и у него все работает, но после того, как он передает разработанный код инженерам, и код не запускается, никто не знает, как и в каком приложении этот код запускать. Сейчас стандартом в разработке является передача разработчиком Docker-файла инженерам, который они запускают и таким образом доставляют код.

Василий Колосов. Мне кажется, что все началось с удобства для разработчиков в локальной среде. Они могут просто воспользоваться Docker-образом, чтобы подключить небольшой сервис, запустить микро-Postgres или очереди. При этом им не приходится думать о том, что нужно ставить какие-то пакеты, что-то забирать и т.д. Можно просто все сделать в локальной среде. Это уже стало стандартом, а еще в 2018 году часто работали по старинке и не использовали контейнеры.

Михаил Гудов. В 2018 году еще не произошла индустриальная революция, и люди писали на Ansible, «раскатывали» приложения на виртуалках, готовили планы отката и т. д. Все меняется. Пришли новые технологии.

Сергей Зинкевич. Итак, есть стандарт, когда разработчики отдают все в Docker-образах. А насколько разработчику нужно знать, как работает Docker и оркестратор? Или мы просто все пакуем в Docker-ы и дальше инженеры по инфраструктуре разбираются самостоятельно?

Михаил Гудов. Если разработчик разбирается в чем-то большем, чем кодирование алгоритмов, он, как минимум, будет более востребованным на рынке. При этом степень погружения разработчика в Kubernetes и, в принципе, в оркестратор не должна быть на уровне инженера, который может развернуть Kubernetes. Проще сказать, что не нужно разработчику.

Разработчику точно не нужно знать, как установить Kubernetes, как настроить компоненты Kubernetes и при каких условиях они лучше работают, как и знать, в каких условиях лучше работает controller manager или API server. Разработчику это не важно и не очень нужно. Разработчику не нужно знать, как конфигурировать компоненты внутри кластера, например, Ingress Controller или DNS. Разработчику не обязательно, но важно знать про инфраструктурные ограничения в кластере, например, иметь понятие о ресурсах, CPU, памяти, знать, что есть админы, которые определяют ограничения и управляют ими в кластере; важно знать о таких объектах, как LimitRange или ResourceQuota, которыми админы управляют и могут распределять их между неймспейсами. Разработчик, в особенности Java-разработчик, в любом случае столкнется с тем, что закончились лимиты, потому что у контейнеров в поде Kubernetes, как правило, ограниченное и не всегда большое значение по ресурсам. Такие вещи разработчику знать не обязательно, но полезно, как и то, что в кластере существует авторизация и аутентификация, что есть права и механизм RBAC, с помощью которого админы могут разделять доступ и управлять им и который можно использовать в своем приложении, чтобы написать собственный механизм авторизации.

Сергей Зинкевич. Получается довольно много. Может быть есть иное мнение? Как это устроено в компании Smartex и какие требования предъявляются к компетенциям разработчиков, в том числе к знаниям об инфраструктуре?

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

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

Сергей Зинкевич. Разработка — это же про скорость и «фичастость», а эксплуатация — про надежность. Это два разных полюса. Когда это две разные команды, то понятно, как это работает, — мы друг против друга делаем один продукт. А когда это один человек, он не разрывается?

Василий Колосов. Я не согласен, что разработчики про time to market, а эксплуатация про надежность. Все зависит от философии и культуры в команде. У нас например с первого дня культивируется настрой на time to market и скорость доставки. Состоявшийся релиз — это важно, и бизнесу это важнее всего на ранних стадиях проекта. Разумеется, когда вы уже разрослись и несете ответственность перед миллионами покупателей, продукт естественным образом начинает перетягивать одеяло на себя, и стабильность играет более важную роль. Поэтому вопрос о выборе между time to market и новыми фичами с одной стороны и надежностью с другой должен учитывать этап развития продукта.

Вопрос из чата. Как провести границу ответственности между разработкой и эксплуатацией, между разработчиком и DevOps-инженером?

Михаил Гудов. Нельзя сказать, что команда разработки ответственна только за код. Она ответственна за сервис полностью. Если разработчик выкатил сервис, а с ним что-то не так, он должен разобраться в причине. Если проблема с базой данных, он должен обратиться к админам базы данных или найти человека, ответственного за этот сервис. Поэтому я не думаю, что есть четкое разграничение. В идеале хотелось бы, чтобы разработчик мог выкатывать код без участия инфраструктурной команды или команды эксплуатации. Но для этого нужны совместные усилия.

Например, если есть платформа оркестрации, разработчик вместе с админом настроил роутинг, и что-то произошло в субботу с его приложением, то сам Kubernetes его починит, разработчику не придется ничего делать. При этом разработчик не ставит платформу и не знает, что происходит внутри Kubernetes или OpenShift. Это утилитарный процесс деплоя. Разработчику не нужно настолько глубоко погружаться в контейнеры, в оркестрацию, в Kubernetes или Nova, верхнеуровневых знаний точно хватает.

Однако нужно понимать, как делать приложение, которое ты будешь запускать. Например, есть такой старый гайд — золотой стандарт, который называется Twelve-Factor Application. Это набор стандартов, определяющих, как должно выглядеть приложение, которое можно горизонтально масштабировать, например, приложение, которое размещается в облачной инфраструктуре. Если у вас появился Kubernetes — платформа или «голый» Kubernetes, вам стоит прочитать этот гайд. Это относится не только к разработчикам, которые делают SaaS-приложение, но и к Ops-ам, которые будут этим приложениям управлять и его поддерживать.

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

Сергей Зинкевич. Orion soft делает контейнерную платформу, т. е. инфраструктурный продукт, которым пользуются инфраструктурные инженеры. Smartex делает, в основном, мобильные приложения и веб-приложения, т. е. работает с конечными, а значит самыми требовательными пользователями. Уровень требований к продуктам компаний разный. Есть ли отличия в разработке или неважно, в какой компании работать CTO?

Василий Колосов. Специфика, конечно, диктует и состав команды, и процессы, и внимание к разным деталям процесса. Я не занимался разработкой инфраструктурных продуктов, но я представляю, что там процессы тестирования, планирования фич и разделения задач учитывают специфику. А в Smartex есть большой процесс, который касается продуктового дизайна — как продукт будет выглядеть и восприниматься. Сейчас у нас в одном большом проекте 300 экранов в Figma и целая дизайн-команда.

Сергей Зинкевич. А у Orion soft есть экраны в Figma?

Михаил Гудов. Да, но немного, 4-5. Но конечно мы тоже заботимся о UX. Василий Колосов. Кроме того, у нас очень много общения между командами. Но это не фронтенд против бэкенда, они вместе. Я думаю, что в Orion soft объем задач бэкенда порядка 90%.

Вопрос из чата. В чем преимущества Nova Container Platform по сравнению с Vanilla Kubernetes?


Михаил Гудов. Можно использовать Vanilla Kubernetes, это сейчас модно. Но, если ты ставишь «голый» Kubernetes, у тебя появляется огромный объем автоматизации рутинных задач; тебе придется строить инфраструктуру вокруг Kubernetes, включая хранилище секретов, хранилище образов; нужно будет поставить мониторинг, логирование и тому подобное. Это целый пул компонентов, которые нужно правильно разместить и настроить. Если у тебя стоял Zabbix, нельзя просто поставить Kubernetes, и все заработает. Не заработает. Kubernetes можно использовать для решения определенных задач, но он не вполне функционален.

Не стоит забывать о том, что платформа оркестрации не только включает в себя много компонентов под различные задачи, она еще и модульная. Универсального инструмента не существует, и можно отказаться от использования одного инструмента и добавить другой, но при этом систему переделывать не придется. Сейчас сложно представить, как разработчики будут пользоваться «голым» Kubernetes. Для создания современного приложения не обойтись без Opensearch, мониторинга, Prometheus, Grafana, потому что приложение должно куда-то писать логи, за ним нужно следить и т. д. Поэтому нужна платформа.

Возвращаясь к тому, что нужно знать разработчику, стоит обратить внимание на базовые абстракции Kubernetes — Pod, Deployment, StatefulSet, ReplicaSet, Jobs, CronJob. Это все нужно знать, потому что это описывает приложение и как оно будет работать в кластере. Я думаю, что, когда ты используешь микросервисную архитектуру, ты все равно будешь писать свой манифест, и задачи у тебя будут похожие.

Сергей Зинкевич. Итак, в Smartex 300 экранов в Figma, а в Orion soft — 4-5. Какая доля бэкенд-задач?

Михаил Гудов. В Orion soft это правильней назвать инфраструктурными задачами. У нас среди разработчиков половина — сильные инженеры. Когда мы рисовали нашу веб-консоль (а она у нас очень красивая — не хуже чем в OpenShift), мы привлекали разработчиков, у которых не было инженерных знаний работы с бэкэндом. А сейчас разработчики имеют верхнеуровневое понимание этой темы и знают базовые абстракции. Они понимают, что если после запуска приложения есть поды в пендинге (pending), нужно в веб UI посмотреть describe деплоймента. Когда разработчик может хотя бы попытаться определить первопричину, то уменьшается количество общения с инженерной командой, разработчик может и сам что-то починить, и знает, к кому обращаться за помощью. Не обязательно забираться в дебри, разбирать ядро Linux или знать механизм cgroups, важно знать базовые вещи.

Василий Колосов. Мы в Smartex — больше разработчики. У нас тоже есть инфраструктурные проекты, но по большей части наши DevOps-ы обеспечивают инфраструктуру проектов, которые мы разрабатываем. Я не могу себе представить ситуацию, когда мы будем использовать «голый» Kubernetes. Время каждого Ops-а настолько на вес золота, что везде, где есть возможность, мы пользуемся только управляемым Kubernetes, ускорителями и готовыми решениями, чтобы запускать сервисы и делать как можно меньше шаблонных вещей.

Ценность не в том, что ты можешь настроить своими руками «голый» Kubernetes, а в том, как быстро ты это сделаешь. С точки зрения бизнеса это просто накладные расходы. Kubernetes — это commodity, для которого надо использовать софт, умеющий хорошо это делать. Умные люди уже все за нас придумали, наступили на все грабли, подготовили везде соломку, и можно об этом не думать. Мы полностью придерживаемся этого подхода, потому что он позволяет нам предлагать клиентам лучший сервис.

Например, у нас есть клиент, Picvario, с которым мы прошли очень долгий путь (сейчас это ведущий продукт в России среди систем класса Digital Asset Management). Мы начинали с Docker Compose, когда продукт был еще на ранних стадиях, и им пользовались три клиента. В какой-то момент потребовалось перейти на Kubernetes. Нагрузка повышалась, и мы столкнулись с тем, что очень сильно плавает загрузка по транскодингу, потому что загружаемое медиа приходилось перекодировать, сжимать, готовить к стримингу, делать несколько вариантов картинок, прогонять AI-задачи и т.д. При этом инфраструктура была мультитенантная, т. е. продуктом пользовалось много компаний в изолированных пространствах, но в рамках одной инфраструктуры. Нагрузка была нерегулярная.

Я отчетливо помню момент миграции на Kubernetes, когда всем разработчикам пришлось вникать в основные объекты, разбираться, как залезть в консоль и посмотреть, что сломалось и т.д. Я уверен, что, если бы разработчики не погрузились в работу Kubernetes, мы бы провозились с нашим продуктом намного дольше. Нам пришлось переводить приложения на эти 12 принципов, все, что было stateful, делать stateless, решать задачу загрузки (upload) файлов, чтобы не грузить их в папочку, и т.д. Именно разработчики, которые вникли в суть работы контейнерной платформы в целом и Kubernetes в частности, обеспечили успех этой миграции.

Сергей Зинкевич. Когда вы разрабатываете, имеет значение, где вы работаете — на серверах on premise, в облаке в своей преднастроенной инфраструктуре. Или, поскольку Smartex пользуется только Managed Kubernetes, вам подходят только публичные облака?

Василий Колосов. Только публичные облака, потому что это наибольшая экономия времени и максимальная надежность. Иногда «считаешь на салфетке» и кажется, что дорого. Можно арендовать серверы, поставить их в дата-центр или арендовать в разных ЦОД, и все будет работать. Но, если вы не огромная компания или если нет специфических требований к большому количеству дешевых вычислительных мощностей и вас не волнует выход из строя 1-2 серверов, нет причины не пользоваться публичными облаками, потому что за нас уже столько вещей придумали и сделали. Мы как разработчики настолько развращены управляемыми сервисами, что с этой иглы слезть очень сложно.

Михаил Гудов. С одной стороны, все уже к этому привыкли, и есть гораздо более простые вещи, чем Managed Kubernetes. Я всегда думал, что облака — это очень сложная штука, где есть IaaS, PaaS, но это тебя не избавляет от необходимости иметь человека, который будет управлять твоим кластером Kubernetes, например. И ты должен ему заплатить. С другой стороны, провайдер берет на себя все риски по стабильности. Поэтому это вопрос, скорее, религиозный. Если мне нужно что-то получить быстро, я бы точно не ставил инфраструктуру к себе, если нет критических данных, которые нужно хранить на своих серверах, или жестких регуляторных требований. Все зависит от задач, которые надо решать.

Кажется, мы сошлись во мнении, что «голый» Kubernetes ничего не решает, т. е. его можно использовать, если очень хочется, но уже есть Managed Kubernetes и контейнерные платформы. Порог вхождения разработчика в Kubernetes не такой большой — курсы и документация. В этом необходимо разбираться, потому что никто не даст волшебную кнопку. Если ты не хочешь в этом разбираться, бизнес получит махину, которая все усложнит, а time to market станет больше. За Kubernetes или за платформой, в составе которой Kubernetes, нужно постоянно следить.

Василий Колосов. Мы делаем небольшое исследование Customer Development, и я общаюсь с большим количеством СТО и фаундеров в стартапах на ранних стадиях. Что у такого стартапа есть кроме time to market? Все, что им нужно делать, это показывать какой-то traction и time to market и бежать как можно быстрее. Им, разумеется, надо писать код, но от того, чтобы бежать быстрее, их отделяет инфраструктура, окружение, как это туда попадает и т. д. При этом ни у одного из них нет в штате DevOps-а просто потому, что они его не могут себе позволить. У них есть небольшое количество инвестиционных денег и план. Они стоят перед выбором — нанять человека, который поставит 10 кнопок и сделает продукт, который можно показать, или человека, который будет заниматься инфраструктурой. Поэтому в реальности задачи по инфраструктуре приходится брать на себя техническому директору, тимлиду или одному из разработчиков. При этом, как правило, Kubernetes там не пахнет, по крайней мере, в десятке компаний, с которыми я общался. Все в контейнерах, но в лучшем случае у них есть Docker Compose, за рубежом — AWS, в России — облако, но арендуется виртуалка, на которой что-то запускается.

А как был бы прекрасен мир, в котором даже в такой ситуации стартапам на ранней стадии был бы доступен Kubernetes и его возможности без какой-то «накладухи». Вопрос в том, что их от этого отделяет — только изучение Kubernetes или все же они опасаются связанной «накладухи»? У меня пока нет ответа на этот вопрос.

Михаил Гудов. Да, мне кажется, что про «накладуху» ты отметил верно. Многие люди, принимая решение, ориентируются на маркетинговые материалы. Например, ты приобрел Rancher или поставил OpenShift, но что если эта сложная система откажет в самый нужный момент, и никто не сможет этим управлять. Я бы при создании небольшого стартапа максимально все упрощал и, возможно, отказался бы даже от Docker Compose. В AWS, если я не ошибаюсь, есть еще более простое решение и оно набирает обороты. Многие промышленные решения представляют собой overhead для бизнеса. Платформы такого уровня, как разрабатываем мы, — это для среднего бизнеса и выше, для больших нагрузок, где много команд, очень много контейнеров, постоянно ведется разработка и нужно «докидывать» новые фичи и т. п.

Сергей Зинкевич. Наверно, нужно, чтобы разные команды использовали единые практики? Если у меня большая компания с множеством команд, мне хотелось бы, чтобы они были более или менее похожи друг на друга.

Михаил Гудов. Все зависит от того, какую задачу ты решаешь. Тебе дают очень большой инструмент, и ты сам решаешь, как его использовать. Например, у тебя есть стенд, и он должен быть стабильным, а тебе нужно протестировать feature branch, который с высокой вероятностью этот стенд сломает. Ты поднимаешь рядом под со своим микросервисом на load balancer, пишешь роутинг, что запрос приходит и в хедере запроса есть x feature branch = name, и все запросы попадают на этот микросервис, где ты их тестируешь, а остальные запросы без такого заголовка идут на стабильный сервис. Это своего рода сокращение time to market и решение множества проблем разработки, особенно когда очень много команд. 

Василий Колосов. Разработчик должен хорошо понимать эти концепции в Kubernetes, чтобы что-то такое сделать. Это ведет уже к канареечным релизам и более сложным деплойментам.

Сергей Зинкевич. Насколько важен time to market? Тот же Picvario был на этапе, когда пользователей ноль, а идея — огонь. Что Smartex делает для time to market? Как выбрать, где важна скорость, с какого момента важна надежность и где надежность становится важнее?

Василий Колосов. Это большая проблема DevOps-отделов. DevOps — как городской телефон, который должен всегда работать, и все к этому привыкли. Люди больше фокусируются на новых фичах, сроках, когда они будут выкатываться, а DevOps никогда не должен подвести. Инфраструктура — это что-то незыблемое и всегда в тени. Но когда что-то происходит, все начинают паниковать. 

Если есть хорошо отлаженная инфраструктура, настроенный Software Development Life Cycle, CI/CD, когда в Kubernetes все шаблонизировано, установлены хорошие стандарты и отлажена маршрутизация, в этом случае мы минимизируем проблемы, связанные с доставкой и эксплуатацией. Мы всегда считаем, что инфраструктура не должна подводить или задерживать, потому что у нас достаточно проблем с разработкой. Инфраструктура — это реальные герои, которые не носят плащи и о которых мы вспоминаем только когда что-то сломалось, но они важны настолько, что это необходимое условие для минимальных показателей time to market. Поэтому, чтобы добиться результатов, сначало надо обеспечить инфраструктуру.

Михаил Гудов. DevOps — это не роль, а целая культура, и от того, как она выстроена, зависит очень много. Люди, которые занимаются инфраструктурой, нужны и должны быть молодцами. Но важна не только инфраструктура, когда ты разворачиваешь оборудование и ресурсы, но и возможность для разработчика управлять инфраструктурой, на которой он размещает свое приложение. Разработчик, на самом деле, может вообще ничего не знать про эти абстракции, Kubernetes или как описывать деплоймент, но ему достаточно дать какой-нибудь универсальный YAML, а если приложение сложное, можно воспользоваться шаблонизатором. Он может написать health checks, управлять ресурсами, пробами и т. п. Это тоже очень важно. И то, и то должно быть хорошо.

Сергей Зинкевич. Получается, что вы делаете разные продукты с точки зрения конечных пользователей, но у вас очень много общего.

Михаил Гудов. Я готовился нападать на разработчиков и говорить, что они все должны знать. Я думал, что буду «плохим полицейским», но мы подозрительно во многом сходимся.

Сергей Зинкевич. Сегодня мы пытались разобраться, зачем разработчикам знать контейнеры, Dockers, Kubernetes. Это существующая реальность для разработки и настолько упрощает наши подходы, настолько нас сближает с командой эксплуатации, что основные абстракции знать необходимо. Это нам позволяет управлять в том числе архитектурой приложения и быстрее договариваться внутри команды. Команды фронтэнда и бэкенда уже не игнорируют друг друга в чатах, а работают вместе, а день релиза — общее событие, и мы должны договариваться. Получается, что мы учим Docker, Kubernetes и готовимся все размещать в Managed Kubernetes или на managed-платформах или использовать специализированные платформы. 

Василий Колосов. Помните кривые адаптации технологии? Все «долины отчаяния» для контейнеров и Kubernetes уже пройдены. Это новый стандарт, и если разработчик не будет в это вникать, можно остаться за бортом. Без хорошего понимания этой части просто не получится приносить ценность команде, и есть риск превратиться в обузу или просто мешать процессу. Value будет только тогда, когда все хорошо представляют, как все устроено, как работает, как эксплуатируется, как будет запускаться. Поэтому берем курсы и записываемся на семинары.

Михаил Гудов. Мне кажется, что платформы избавляют от огромного количества ненужных раздумий, например, как загружать сертификаты в Kubernetes – за тебя уже подумали и дали cert-manager. Сергей Зинкевич. Получается, что мы жизнь постоянно упрощаем, а разработчиков нам все не хватает и не хватает.

Василий Колосов. Системы становятся сложнее.

Михаил Гудов. Системы становятся сложнее, а разработчики как писали круто, так и пишут. Но система все равно становится сложнее. Ты разворачиваешь приложение, и тебе уже хочется в моменте видеть, как оно работает, под какой нагрузкой, какие там ошибки. Обязательно будут регуляторные требования, требования ИТ-безопасности, как и у всех больших компаний. Тебе хочется автоматизировать все, что связано с поддержкой разработки, и не только доставку кода, но и его сопровождение и эксплуатацию. Важна модульность, если ты хочешь доработать конкретный продукт, но платформа в целом тебя устраивает. Продукты действительно становятся сложнее, и их надо как можно быстрее доставлять на рынок. И разработчик может доработать, например, какую-то фичу в виде нового приложения за пару дней, нажать кнопку, и все уже в продуктиве, а компания получает прибыль.

Василий Колосов. Мы уже не успеем в полном объеме коснуться темы отладки, но у нас на проекте Picvario разработчики погрузились в Kubernetes, в первую очередь, чтобы понять, что не работает, и посмотреть, например, логи пода, какие события происходили в этот момент в кластере, почему то, что должно было реплицироваться, не реплицировалось, какие условия или триггер не сработал и т. д. Если этого всего не понимать, как отладить свой код даже не в продакшене, а в тестовой среде? В реальности 10% времени мы код пишем, а 90% времени его отлаживаем и чиним.