Tekton Pipeline — Kubernetes-нативные pipelines

Tekton Pipeline — это новый проект, который позволяет запускать CI/CD pipelines используя Kubernetes-нативный подход. Первоначально Tekton Pipelines это часть проекта “Knative build”. Если вы хотите узнать больше об этом проекте, я настоятельно рекомендую посетить их сайт, который доступен по ссылке здесь.

Прежде чем мы начнем говорить о том, что значит «Kubernetes-нативный» и как работают Tekton Pipeline, я бы хотел сделать шаг назад и кратко пояснить, почему запускать pipelines в контейнерах, а не на хосте, так важно и полезно: Некоторое время назад мы начали перенос приложений, с которыми мы работаем, в контейнеры. Мы сделали это из-за таких преимуществ как изоляция, прозрачные зависимости, масштабируемость и неизменяемость. Разве не было бы это так же полезным и для CI/CD pipelines? Подумайте о “build-hosts”, которые предоставляли бы инструменты и зависимости, необходимые для одной конкретной задачи сборки. Об окружении, которое бы было одинаковым при каждом отдельном запуске и не имело бы никаких зависимостей от других проектов, из-за чего могли бы возникнуть проблемы. А также, о легком масштабировании pipelines. Вот почему мы можем и должны запускать контейнеризированные pipelines!

Сейчас, когда мы вкратце поговорили о контейнеризации для pipelines, давайте поговорим как проект Tekton Pipeline с его Kubernetes-нативным подходом могли бы помочь:

Tekton Pipeline позволяют нам запускать контейнеризированные pipelines в наших имеющихся Kubernetes кластерах. Это значит, что нам не нужны дополнительные машины для запуска наших pipelines и, следовательно, мы можем лучше использовать уже существующие.

Это здорово, но, будем честны, это не делает Tekton Pipeline уникальным. Поэтому, Tekton Pipeline идет на шаг дальше и хранит все относящееся к нашему pipelines внутри Kubernetes — как ресурс Kubernetes. Это позволяет нам работать с нашими конвейерами, как и с любым другим ресурсом. Подумайте о Deployment или о Service, которые вы можете создавать и управлять ими, используя kubectl и YAML-файлы.

С чего начать

Как уже упоминалось выше, Tekton Pipeline находится внутри кластера Kubernetes. Он основан на 5 Custom Resource Definitions (CRDs), Deployments, ConfigMaps и Services. Вы можете запустить следующую команду, чтобы начать:

kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml

Помимо вышеупомянутых ресурсов, он также создаст Namespace, Pod Security Policy, Service Account и ClusterRoles. Tekton Pipeline готовы к работе, как только все Pods в только что созданном Namespace (имя по умолчанию tekton-pipelines) готовы.

Разумеется, вы можете просмотреть данный YAML-файл и настроить его в соответствии с вашими потребностями.

Если вам нужно совместно использовать артефакты или другие ресурсы pipelines между задачами, вам необходимо настроить для них хранилище. Вы можете использовать PVC, которые будут запрашиваться каждый раз, когда это необходимо (динамическая инициализация тома является ключевой!), или Blob-storage. Вы найдете более подробную информацию об этой задаче здесь.

Первый pipeline

Итак, как работает Tekton Pipelines? Я объясню разницу между ресурсами (Custom Resource Definitions) Tekton Pipelines на небольших примерах. Pipeline будет создавать (билдить) небольшое приложение на Go, создавать требуемый образ и затем пушить его в Registry. Вы можете найти все соответствующие файлы здесь.

Прежде всего, мы создаем два определения PipelineResouce, которые будем использовать для определения в качестве источника кода Git-репозиторий и Registry в качестве конечного пункта. Pipeline Resources опциональны и потому очень полезны для использования одних и тех же pipelines, но с разными источниками и пунктами назначения.

apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
 name: git-repo
spec:
 type: git
 params:
   - name: revision
     value: master
   - name: url
     value: https://gitlab.com/nmeisenzahl/tekton-demo
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
 name: image-registry
spec:
 type: image
 params:
   - name: url
     value: registry.gitlab.com/nmeisenzahl/tekton-demo/demo:latest

Теперь нам нужно создать ресурс Task, чтобы определить последовательность шагов в нашем pipeline. Разумеется, если это необходимо, можно создать несколько задач. В нашем примере чтобы создать Image мы будем использовать Kaniko. Данный Dockerfile, как и остальные ресурсы для приложения, лежат в Git-репозитории.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
 name: build-docker-image
spec:
 inputs:
   resources:
     - name: git-repo
       type: git
   params:
     - name: pathToDockerFile
       description: Path to Dockerfile
       default: /workspace/git-repo/Dockerfile
     - name: pathToContext
       description: The build context used by Kaniko
       default: /workspace/git-repo
 outputs:
   resources:
     - name: image-registry
       type: image
 steps:
   - name: build-and-push
     image: gcr.io/kaniko-project/executor:v0.10.0
     env:
       - name: "DOCKER_CONFIG"
         value: "/builder/home/.docker/"
     command:
       - /kaniko/executor
     args:
       - --dockerfile=${inputs.params.pathToDockerFile}
       - --destination=${outputs.resources.image-registry.url}
       - --context=${inputs.params.pathToContext}

Теперь мы можем создать ресурс TaskRun для запуска экземпляра вышеуказанной задачи. Однако в этом примере мы используем Pipeline, который мы можем использовать для объединения нескольких задач (тасков) подряд:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 resources:
   - name: git-repo
     type: git
   - name: image-registry
     type: image
 tasks:
   - name: build-docker-image
     taskRef:
       name: build-docker-image
     params:
       - name: pathToDockerFile
         value: /workspace/git-repo/Dockerfile
       - name: pathToContext
         value: /workspace/git-repo
     resources:
       inputs:
         - name: git-repo
           resource: git-repo
       outputs:
         - name: image-registry
           resource: image-registry

Так как мы помещаем созданный Image в registry, вы должны убедиться, что pipeline может пройти аутентификацию, настроив ImagePullSecrets для нужного serviceaccount (в нашем случае это serviceaccount — default).

Теперь у нас есть все необходимое для запуска pipeline. Для этого нам нужно задать последнее определение, для PipelineRun resource:

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
 name: demo-pipeline-run-1
spec:
 pipelineRef:
   name: demo-pipeline
 resources:
   - name: git-repo
     resourceRef:
       name: git-repo
   - name: image-registry
     resourceRef:
       name: image-registry

Для проверки статуса pipeline можно использовать kubectl get pipelineruns -o yaml.

Более того

Помимо самого проекта Tekton Pipeline, есть также проект для CLI который облегчает работу с pipelines. Вы также можете установить веб-панель управления (web-based Dashboard) для просмотра и управления вашими pipelines из браузера.

Кроме того, та же команда работает над другим проектом под названием Tekton Triggers. Этот проект довольно новый (первый коммит был 4 недели назад) и все еще в стадии разработки. Триггеры Tekton позволяют вызывать Tekton Pipelines на основе «триггеров». Это могут быть git-commits, git-issues или любые другие webhooks(веб-хуки). Более подробная информация доступна здесь.

Также читайте другие статьи в нашем блоге:

• Cборка динамических модулей для Nginx
• Введение в Hashicorp Consul’s Kubernetes Авторизацию
• К чему привела миграция с ClickHouse без авторизации на ClickHouse с авторизацией
• Blue-Green Deployment приложений на Spring c веб-сервером Nginx
• Как запустить несколько пайплайнов с помощью GitLab CI/CD