Прим. перев.: С Kubernetes-энтузиастами из проекта Garden мы познакомились на недавнем мероприятии KubeCon Europe 2019, где они произвели на нас приятное впечатление. Этот их материал, написанный на актуальную техническую тему и с заметным чувством юмора, — наглядное тому подтверждение, а посему мы решили его перевести.
Он рассказывает о главном (одноименном) продукте компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0, в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.
Меньше всего я люблю работать с Kubernetes на своем ноутбуке. «Кормчий» поглощает его процессор и аккумулятор, заставляет кулеры вращаться без остановки и сложен в обслуживании.
Фотография со стока в тему для пущего эффекта
Minikube, kind, k3s, Docker Desktop, microk8s и т.д. — отличные инструменты, созданные для того, чтобы пользоваться Kubernetes было максимально удобно, и спасибо им за это. Серьезно. Но с какой стороны ни посмотри, ясно одно: Kubernetes не приспособлен для запуска на моем ноуте. Да и сам ноутбук не предназначен для работы с кластером контейнеров, разбросанных по слоям виртуальных машин. Бедняжка старается изо всех сил, но явно не любит это занятие, выказывая свое недовольство воем кулеров и норовя обжечь бедра, когда я опрометчиво ставлю его на колени.
Скажем же: ноутбуку — ноутбуково.
Garden — инструмент для разработчиков, занимающий ту же нишу, что и Skaffold, и Draft. Он упрощает и ускоряет разработку и тестирование Kubernetes-приложений.
С момента самого начала работы над Garden, около 18 месяцев назад, мы знали, что локальная разработка распределенных систем — временное решение, поэтому заложили в Garden значительную гибкость и прочную основу.
Теперь мы готовы поддерживать как локальные, так и удаленные Kubernetes-окружения. Работать стало гораздо проще: сборку, развертывание и тестирование теперь можно проводить в удаленном кластере.
Короче говоря:
С Garden v0.10 можно полностью забыть о локальном кластере Kubernetes и по-прежнему получать быструю реакцию на изменения в коде. Всё это — бесплатно и с открытыми исходниками.
Наслаждайтесь одинаковым удобством при работе с локальными и удаленными средами
И я рад этому, поскольку у нас есть еще много любопытных фишек! Общее использование dev-кластеров имеет более масштабные последствия, особенно для совместно работающих команд и CI-пайплайнов.
Как так?
Прежде всего, внутрикластерный сборщик — будь то стандартный демон Docker или Kaniko, — а также внутрикластерный реестр являются общими для всего кластера. Ваша команда может сообща использовать dev-кластер, при этом кэши сборок и образы доступны всем разработчикам. Поскольку Garden присваивает теги образам на основе хэшей исходников, теги и слои определяются однозначно и непротиворечиво.
Это означает, что как только разработчик создает образ, он становится доступен для всей команды. Изо дня в день мы скачиваем одни и те же базовые образы и делаем одни и те же сборки на компьютерах. Любопытно, сколько трафика и электричества тратится впустую?..
То же самое можно сказать о тестах: их результаты доступны всему кластеру и всем членам команды. Если один из разработчиков протестировал некую версию кода, отпадает всякая необходимость повторно проводить тот же тест.
Другими словами, дело не только в том, что не нужно запускать minikube. Этот скачок открывает для вашей команды дорогу ко множеству возможностей по оптимизации — больше никаких лишних сборок и тестовых прогонов!
Большинство из нас привыкли к тому, что CI и локальный dev — это два самостоятельных мира, которые нужно настраивать отдельно (и они не используют общий кэш). Теперь их можно объединить и избавиться от лишнего:
Можно выполнять одни и те же команды в CI и в процессе разработки, а также использовать единую среду, кэши и результаты тестов.
По сути ваша CI превращается в бота-разработчика, работающего в той же среде, что и вы.
Элементы системы; беспрепятственная разработка и тестирование
Можно существенно упростить конфиги CI-пайплайнов. Для этого достаточно запустить Garden из CI для сборок, тестов и деплоев. Поскольку вы и CI используете одно и то же окружение, вероятность столкнуться с проблемами CI гораздо ниже.
Копание в бесчисленных строках конфигов и скриптов, затем push'и, ожидание, надежда и бесконечные повторы… Все это в прошлом. Вы просто занимаетесь разработкой. Никаких лишних движений.
И чтобы окончательно прояснить ситуацию: когда вы или другой представитель команды собрал или протестировал что-то с помощью Garden, то же самое произошло и для CI. Если вы ничего не меняли после тестовых прогонов, то не нужно проводить тесты (или даже сборки) для CI. Garden все делает сам, а затем переходит к другим задачам, таким как организация среды предварительного запуска, pushing артефактов и т.д.
Добро пожаловать в наш репозиторий GitHub! Устанавливайте Garden и играйтесь с примерами. Тем, кто уже использует Garden или желает познакомиться с ним поближе, предлагаем Remote Kubernetes Guide. Присоединяйтесь к нам в канале #garden в Slack'е Kubernetes, если у вас есть вопросы, проблемы или вы просто хотите пообщаться. Мы всегда готовы помочь и приветствуем обратную связь от пользователей.
В скором времени мы также опубликуем обзор полезных утилит для разработчиков приложений, функционирующих в Kubernetes, куда помимо Garden попали и другие интересные проекты… А пока — читайте также в нашем блоге:
Он рассказывает о главном (одноименном) продукте компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0, в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.
Меньше всего я люблю работать с Kubernetes на своем ноутбуке. «Кормчий» поглощает его процессор и аккумулятор, заставляет кулеры вращаться без остановки и сложен в обслуживании.
Фотография со стока в тему для пущего эффекта
Minikube, kind, k3s, Docker Desktop, microk8s и т.д. — отличные инструменты, созданные для того, чтобы пользоваться Kubernetes было максимально удобно, и спасибо им за это. Серьезно. Но с какой стороны ни посмотри, ясно одно: Kubernetes не приспособлен для запуска на моем ноуте. Да и сам ноутбук не предназначен для работы с кластером контейнеров, разбросанных по слоям виртуальных машин. Бедняжка старается изо всех сил, но явно не любит это занятие, выказывая свое недовольство воем кулеров и норовя обжечь бедра, когда я опрометчиво ставлю его на колени.
Скажем же: ноутбуку — ноутбуково.
Garden — инструмент для разработчиков, занимающий ту же нишу, что и 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! Устанавливайте Garden и играйтесь с примерами. Тем, кто уже использует Garden или желает познакомиться с ним поближе, предлагаем Remote Kubernetes Guide. Присоединяйтесь к нам в канале #garden в Slack'е Kubernetes, если у вас есть вопросы, проблемы или вы просто хотите пообщаться. Мы всегда готовы помочь и приветствуем обратную связь от пользователей.
P.S. от переводчика
В скором времени мы также опубликуем обзор полезных утилит для разработчиков приложений, функционирующих в Kubernetes, куда помимо Garden попали и другие интересные проекты… А пока — читайте также в нашем блоге:
