Kubernetes быстро превращается из платформы оркестровки Docker в облачную операционную систему общего назначения. Благодаря операторам, Kubernetes получает возможность изначально управлять высокоуровневыми концепциями и бизнес-процессами, что означает, что вы больше не управляете строительными блоками модулей, служб и развертываний, а вместо этого описываете вещи, которые эти строительные блоки могут создавать, например веб-серверы, базы данных, непрерывное развертывание, управление сертификатами и многое другое. При развертывании в кластере Kubernetes Tekton Pipelines предоставляет возможность определять и выполнять задачи сборки, входные и выходные данные в форме простых значений или сложных объектов, таких как образы Docker, и объединять эти ресурсы в конвейеры. Эти новые ресурсы Kubernetes и контроллеры, которые ими управляют, приводят к созданию автономной платформы CI / CD, размещенной в кластере Kubernetes. В этом посте мы рассмотрим простой конвейер сборки, работающий на MicroK8S. В этой публикации я использую MicroK8S для создания кластера Kubernetes. MicroK8S здесь полезен, потому что он предлагает выбор официальных надстроек, одна из которых — реестр образов Docker. Поскольку наш конвейер создает образ Docker, нам нужно где-то его разместить, а надстройка реестра MicroK8S предоставляет нам эту функциональность с помощью одной команды: Нам также необходимо включить поиск DNS из кластера MicroK8S. Это делается путем включения надстройки DNS: Установка Tekton Pipelines выполняется с помощью одной команды kubectl (или microk8s.kubectl в нашем случае):  Теперь мы можем создавать ресурсы Tekton в нашем кластере Kubernetes. Задачи содержат отдельные шаги, которые выполняются для выполнения работы. В приведенном ниже примере у нас есть задача с одним шагом, которая выполняет команду echo с аргументами Hello World в контейнере, созданном из образа ubuntu. В YAML ниже показан наш файл helloworldtask.yml: Ресурс задачи создается в кластере Kubernetes командой: Задача описывает, как должна выполняться работа, но создание ресурса задачи не приводит к выполнению каких-либо действий. Ресурс запуска задачи ссылается на задачу, и создание ресурса запуска задачи запускает Tekton для выполнения шагов в указанной задаче. В YAML ниже показан наш файл helloworldtaskrun.yml: Ресурс запуска задачи создается в кластере Kubernetes с помощью команды: Чтобы выйти за рамки этого примера hello world, мы рассмотрим канонический вариант использования конвейера сборки Tekton, который заключается в компиляции и отправке образа Docker. Чтобы продемонстрировать эту функциональность, мы создадим наше примерное приложение RandomQuotes. Мы запускаем конвейер с конвейерного ресурса. Ресурсы конвейера обеспечивают независимый метод определения входных данных для процесса сборки. Первый вход, который нам нужен, — это репозиторий Git, в котором хранится наш код. Ресурсы конвейера имеют несколько известных типов, и здесь мы определяем ресурс конвейера git, указывающий URL-адрес и ветвь, содержащую наш код: Затем мы определяем реестр Docker, содержащий наш скомпилированный образ. В этом случае полезна надстройка реестра MicroK8S, поскольку она предоставляет доступ к реестру Docker по адресу http://registry.container-registry.svc.cluster.local:5000. Вот конвейерный ресурс типа image, определяющий образ Docker, который мы создадим как registry.container-registry.svc.cluster.local:5000/randomquotes: Определив входной исходный код и целевой образ Docker, мы можем создать задачу для создания образа Docker и отправить его в репозиторий. Обычно создание образов Docker выполняется клиентом Docker непосредственно в операционной системе хоста. Однако в Kubernetes все выполняется внутри Docker, поэтому возникает вопрос: как запустить Docker внутри Docker? За последние несколько лет появилось множество инструментов, предназначенных для выполнения процессов, предоставляемых Docker CLI и демоном, но без какой-либо зависимости от самого Docker. К ним относятся такие инструменты, как umoci для распаковки и переупаковки образов Docker, Kaniko и Buildah для создания образов Docker из файла Docker и Podman для запуска образов Docker. Мы будем использовать Kaniko в нашей задаче Tekton, чтобы создать образ Docker внутри контейнера Docker, предоставленного Kubernetes. YAML ниже показывает полную задачу: Стоит отметить несколько важных аспектов этой задачи. В этой задаче есть два свойства, которые относятся к ресурсам конвейера, которые мы создали выше. Входной ресурс типа git: И вывод типа image: Есть два дополнительных входных параметра, которые определяют пути, используемые для процесса сборки Docker: Обратите внимание, что путь /workspace/docker-source — это соглашение, используемое ресурсами git, с каталогом docker-source, совпадающим с именем ввода. Затем у нас есть один шаг, который создает образ Docker. Сборка выполняется в контейнере, созданном из образа gcr.io/kaniko-project/executor:v0.17.1 image, который предоставляет Kaniko: И наконец, запуск задачи используется для связывания ресурсов задачи и конвейера. Этот ресурс сопоставляет входные данные docker-source задачи с ресурсом конвейера randomquotes-git, а выходные данные builtImage — с ресурсом конвейера randomquotes-image. После создания этого ресурса запускается сборка: Сам Tekton не предоставляет никаких панелей управления или графического интерфейса для взаимодействия с заданиями. Однако есть инструмент командной строки для управления заданиями Tekton. Инструмент Tekton CLI предполагает, что kubectl настроен, но MicroK8S поддерживает отдельный инструмент под названием microk8s.kubectl. Самый простой способ настроить kubectl — использовать следующую команду, которая копирует файл конфигурации MicroK8S в стандартное расположение для kubectl: На этом этапе мы можем получить статус задачи с помощью команды:  Составляя сборки с образами Docker, Tekton устраняет накладные расходы на поддержку набора специализированных агентов сборки. В наши дни для каждого инструмента и языка предоставляется поддерживаемый образ Docker, что упрощает соблюдение новой нормы шестимесячного цикла выпуска для основных языковых версий. Kubernetes также является естественной платформой для удовлетворения гибких и краткосрочных требований сборки программного обеспечения. Почему десять специализированных агентов бездействуют, если между ними может быть пять узлов, планирующих сборки? Однако я подозреваю, что Tekton не находится на том уровне, необходимом для большинства инженерных команд. Инструмент tkn CLI будет знаком любому, кто раньше использовал kubectl, но сложно понять общее состояние ваших сборок из терминала. Не говоря уже о создании сборок с помощью kubectl create -f taskrun.yml, которые быстро устаревают. Доступна информационная панель, но это простой пользовательский интерфейс по сравнению с существующими инструментами CI.  Тем не менее, Tekton — это мощная основа для создания инструментов для разработчиков. Jenkins X и OpenShift Pipelines — две такие платформы, которые используют Tekton. Kubernetes решает многие из требований для запуска приложений, таких как аутентификация, авторизация, инструменты интерфейса командной строки, управление ресурсами, проверки работоспособности и многое другое. Тот факт, что кластер Kubernetes может размещать полностью функциональный сервер CI с помощью одной команды, является свидетельством того, насколько гибким является Kubernetes. С такими проектами, как Jenkins X и OpenShift Pipelines, Tekton находится в начале пути к основным рабочим процессам разработки. Но как отдельный проект Tekton находится на низком уровне своих возможностей, чтобы его могло использовать большинство команд разработчиков, хотя бы потому, что у немногих людей будет опыт, чтобы поддержать его. DevOps-инженер