Tekton Pipeline es un nuevo proyecto que le permite ejecutar canalizaciones de CI / CD utilizando el enfoque nativo de Kubernetes. Tekton Pipelines fue originalmente parte del proyecto "Knative build". Si desea saber más sobre este proyecto, le recomiendo que visite su sitio web, que está disponible en el enlace aquí .
Antes de comenzar a hablar sobre lo que significa “nativo de Kubernetes” y cómo funciona Tekton Pipeline, me gustaría dar un paso atrás y explicar brevemente por qué es tan importante y útil ejecutar tuberías en contenedores en lugar de en el host: hace algún tiempo comenzamos a transferir las aplicaciones con las que trabajamos a los contenedores. Lo hicimos debido a beneficios como el aislamiento, dependencias transparentes, escalabilidad e inmutabilidad. ¿No sería tan útil para las canalizaciones de CI / CD? Piense en "hosts de compilación", que proporcionarían las herramientas y dependencias necesarias para una tarea de compilación específica. Acerca de un entorno que sería el mismo cada vez que se iniciara y que no dependería de otros proyectos, lo que podría causar problemas. Y también, sobre tuberías de escalado fáciles. ¡Es por eso que podemos y debemos ejecutar tuberías en contenedores!
Ahora que hemos hablado brevemente sobre la contenedorización de tuberías, hablemos de cómo el proyecto Tekton Pipeline con su enfoque nativo de Kubernetes podría ayudar:
Tekton Pipeline nos permite ejecutar tuberías en contenedores en nuestros grupos de Kubernetes existentes. Esto significa que no necesitamos máquinas adicionales para ejecutar nuestras tuberías y, por lo tanto, podemos utilizar mejor las existentes.
Es genial, pero para ser sincero, eso no hace que Tekton Pipeline sea único. Por lo tanto, Tekton Pipeline va un paso más allá y almacena todo lo relacionado con nuestras tuberías dentro de Kubernetes, como un recurso de Kubernetes. Esto nos permite trabajar con nuestros transportadores, así como con cualquier otro recurso. Piense en Implementación o Servicio, que puede crear y administrar utilizando archivos kubectl y YAML.
Por donde empezar
Como se mencionó anteriormente, la tubería de Tekton se encuentra dentro del clúster de Kubernetes. Se basa en 5 definiciones de recursos personalizados (CRD), implementaciones, mapas de configuración y servicios. Puede ejecutar el siguiente comando para comenzar:
kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml
Además de los recursos anteriores, también creará Espacio de nombres, Política de seguridad de pod, Cuenta de servicio y ClusterRoles. Tekton Pipeline está listo para funcionar tan pronto como todos los Pods en el espacio de nombres recién creado (el nombre predeterminado es tekton-pipelines) estén listos.
Por supuesto, puede ver este archivo YAML y personalizarlo según sus necesidades.
Si necesita compartir artefactos u otros recursos de canalizaciones entre tareas, debe configurar el almacenamiento para ellos. Puede usar PVC, que se solicitará cada vez que sea necesario (¡la inicialización dinámica del volumen es clave!), O Blob-storage. Encontrará más información sobre esta tarea aquí .
Primera tubería
Entonces, ¿cómo funcionan las tuberías de Tekton? Explicaré la diferencia entre las definiciones de recursos personalizados de Tekton Pipelines en pequeños ejemplos. Pipeline creará (compilará) una pequeña aplicación en Go, creará la imagen requerida y luego la introducirá en el Registro. Puede encontrar todos los archivos relevantes aquí .
En primer lugar, creamos dos definiciones de PipelineResouce que usaremos para definir el repositorio y el Registro de Git como destino final como código fuente. Los recursos de tuberías son opcionales y, por lo tanto, muy útiles para usar las mismas tuberías, pero con diferentes fuentes y destinos.
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
Ahora necesitamos crear un recurso de Tarea para determinar la secuencia de pasos en nuestra tubería. Por supuesto, si es necesario, puede crear varias tareas. En nuestro ejemplo, utilizaremos Kaniko para crear una imagen. Este Dockerfile, como otros recursos para la aplicación, se encuentra en el repositorio de 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}
Ahora podemos crear un recurso TaskRun para iniciar una instancia de la tarea anterior. Sin embargo, en este ejemplo, usamos Pipeline , que podemos usar para combinar varias tareas (tareas) en una fila:
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
Dado que colocamos la imagen creada en el registro, debe asegurarse de que la tubería se pueda autenticar configurando ImagePullSecrets para la cuenta de servicio deseada (en nuestro caso, es la cuenta de servicio, predeterminada).
Ahora tenemos todo lo necesario para lanzar la tubería. Para hacer esto, necesitamos especificar la última definición para el recurso PipelineRun :
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
Puede usar kubectl get pipelineruns -o yaml para verificar el estado de la tubería.
Por otra parte
Además del proyecto Tekton Pipeline en sí, también hay un proyecto para la CLI que facilita el trabajo con tuberías. También puede configurar un Panel de control basado en la web para ver y administrar sus canalizaciones desde un navegador.
Además, el mismo equipo está trabajando en otro proyecto llamado Tekton Triggers. Este proyecto es bastante nuevo (el primer commit fue hace 4 semanas) y todavía está en desarrollo. Los disparadores de Tekton le permiten llamar a las tuberías de Tekton en función de los "disparadores". Pueden ser git-commits, git-issues o cualquier otro webhooks (web hooks). Más información está disponible aquí .
Lea también otros artículos en nuestro blog: