Хабрахабр

[Перевод] Garden v0.10.0: Вашему ноутбуку не нужен Kubernetes

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

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

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


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

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

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

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

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

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

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

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


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

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

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

Как так?

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

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

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

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

Как насчет CI?

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

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

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


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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть