- PVSM.RU - https://www.pvsm.ru -
Современный подход к эксплуатации решает множество насущных проблем бизнеса. Контейнеры и оркестраторы позволяют легко масштабировать проекты любой сложности, упрощают релизы новых версий, делают их более надежными, но вместе с тем создают и дополнительные проблемы для разработчиков. Программиста, в первую очередь, заботит его код: архитектура, качество, производительность, элегантность, — а не то, как он поедет в Kubernetes и как его тестировать и отлаживать после внесения даже минимальных правок. Посему весьма закономерно и то, что активно развиваются инструменты для Kubernetes, помогающие решать проблемы даже самых «архаичных» разработчиков и позволяя им сосредоточиться на главном.
В этом обзоре представлена краткая информация о некоторых инструментах, которые упрощают жизнь программисту, чей код крутится в pod’ax Kubernetes-кластера.
Этот плагин для kubectl позволяет создать внутри интересующего pod'a дополнительный контейнер, который будет делить пространство имен процессов с остальными контейнерами. В нем можно производить отладку работы pod'а: проверить работу сети, послушать сетевой трафик, сделать strace интересующего процесса и т.п.
Также можно переключиться в контейнер процесса, выполнив chroot /proc/PID/root
— это бывает очень удобно, когда нужно получить root shell в контейнере, для которого в манифесте выставлен securityContext.runAs
.
Инструмент прост и эффективен, так что может пригодиться каждому разработчику. Подробнее о нём мы писали в отдельной статье [2].
Идея этой оснастки заключается в запуске контейнера с приложением на локальном пользовательском компьютере и проксировании всего трафика из кластера в него и обратно. Такой подход позволяет вести разработку локально, просто изменяя файлы в своей любимой IDE: результаты будут доступны сразу же.
Плюсы локального запуска — удобство правок и моментальный результат, возможность отлаживать приложение привычным способом. Из минусов — требовательность к скорости соединения, что особенно заметно, когда приходится работать с приложением с достаточно высоким RPS и трафиком. Кроме того, у Telepresence есть проблемы с volume mounts в Windows, что может стать решающим ограничителем для разработчиков, привыкшим к этой ОС.
Мы уже делились своим опытом использования Telepresence здесь [5].
Утилита позволяет синхронизировать содержимое локальной директории с каталогом контейнера, запущенного в кластере. Такой инструмент отлично подойдет для разработчиков на скриптовых языках программирования, основная проблема у которых — доставить код в работающий контейнер. Ksync призван снять эту головную боль.
При однократной инициализации командой ksync init
в кластере создается DaemonSet, который используется для отслеживания состояния файловой системы выбранного контейнера. На своем локальном компьютере разработчик запускает команду ksync watch
, которая следит за конфигурациями и запускает syncthing [7], осуществляющую непосредственную синхронизацию файлов с кластером.
Остается проинструктировать ksync, что и с чем синхронизировать. Например, такая команда:
ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/
… создаст watcher с именем myproject
, который будет искать pod с меткой app=backend
и пытаться синхронизировать локальную директорию /home/user/myproject/
с каталогом /var/www/myproject/
у контейнера под названием php
.
Проблемы и примечания по ksync из нашего опыта:
overlay2
в качестве storage driver для Docker. Ни с какими другими утилита работать не будет..stignore
[9] для того, чтобы указать пути или шаблоны файлов, которые не нужно синхронизировать (например, каталоги app/cache
и .git
).--reload=false
.$HOME/.ksync/ksync.yaml
.Данный инструмент предназначен для отладки процессов непосредственно в pod'ах. Утилита проста и в интерактивном режиме позволяет выбрать нужный отладчик (см. ниже) и namespace + pod, в процесс которого нужно вмешаться. В настоящее время поддерживаются:
Со стороны IDE поддержка есть лишь в VScode (с помощью расширения [11]), однако в планах на текущий (2019) год значатся Eclipse и Intellij.
Для отладки процессов Squash запускает на узлах кластера привилегированный контейнер, поэтому необходимо сперва ознакомиться с возможностями безопасного режима [12] во избежание проблем с безопасностью.
Переходим к тяжелой артиллерии — более «масштабным» проектам, призванным сразу закрыть многие потребности разработчиков.
NB: В этом списке, безусловно, есть место и нашей Open Source-утилите werf [13] (ранее известной как dapp). Однако мы уже не раз писали и рассказывали о ней, а посему решили не включать в обзор. Для желающих ознакомиться с её возможностями поближе рекомендуем прочитать/послушать доклад «werf — наш инструмент для CI/CD в Kubernetes [14]».
Решение от одноименной компании, предоставляющей managed-кластеры с Kubernetes для командной разработки. Утилита была создана для коммерческих кластеров, однако отлично работает и с любыми другими.
При запуске команды devspace init
в каталоге с проектом вам предложат (в интерактивном режиме):
Dockerfile
(или сгенерировать новый) для создания контейнера на его базе,
После всех этих подготовительных действий можно начинать разработку, выполнив команду devspace dev
. Она соберёт контейнер, загрузит его в репозиторий, выкатит deployment в кластер и запустит проброс портов и синхронизацию контейнера с локальным каталогом.
Опционально будет предложено перейти терминалом в контейнер. Отказываться не стоит, потому как в реальности контейнер стартует с командой sleep, а для реального тестирования приложение требуется запускать вручную.
Наконец, команда devspace deploy
выкатывает приложение и связанную с ним инфраструктуру в кластер, после чего все начинает функционировать в боевом режиме.
Вся конфигурация проекта хранится в файле devspace.yaml
. Помимо настроек окружения для разработки в нем же можно найти описание инфраструктуры, похожее на стандартные манифесты Kubernetes, только сильно упрощенные.
Архитектура и основные этапы работы с DevSpace
Кроме того, в проект легко добавить предопределенный компонент (например, СУБД MySQL) или Helm-чарт. Подробнее читайте в документации [16] — она несложная.
Эта утилита от Google претендует на то, чтобы покрыть все потребности разработчика, чей код так или иначе будет запускаться в кластере Kubernetes. Начать пользоваться им не так просто, как devspace'ом: никакой интерактивности, определения языка и автосоздания Dockerfile
здесь вам не предложат.
Впрочем, если это не пугает — вот что позволяет делать Skaffold:
Workflow в различных вариациях декларативно описывается в файле skaffold.yaml
. Для проекта можно также определить несколько профилей, в которых частично или полностью изменять стадии сборки и деплоя. Например, для разработки указать удобный для разработчика базовый образ, а для staging и production — минимальный (+ использовать securityContext
у контейнеров или же переопределить кластер, в котором приложение будет развернуто).
Сборка Docker-контейнеров может осуществляться локально или удаленно: в Google Cloud Build [20] или в кластере с помощью Kaniko [21]. Также поддерживаются Bazel и Jib Maven/Gradle. Для тегирования Skaffold поддерживает множество стратегий: по git commit hash, дате/времени, sha256-сумме исходников и т.п.
Отдельно стоит отметить возможность тестирования контейнеров. Уже упомянутый фреймворк container-structure-test предлагает следующие методы проверки:
ENV
, ENTRYPOINT
, VOLUMES
и т.п.).Синхронизация файлов с контейнером осуществляется не самым оптимальным способом: Skaffold просто создает архив с исходниками, копирует его и распаковывает в контейнере (должен быть установлен tar). Поэтому, если ваша основная задача — в синхронизации кода, лучше посмотреть в сторону специализированного решения (ksync).
Основные этапы работы Skaffold
В целом же инструмент не позволяет абстрагироваться от Kubernetes-манифестов и не имеет какой-либо интерактивности, поэтому может показаться сложным для освоения. Но в этом же и его плюс — большая свобода действий.
Как и Skaffold, Garden нацелен на автоматизацию процессов доставки кода приложения в K8s-кластер. Для этого сперва необходимо описать структуру проекта в YAML-файле, после чего запустить команду garden dev
. Она сделает всю магию:
Основной упор при использовании этого инструмента делается на совместное использование удаленного кластера командой разработчиков. В этом случае, если какие-то стадии сборки и тестирования уже были сделаны, это значительно ускорит весь процесс, поскольку Garden сможет использовать закэшированные результаты.
Модулем проекта может быть контейнер, Maven-контейнер, Helm-чарт, манифест для kubectl apply
или даже OpenFaaS-функция. Причем любой из модулей можно подтянуть из удаленного Git-репозитория. Модуль может определять (а может и нет) сервисы, задачи и тесты. Сервисы и задачи могут иметь зависимости, благодаря чему можно определить последовательность деплоя того или иного сервиса, упорядочить запуск заданий и тестов.
Garden предоставляет пользователю красивый dashboard (пока в экспериментальном состоянии [24]), в котором отображается граф проекта: компоненты, последовательность сборки, выполнения задач и тестов, их связи и зависимости. Прямо в браузере можно просмотреть и логи всех компонентов проекта, проверить, что выдает тот или иной компонент по HTTP (если, конечно, для него объявлен ресурс ingress).
Панель для Garden
Есть у этого инструмента и режим hot-reload, который просто синхронизирует изменения скриптов с контейнером в кластере, многократно ускоряя процесс отладки приложения. У Garden хорошая документация [25] и неплохой набор примеров [26], позволяющих быстро освоиться и начать пользоваться. Кстати, совсем недавно мы публиковали перевод статьи [27] от его авторов.
Разумеется, данным списком инструментарий для разработки и отладки приложений в Kubernetes не ограничивается. Существует еще много весьма полезных и практичных утилит, достойных если не отдельной статьи, то — как минимум — упоминания. Расскажите, чем пользуетесь вы, с какими проблемами вам доводилось сталкиваться и как вы их решали!
Читайте также в нашем блоге:
Автор: Vadim Lazovskiy
Источник [28]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/327940
Ссылки в тексте:
[1] GitHub: https://github.com/aylei/kubectl-debug
[2] отдельной статье: https://habr.com/ru/company/flant/blog/436112/
[3] Сайт: https://www.telepresence.io/
[4] GitHub: https://github.com/telepresenceio/telepresence
[5] здесь: https://habr.com/ru/company/flant/blog/446788/
[6] GitHub: https://github.com/vapor-ware/ksync
[7] syncthing: https://syncthing.net/
[8] соответствующий issue: https://github.com/syncthing/syncthing/issues/5832
[9] .stignore
: https://docs.syncthing.net/users/ignoring.html
[10] GitHub: https://github.com/solo-io/squash
[11] расширения: https://marketplace.visualstudio.com/items?itemName=ilevine.squash
[12] безопасного режима: https://squash.solo.io/secure_mode/
[13] werf: https://habr.com/ru/company/flant/blog/333682/
[14] werf — наш инструмент для CI/CD в Kubernetes: https://habr.com/ru/company/flant/blog/460351/
[15] GitHub: https://github.com/devspace-cloud/devspace
[16] документации: https://devspace.cloud/docs/
[17] Сайт: https://skaffold.dev/
[18] GitHub: https://github.com/GoogleContainerTools/skaffold
[19] container-structure-test: https://github.com/GoogleContainerTools/container-structure-test
[20] Google Cloud Build: https://cloud.google.com/cloud-build/
[21] Kaniko: https://github.com/GoogleContainerTools/kaniko
[22] Сайт: https://garden.io/
[23] GitHub: https://github.com/garden-io/garden
[24] экспериментальном состоянии: https://github.com/garden-io/garden/tree/master/dashboard
[25] документация: https://docs.garden.io/
[26] набор примеров: https://github.com/garden-io/garden/tree/master/examples
[27] перевод статьи: https://habr.com/ru/company/flant/blog/459586/
[28] Источник: https://habr.com/ru/post/462707/?utm_source=habrahabr&utm_medium=rss&utm_campaign=462707
Нажмите здесь для печати.