Traducción | To Great
El estilo sin servidor de Jenkins X, o algunas personas lo llaman Jenkins X Next Generation, intenta redefinir cómo realizamos la entrega continua y GitOps en un clúster de Kubernetes.
Lo hace combinando bastantes herramientas en un paquete fácil de usar. La mayoría de los usuarios no necesitan comprender la complejidad del funcionamiento independiente de los componentes relacionados, ni tampoco cómo se integran. Simplemente envíe la iteración de la versión a Git y el sistema realizará el resto del trabajo automáticamente.
Para echar un vistazo, exploremos juntos los procesos y componentes involucrados en la plataforma Jenkins X sin servidor. Al comprender el flujo de una tarea desde el webhook de Git, nos ayudará a comprender mejor su principio de funcionamiento. Al mismo tiempo, también brindaremos ayuda cuando presentemos cada nuevo componente en profundidad.
以下的描述，并非对所有使用者都是必需的。如果你选择跳过，并选择在不清楚其内部工作原理的情况下使用无服务器的Jenkins X，我们也认为很好。毕竟，Jenkins X的主要目标就是抽象细节，让人们练习持续交付，而不用花费数月时间来学习诸如Kubernetes和Jenkins X等复杂系统。
Al igual que Jenkins estático, todo comienza con un empujón a la biblioteca de Git. Posteriormente, se envía una solicitud de webhook al clúster. La diferencia es que no hay Jenkins para recibir estas solicitudes. En cambio, tenemos Prow. Hará muchas cosas, pero en el escenario de webhook, su trabajo es recibir solicitudes y decidir qué hacer a continuación. Estas solicitudes no se limitan a operaciones de inserción, sino que también incluyen comandos de barra que podemos especificar mediante comentarios de solicitud de extracción (por ejemplo, / aprobar).
La proa consta de varios componentes diferentes (por ejemplo, cubierta, gancho, pregonero, marea, etc.). Sin embargo, no profundizaremos en las responsabilidades de cada componente. En este momento, lo más importante a tener en cuenta es que Prow es la entrada al grupo. Recibe todas las solicitudes de Git, incluidas las generadas por acciones de Git (como empujar) y las generadas por comandos de barra en los comentarios.
Prow puede hacer muchas cosas después de recibir la solicitud. Si proviene de un comando en un comentario de Git, podría volver a ejecutar la prueba, fusionar solicitudes de extracción, asignar personas o una de muchas otras operaciones relacionadas con Git. Si el webhook le informa que se ha realizado una nueva inserción, enviará una solicitud al Jenkins X Pipeline Operator, que garantizará que se ejecute la compilación correspondiente a la canalización definida. Finalmente, Prow también informó el estado de la compilación a Git.
Estas características no son el único tipo de acción que puede realizar Prow, pero ahora puedes obtener una esencia general. Prow es responsable de la comunicación entre Git y los procesos internos del clúster.
Cuando Prow Hook recibe una solicitud de un webhook de Git, la reenvía al Jenkins X Pipeline Operator. La responsabilidad del operador es recuperar el archivo jenkins-x.yml utilizado para inicializar el proceso de la biblioteca y convertirlo a Tekton Tasks and Pipelines. A su vez, definen la canalización completa que debe ejecutarse después de que los cambios se envíen a Git.
La razón por la que existe el operador de oleoductos es para simplificar la definición de nuestro proceso de entrega continua. Tekton hizo el trabajo pesado, pero esta es una solución de muy bajo nivel. No debe usarse directamente. Escribir definiciones de Tekton puede ser muy doloroso y complicado. El operador de canalización simplifica este proceso al ser fácil de aprender y utilizar el formato YAML para definir canalizaciones.
Tekton crea un PipelineRun para cada inserción, y cada inserción se envía a una rama relacionada (por ejemplo, rama maestra, PR, etc.), y todos los pasos necesarios para verificar la inserción se realizan al mismo tiempo. Tekton ejecuta pruebas, almacena binarios en el registro (por ejemplo, Docker Registry, Nexus y ChartMuseum) e implementa la versión en un entorno temporal (PR) o permanente (temporal o de producción).
El proceso completo se muestra en la siguiente figura:
Como se mencionó anteriormente, no todo el mundo necesita comprender el flujo de eventos, ni es necesario tener una comprensión profunda de todos los componentes involucrados en el proceso. Para la mayoría de los usuarios, lo único que deben entender es que si se realizan cambios en Git, se ejecutará la compilación definida en la canalización jenkins-x.yml. Esta es la belleza de Jenkins X. Simplifica nuestras vidas al simplificar procesos complejos.
Este artículo es un extracto del libro "DevOps 2.6 Toolkit: Jenkins X".
Enlace original: https://technologyconversations.com/2019/04/15/going-serverless-with-jenkins-x-exploring-prow-jenkins-x-pipeline-operator-and-tekton/