Garden v0.10.0: Вашему ноутбуку не нужен Kubernetes

Прим. перев.: С Kubernetes-энтузиастами из проекта Garden ^[1] мы познакомились на недавнем мероприятии KubeCon Europe 2019 ^[2], где они произвели на нас приятное впечатление. Этот их материал, написанный на актуальную техническую тему и с заметным чувством юмора, — наглядное тому подтверждение, а посему мы решили его перевести.

Он рассказывает о главном (одноименном) продукте ^[3] компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0 ^[4], в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.

Меньше всего я люблю работать с Kubernetes на своем ноутбуке. «Кормчий» поглощает его процессор и аккумулятор, заставляет кулеры вращаться без остановки и сложен в обслуживании.

Фотография со стока в тему для пущего эффекта

Minikube, kind, k3s, Docker Desktop, microk8s и т.д. — отличные инструменты, созданные для того, чтобы пользоваться Kubernetes было максимально удобно, и спасибо им за это. Серьезно. Но с какой стороны ни посмотри, ясно одно: Kubernetes не приспособлен для запуска на моем ноуте. Да и сам ноутбук не предназначен для работы с кластером контейнеров, разбросанных по слоям виртуальных машин. Бедняжка старается изо всех сил, но явно не любит это занятие, выказывая свое недовольство воем кулеров и норовя обжечь бедра, когда я опрометчиво ставлю его на колени.

Скажем же: ноутбуку — ноутбуково.

Garden ^[3] — инструмент для разработчиков, занимающий ту же нишу, что и Skaffold, и Draft. Он упрощает и ускоряет разработку и тестирование Kubernetes-приложений.

С момента самого начала работы над Garden, около 18 месяцев назад, мы знали, что локальная разработка распределенных систем — временное решение, поэтому заложили в Garden значительную гибкость и прочную основу.

Теперь мы готовы поддерживать как локальные, так и удаленные Kubernetes-окружения. Работать стало гораздо проще: сборку, развертывание и тестирование теперь можно проводить в удаленном кластере.

Короче говоря:

С Garden v0.10 можно полностью забыть о локальном кластере Kubernetes и по-прежнему получать быструю реакцию на изменения в коде. Всё это — бесплатно и с открытыми исходниками.

Наслаждайтесь одинаковым удобством при работе с локальными и удаленными средами

Привлек ваше внимание?

И я рад этому, поскольку у нас есть еще много любопытных фишек! Общее использование dev-кластеров имеет более масштабные последствия, особенно для совместно работающих команд и CI-пайплайнов.

Как так?

Прежде всего, внутрикластерный сборщик — будь то стандартный демон Docker или Kaniko, — а также внутрикластерный реестр являются общими для всего кластера. Ваша команда может сообща использовать dev-кластер, при этом кэши сборок и образы доступны всем разработчикам. Поскольку Garden присваивает теги образам на основе хэшей исходников, теги и слои определяются однозначно и непротиворечиво.

Это означает, что как только разработчик создает образ, он становится доступен для всей команды. Изо дня в день мы скачиваем одни и те же базовые образы и делаем одни и те же сборки на компьютерах. Любопытно, сколько трафика и электричества тратится впустую?..

То же самое можно сказать о тестах: их результаты доступны всему кластеру и всем членам команды. Если один из разработчиков протестировал некую версию кода, отпадает всякая необходимость повторно проводить тот же тест.

Другими словами, дело не только в том, что не нужно запускать minikube. Этот скачок открывает для вашей команды дорогу ко множеству возможностей по оптимизации — больше никаких лишних сборок и тестовых прогонов!

Как насчет CI?

Большинство из нас привыкли к тому, что CI и локальный dev — это два самостоятельных мира, которые нужно настраивать отдельно (и они не используют общий кэш). Теперь их можно объединить и избавиться от лишнего:

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

По сути ваша CI превращается в бота-разработчика, работающего в той же среде, что и вы.

Элементы системы; беспрепятственная разработка и тестирование

Можно существенно упростить конфиги CI-пайплайнов. Для этого достаточно запустить Garden из CI для сборок, тестов и деплоев. Поскольку вы и CI используете одно и то же окружение, вероятность столкнуться с проблемами CI гораздо ниже.

Копание в бесчисленных строках конфигов и скриптов, затем push'и, ожидание, надежда и бесконечные повторы… Все это в прошлом. Вы просто занимаетесь разработкой. Никаких лишних движений.

И чтобы окончательно прояснить ситуацию: когда вы или другой представитель команды собрал или протестировал что-то с помощью Garden, то же самое произошло и для CI. Если вы ничего не меняли после тестовых прогонов, то не нужно проводить тесты (или даже сборки) для CI. Garden все делает сам, а затем переходит к другим задачам, таким как организация среды предварительного запуска, pushing артефактов и т.д.

Звучит заманчиво. Как попробовать?

Добро пожаловать в наш репозиторий GitHub ^[3]! Устанавливайте Garden и играйтесь с примерами. Тем, кто уже использует Garden или желает познакомиться с ним поближе, предлагаем Remote Kubernetes Guide ^[5]. Присоединяйтесь к нам в канале #garden в Slack'е Kubernetes ^[6], если у вас есть вопросы, проблемы или вы просто хотите пообщаться. Мы всегда готовы помочь и приветствуем обратную связь от пользователей.

P.S. от переводчика

В скором времени мы также опубликуем обзор полезных утилит для разработчиков приложений, функционирующих в Kubernetes, куда помимо Garden попали и другие интересные проекты… А пока — читайте также в нашем блоге:

• «Kubernetes tips & tricks: о локальной разработке и Telepresence ^[7]»;
• «Плагин kubectl-debug для отладки в pod'ах Kubernetes ^[8]»;
• «Kubernetes tips & tricks: доступ к dev-площадкам ^[9]»;
• «Начало работы в Kubernetes с помощью Minikube ^[10]».

Автор: Васильев Михаил

Источник ^[11]