Introducción a GitOps para OpenShift

Hoy hablaremos sobre los principios y modelos de GitOps, así como sobre cómo estos modelos se implementan en la plataforma OpenShift. Una guía en línea sobre este tema está disponible aquí .



En resumen, GitOps es un conjunto de métodos prácticos para usar las solicitudes de extracción de Git para administrar la infraestructura y las configuraciones de las aplicaciones. El repositorio de Git dentro de GitOps se considera como una única fuente de información sobre el estado del sistema, y ​​cualquier cambio en este estado se supervisa y audita por completo.

La idea del seguimiento de cambios en GitOps no es nueva; este enfoque se ha utilizado durante mucho tiempo en casi todas partes cuando se trabaja con el código fuente de la aplicación. GitOps simplemente implementa funciones similares (revisiones de revisión, solicitudes de extracción, etiquetas, etc.) al administrar la infraestructura y las configuraciones de la aplicación y ofrece ventajas similares a las de la administración del código fuente.

Para GitOps, no existe una definición académica o un conjunto aprobado de reglas, solo un conjunto de principios en los que se basa esta práctica:

• La descripción declarativa del sistema se almacena en el repositorio de Git (configuraciones, monitoreo, etc.).
• Los cambios de estado se realizan mediante solicitudes de extracción.
• El estado de los sistemas en ejecución está alineado con los datos en el repositorio utilizando solicitudes push de Git.

Principios de GitOps

• Las definiciones del sistema se describen como código fuente.

La configuración del sistema se considera como código, por lo que puede almacenarse y versionarse automáticamente en el repositorio de Git, que sirve como la única fuente de verdad. Este enfoque facilita el despliegue y la reversión de los cambios en los sistemas.

• El estado deseado y la configuración del sistema se configuran y versionan en Git

Al almacenar y versionar en Git el estado deseado de los sistemas, tenemos la capacidad de revertir y revertir fácilmente los cambios en los sistemas y aplicaciones. También podemos usar los mecanismos de seguridad de Git para controlar la propiedad del código y verificar su autenticidad.

• Los cambios de configuración se pueden aplicar automáticamente mediante solicitudes de extracción.

Usando las solicitudes de extracción de Git, podemos controlar fácilmente cómo se aplican los cambios a las configuraciones en el repositorio. Por ejemplo, pueden enviarse para verificación a otros miembros del equipo o pasar por pruebas de CI, etc.

Y al mismo tiempo, no es necesario que otorgue autoridad de administrador a derecha e izquierda. Para confirmar los cambios de configuración, los usuarios tienen permisos suficientes en el repositorio de Git donde se almacenan estas configuraciones.

• Arreglar configuraciones de deriva no controladas

Cuando el estado deseado del sistema se almacena en el repositorio de Git, solo podemos encontrar software que controle que el estado actual del sistema corresponda a su estado deseado. Si esto no es así, entonces este software debería, dependiendo de la configuración, corregir la discrepancia por sí solo o notificarnos la deriva de la configuración.

Modelos GitOps para OpenShift

Reconciliador de recursos en clúster

Según este modelo, el clúster tiene un controlador que se encarga de comparar los recursos de Kubernetes (archivos YAML) en el repositorio de Git con los recursos reales del clúster. En caso de discrepancias, el controlador envía notificaciones y, posiblemente, toma medidas para eliminar inconsistencias. Este modelo de GitOps es utilizado por Anthos Config Management y Weaveworks Flux.

Reconciliador de recursos externos (Push)

Este modelo puede considerarse como una variación del anterior, cuando tenemos uno o más controladores responsables de sincronizar recursos en pares "Repositorio de Git - Clúster de Kubernetes". La diferencia aquí es que cada clúster administrado no tiene que tener su propio controlador separado. Los pares de clúster Git - k8 a menudo se definen como CRD de definición de recursos personalizados, que describen cómo el controlador debe realizar la sincronización. Dentro de este modelo, los controladores comparan el repositorio de Git especificado en CRD con los recursos del clúster de Kubernetes, que también se definen en CRD, y realizan las acciones correspondientes en función de los resultados de la comparación. En particular, dicho modelo GitOps se usa en ArgoCD.

GitOps en la plataforma OpenShift

Administración de Infraestructura Kubernetes Multiclúster

Con la propagación de Kubernetes y la creciente popularidad de las estrategias multi-nube y la informática de punta, el número promedio de clústeres OpenShift por cliente también ha aumentado.

Por ejemplo, cuando se utiliza la informática periférica, los clústeres de un solo cliente se pueden implementar en cientos o incluso miles. Como resultado, se ve obligado a administrar varios clústeres OpenShift independientes o coordinados en la nube pública y en las instalaciones.

Al mismo tiempo, se deben resolver muchos problemas, en particular:

• Para controlar que los clústeres estén en idénticas condiciones (configuraciones, monitoreo, almacenamiento, etc.)
• Vuelva a crear (o restaurar) clústeres de acuerdo con un estado conocido.
• Cree nuevos clústeres de acuerdo con un estado conocido.
• Tire de los cambios en múltiples clústeres OpenShift.
• Retroceda los cambios a múltiples clústeres OpenShift.
• Configuraciones de enlace de patrones con diferentes entornos.

Configuraciones de aplicaciones

Durante su ciclo de vida, las aplicaciones a menudo pasan por una cadena de clústeres (desarrollo, etapa, etc.) antes de ingresar a un clúster de producción. Además, debido a los requisitos de disponibilidad y escalabilidad, los clientes a menudo implementan aplicaciones en múltiples clústeres locales o en múltiples regiones de una plataforma de nube pública.

En este caso, es necesario resolver los siguientes problemas:

• Asegure el movimiento de aplicaciones (binarios, configuraciones, etc.) entre clústeres (dev, stage, etc.).
• Enrolle los cambios en las aplicaciones (binarios, configuraciones, etc.) en varios clústeres de OpenShift.
• Revierta los cambios en las aplicaciones al nivel del estado anterior conocido.

Escenarios de uso de OpenShift GitOps

1. Aplicar cambios desde el repositorio de Git

El administrador del clúster puede almacenar las configuraciones de clúster OpenShift en el repositorio de Git y aplicarlas automáticamente para crear nuevos clústeres sin ningún esfuerzo adicional y llevarlos a un estado idéntico al estado conocido almacenado en el repositorio de Git.

2. Sincroniza con Secret Manager

El administrador también encontrará útil sincronizar los objetos secretos de OpenShift con el software apropiado como Vault para administrarlos utilizando herramientas especialmente creadas para esto.

3. Configuraciones de deriva de control

El administrador solo estará a favor si OpenShift GitOps detecta y advierte sobre las discrepancias entre las configuraciones reales y las especificadas en el repositorio, para que pueda responder rápidamente a la deriva.

4. Notificaciones de deriva de configuración

Será útil cuando el administrador quiera conocer rápidamente las configuraciones de deriva para tomar rápidamente las medidas apropiadas por su cuenta.

5. Sincronización manual de configuraciones al derivar

Permite al administrador sincronizar el clúster de OpenShift con el repositorio de Git en caso de configuraciones de deriva para devolver rápidamente el clúster a un estado conocido anterior.

6. Sincronización automática de configuraciones de deriva

El administrador también puede configurar el clúster OpenShift para sincronizar automáticamente con el repositorio cuando se detecta una deriva, de modo que la configuración del clúster siempre coincida con las configuraciones en Git.

7. Varios clústeres: un repositorio

El administrador puede almacenar configuraciones de varios clústeres OpenShift diferentes en un repositorio Git y aplicarlas selectivamente según sea necesario.

8. Jerarquía de configuraciones de clúster (herencia)

El administrador puede establecer la jerarquía de configuraciones de clúster en el repositorio (etapa, prod, cartera de aplicaciones, etc. con herencia). En otras palabras, puede determinar cómo se deben aplicar las configuraciones, a uno o varios clústeres.

Por ejemplo, si el administrador define la jerarquía “Clústeres de producción (prod) → Clústeres del sistema X → Clústeres de producción del sistema X” en el repositorio de Git, las siguientes configuraciones se aplican a los clústeres de producción del sistema X:

• Configuraciones comunes a todos los grupos de producción.
• Configuraciones para el sistema de clúster X.
• Configuraciones para el cluster de producción del sistema X.

9. Patrones y anulaciones de configuración

El administrador puede anular el conjunto de configuraciones heredadas y sus valores, por ejemplo, para ajustar la configuración para clústeres específicos a los que se aplicarán.

10. Incluir y excluir selectivamente para configuraciones, configuración de aplicaciones

El administrador puede establecer las condiciones para aplicar o no ciertas configuraciones a clústeres con ciertas características.

11. Soporte de patrones

Los desarrolladores encontrarán útil elegir cómo se determinarán los recursos de la aplicación (Helm Chart, Kubernetes yaml puro, etc.) para usar el formato más adecuado para cada aplicación específica.

Herramientas de GitOps en la plataforma OpenShift

Argocd

ArgoCD implementa el modelo de Reconciliación de recursos externos y ofrece una interfaz de usuario centralizada para organizar las relaciones entre clústeres y repositorios de Git de una a una. Las desventajas de este programa incluyen la incapacidad de administrar aplicaciones mientras ArgoCD no funciona.

Sitio web oficial

Flujo

Flux implementa el modelo de reconciliación de recursos en el clúster y, como resultado, no existe una administración centralizada del repositorio de definiciones, que es un punto débil. Por otro lado, precisamente por la falta de centralización, la capacidad de administrar aplicaciones se conserva incluso cuando falla un clúster.

Sitio web oficial

Instale ArgoCD en OpenShift

ArgoCD ofrece una excelente interfaz de línea de comandos y consola web, por lo que no consideraremos Flux y otras alternativas aquí.

Para implementar ArgoCD en la plataforma OpenShift 4, siga estos pasos como administrador de clúster:

Despliegue de componentes ArgoCD en la plataforma OpenShift

# Create a new namespace for ArgoCD components oc create namespace argocd # Apply the ArgoCD Install Manifest oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml # Get the ArgoCD Server password ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}') 

Refinamiento del servidor ArgoCD para ser visto por OpenShift Route

 # Patch ArgoCD Server so no TLS is configured on the server (--insecure) PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}' oc -n argocd patch deployment argocd-server -p $PATCH # Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect 

Implementar ArgoCD Cli Tool

 # Download the argocd binary, place it under /usr/local/bin and give it execution permissions curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd chmod +x /usr/local/bin/argocd 

Cambiar contraseña de administrador del Servidor ArgoCD

 # Get ArgoCD Server Route Hostname ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}') # Login with the current admin password argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD} # Update admin's password argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password 

Después de completar estos pasos, puede trabajar con ArgoCD Server a través de la consola web ArgoCD WebUI o la herramienta de línea de comandos ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps: nunca es demasiado tarde

"El tren se ha ido": esto es lo que dicen sobre la situación cuando se pierde la oportunidad de hacer algo. En el caso de OpenShift, el deseo de comenzar a usar de inmediato esta nueva y genial plataforma a menudo crea tal situación con la administración y el mantenimiento de rutas, implementaciones y otros objetos de OpenShift. ¿Pero la oportunidad siempre se pierde por completo?

Continuando con una serie de artículos sobre GitOps , hoy mostraremos cómo transformar una aplicación creada manualmente y sus recursos en un proceso determinado donde el kit de herramientas GitOps controla todo. Para hacer esto, primero implementamos la aplicación httpd con nuestras manos. La siguiente captura de pantalla muestra cómo creamos un espacio de nombres, implementación y servicio, y luego exponemos para que este servicio cree una ruta.

 oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml oc expose svc/httpd -n simple-app 

Entonces, tenemos una aplicación creada manualmente. Ahora debe transferirse bajo el control de GitOps sin pérdida de disponibilidad. En resumen, hace esto:

• Crea un repositorio Git para el código.
• Exportamos nuestros objetos actuales y los cargamos en el repositorio de Git.
• Seleccione e implemente el kit de herramientas GitOps.
• Agregue nuestro repositorio a este kit de herramientas.
• Definimos la aplicación en nuestro kit de herramientas de GitOps.
• Realice una ejecución de prueba de la aplicación utilizando el kit de herramientas GitOps.
• Sincronizamos objetos usando el kit de herramientas GitOps.
• Activamos la poda y la sincronización automática de objetos.

Como se mencionó en el artículo anterior, GitOps tiene una y solo una fuente de información sobre todos los objetos en los clústeres de Kubernetes: el repositorio de Git. Además, procedemos de la premisa de que su organización ya utiliza un repositorio Git. Puede ser público o privado, pero debe estar disponible para los clústeres de Kubernetes. Puede ser el mismo repositorio que para el código de la aplicación, o un repositorio separado creado específicamente para la implementación. Se recomienda que tenga permisos estrictos en el repositorio, ya que los objetos secretos, las rutas y otras cosas sensibles a la seguridad se almacenarán allí.

En nuestro ejemplo, crearemos un nuevo repositorio público en GitHub. Puedes nombrarlo como quieras, usamos el nombre blogpost.

Si los archivos YAML de los objetos no se almacenaron localmente o en Git, deberá usar los binarios oc o kubectl. En la captura de pantalla a continuación, solicitamos YAML para nuestro espacio de nombres, implementación, servicio y ruta. Antes de eso, clonamos el repositorio recién creado y lo trasladamos con el comando cd.

 oc get namespace simple-app -o yaml --export > namespace.yaml oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml oc get service httpd -o yaml -n simple-app --export > service.yaml oc get route httpd -o yaml -n simple-app --export > route.yaml 

Ahora arregle el archivo deploy.yaml para eliminar un campo que Argo CD no puede sincronizar.

 sed -i '/\sgeneration: .*/d' deployment.yaml 

Además, debe cambiar la ruta. Primero estableceremos la variable multilínea y luego reemplazaremos el ingreso: nulo con el contenido de esta variable.

 export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml 

Entonces, con los archivos ordenados, queda guardarlos en el repositorio de Git. Después de eso, este repositorio se convierte en la única fuente de información, y cualquier cambio manual en los objetos debería estar estrictamente prohibido.

 git commit -am 'initial commit of objects' git push origin master 

Además, procedemos del hecho de que ArgoCD ya está implementado para usted (cómo hacer esto, consulte la publicación anterior). Por lo tanto, agregamos al CD Argo el repositorio que creamos que contiene el código de la aplicación de nuestro ejemplo. Solo asegúrese de especificar el repositorio exacto que creó anteriormente.

 argocd repo add https://github.com/cooktheryan/blogpost 

Ahora crea la aplicación. La aplicación establece valores para que el kit de herramientas GitOps comprenda qué repositorio y rutas usar, qué OpenShift se necesita para administrar objetos, así como qué rama específica del repositorio se necesita y si los recursos deben sincronizarse automáticamente.

 argocd app create --project default \ --name simple-app --repo https://github.com/cooktheryan/blogpost.git \ --path . --dest-server https://kubernetes.default.svc \ --dest-namespace simple-app --revision master --sync-policy none 

Una vez que se especifica la aplicación en el CD de Argo, este kit de herramientas comienza a verificar que los objetos ya implementados cumplan con las definiciones del repositorio. En nuestro ejemplo, la sincronización automática y la limpieza están deshabilitadas, por lo que los elementos aún no cambian. Tenga en cuenta que en la interfaz de Argo CD, nuestra aplicación tendrá el estado "Fuera de sincronización" (No sincronizado), ya que no hay una etiqueta que coloque ArgoCD.
Por eso, cuando comenzamos la sincronización un poco más tarde, no se realizará la redistribución de objetos.

Ahora ejecute una prueba para asegurarse de que no haya errores en nuestros archivos.

 argocd app sync simple-app --dry-run 

Si no hay errores, puede proceder a la sincronización.

 argocd app sync simple-app 

Después de ejecutar el comando argocd get en nuestra aplicación, deberíamos ver que el estado de la aplicación ha cambiado a Saludable o Sincronizado. Esto significará que todos los recursos en el repositorio de Git ahora corresponden a aquellos recursos que ya están implementados.

 argocd app get simple-app Name: simple-app Project: default Server: https://kubernetes.default.svc Namespace: simple-app URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app Repo: https://github.com/cooktheryan/blogpost.git Target: master Path: . Sync Policy: <none> Sync Status: Synced to master (60e1678) Health Status: Healthy ... 

Pero ahora puede activar la sincronización automática y la limpieza para asegurarse de que no se creará nada manualmente y que cada vez que se crea o actualiza el objeto en el repositorio, se realizará la implementación.

 argocd app set simple-app --sync-policy automated --auto-prune 

Entonces, transferimos con éxito al control de GitOps una aplicación que inicialmente no usaba GitOps de ninguna manera.