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(веб-хуки). Более подробная информация доступна здесь.
Также читайте другие статьи в нашем блоге:
ссылка на оригинал статьи https://habr.com/ru/company/nixys/blog/481992/
Добавить комментарий