🥇Introducción a GitOps para OpenShift

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

En pocas palabras, GitOps es un conjunto de prácticas para utilizar solicitudes de extracción de Git para administrar la infraestructura y las configuraciones de aplicaciones. El repositorio Git en GitOps se trata como una única fuente de información sobre el estado del sistema, y cualquier cambio en este estado es totalmente rastreable y auditable.

La idea del seguimiento de cambios en GitOps no es nueva; este enfoque se ha utilizado durante mucho tiempo casi universalmente cuando se trabaja con el código fuente de una aplicación. GitOps simplemente implementa características similares (revisiones, solicitudes de extracción, etiquetas, etc.) en la gestión de la configuración de la infraestructura y las aplicaciones y proporciona beneficios similares a los de la gestión del código fuente.

No existe una definición académica ni un conjunto de reglas aprobadas para GitOps, solo un conjunto de principios sobre 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 se alinea con los datos en el repositorio mediante solicitudes push de Git.

Principios de GitOps

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

La configuración de los sistemas se trata como código, por lo que se puede almacenar y versionar automáticamente en un repositorio Git, que sirve como una única fuente de información. Este enfoque facilita la implementación y reversión de cambios en los sistemas.

El estado deseado y la configuración de los sistemas se establecen y versionan en Git.

Al almacenar y versionar el estado deseado de los sistemas en Git, podemos implementar y revertir fácilmente cambios en sistemas y aplicaciones. También podemos utilizar 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

Al utilizar 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, se pueden entregar a otros miembros del equipo para que los revisen o realicen pruebas de CI, etc.

Y al mismo tiempo, no es necesario distribuir poderes administrativos a derecha e izquierda. Para realizar cambios de configuración, los usuarios solo necesitan los permisos adecuados en el repositorio de Git donde se almacenan esas configuraciones.

Solucionar el problema de la deriva incontrolada de configuraciones

Una vez que el estado deseado del sistema se almacena en un repositorio Git, todo lo que tenemos que hacer es encontrar el software que garantice que el estado actual del sistema coincida con el estado deseado. Si este no es el caso, entonces este software debería, dependiendo de la configuración, eliminar la discrepancia por sí solo o notificarnos sobre cambios en la configuración.

Modelos GitOps para OpenShift

Conciliador de recursos en el clúster

Según este modelo, el clúster cuenta con un controlador que se encarga de comparar los recursos de Kubernetes (archivos YAML) en el repositorio Git con los recursos reales del clúster. Si se detectan discrepancias, el controlador envía notificaciones y posiblemente toma medidas para corregir las discrepancias. Este modelo de GitOps se utiliza en Anthos Config Management y Weaveworks Flux.

Conciliador de recursos externos (Push)

Este modelo se puede considerar como una variación del anterior, cuando tenemos uno o más controladores encargados de sincronizar los recursos en los pares “repositorio Git - cluster Kubernetes”. La diferencia aquí es que cada clúster administrado no necesariamente tiene su propio controlador independiente. Los pares de clústeres Git - k8s a menudo se definen como CRD (definiciones de recursos personalizados), que pueden describir cómo el controlador debe realizar la sincronización. Dentro de este modelo, los controladores comparan el repositorio Git especificado en el CRD con los recursos del clúster de Kubernetes, que también se especifican en el CRD, y realizan las acciones apropiadas en función de los resultados de la comparación. En particular, este modelo GitOps se utiliza en ArgoCD.

GitOps en la plataforma OpenShift

Administración de infraestructura Kubernetes multiclúster

Con la expansión de Kubernetes y la creciente popularidad de las estrategias de múltiples nubes y la computación de borde, el número promedio de clústeres OpenShift por cliente también está aumentando.

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

En este caso, hay que resolver muchos problemas, en particular:

Controlar que los clusters estén en idéntico estado (configuraciones, monitoreo, almacenamiento, etc.)
Recrear (o restaurar) clústeres según un estado conocido.
Cree nuevos clústeres basados en un estado conocido.
Implemente cambios en varios clústeres de OpenShift.
Revertir los cambios en varios clústeres de OpenShift.
Vincule configuraciones basadas en plantillas a diferentes entornos.

Configuraciones de aplicaciones

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

En este caso, se deben resolver las siguientes tareas:

Asegurar el movimiento de aplicaciones (binarios, configuraciones, etc.) entre clusters (dev, stage, etc.).
Implemente cambios en aplicaciones (binarios, configuraciones, etc.) en varios clústeres de OpenShift.
Revertir los cambios en las aplicaciones a un estado conocido anterior.

Casos de uso de OpenShift GitOps

1. Aplicar cambios desde el repositorio de Git

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

2. Sincronización con Secret Manager

El administrador también se beneficiará de la capacidad de sincronizar objetos secretos de OpenShift con el software adecuado como Vault para gestionarlos utilizando herramientas especialmente creadas para ello.

3. Control de configuraciones de deriva

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

4. Notificaciones sobre cambios de configuración

Son útiles cuando el administrador quiere conocer rápidamente los casos de desvío de la configuración para poder tomar rápidamente las medidas adecuadas por su cuenta.

5. Sincronización manual de configuraciones al derrapar

Permite al administrador sincronizar el clúster de OpenShift con el repositorio de Git en caso de una variación de la configuración, para devolver rápidamente el clúster a un estado conocido anterior.

6.Sincronización automática de configuraciones al derrapar

El administrador también puede configurar el clúster de OpenShift para que se sincronice automáticamente con el repositorio cuando se detecte una desviación, 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 de 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 una jerarquía de configuraciones de clúster en el repositorio (etapa, producción, cartera de aplicaciones, etc. con herencia). En otras palabras, puede determinar si las configuraciones deben aplicarse a uno o más clústeres.

Por ejemplo, si un administrador establece 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, entonces se aplica una combinación de las siguientes configuraciones a los clústeres de producción del sistema X:

Configuraciones comunes a todos los clústeres de producción.
Configuraciones para el clúster System X.
Configuraciones para el clúster de producción del sistema X.

9. Plantillas y anulaciones de configuración.

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

10. Inclusión y exclusión selectiva para configuraciones, configuraciones de aplicaciones.

El administrador puede establecer las condiciones para la aplicación o no aplicación de determinadas configuraciones a clústeres con determinadas características.

11. Soporte de plantillas

Los desarrolladores se beneficiarán de la posibilidad de elegir cómo se definirán los recursos de la aplicación (Helm Chart, Kubernetes yaml puro, etc.) para utilizar el formato más apropiado para cada aplicación específica.

Herramientas GitOps en la plataforma OpenShift

Argo CD

ArgoCD implementa el modelo de conciliación de recursos externos y ofrece una interfaz de usuario centralizada para orquestar relaciones de uno a muchos entre clústeres y repositorios Git. Las desventajas de este programa incluyen la imposibilidad de administrar aplicaciones cuando ArgoCD no está funcionando.

Sitio web oficial

Flujo

Flux implementa un modelo de conciliación de recursos en el clúster y, como resultado, no existe una gestión centralizada del repositorio de definiciones, lo cual es un punto débil. Por otro lado, precisamente debido a la falta de centralización, la capacidad de administrar aplicaciones permanece incluso si falla un clúster.

Sitio web oficial

Instalación de ArgoCD en OpenShift

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

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

Implementación 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}')

Mejora de ArgoCD Server para que pueda 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

Implementación de la herramienta ArgoCD CLI

# 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 la 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 fue”: esto es lo que dicen sobre una situación en la que se pierde la oportunidad de hacer algo. En el caso de OpenShift, el deseo de empezar a utilizar inmediatamente esta nueva e interesante plataforma a menudo crea exactamente esta situación con la gestión y el mantenimiento de rutas, implementaciones y otros objetos de OpenShift. ¿Pero siempre se pierde por completo la oportunidad?

Continuando con la serie de artículos sobre GitOps, hoy le mostraremos cómo transformar una aplicación artesanal y sus recursos en un proceso donde todo se administra mediante herramientas GitOps. Para hacer esto, primero implementaremos manualmente la aplicación httpd. La siguiente captura de pantalla muestra cómo creamos un espacio de nombres, una implementación y un servicio, y luego exponemos este servicio para crear 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 artesanal. Ahora debe transferirse bajo gestión de GitOps sin pérdida de disponibilidad. En resumen, hace esto:

Cree un repositorio Git para el código.
Exportamos nuestros objetos actuales y los subimos al repositorio de Git.
Seleccionar e implementar herramientas GitOps.
Agregamos nuestro repositorio a este kit de herramientas.
Definimos la aplicación en nuestro kit de herramientas GitOps.
Realizamos una ejecución de prueba de la aplicación utilizando el kit de herramientas GitOps.
Sincronizamos objetos usando el kit de herramientas GitOps.
Habilite la poda y la sincronización automática de objetos.

Como se mencionó en el anterior статье, en GitOps existe una y solo una fuente de información sobre todos los objetos en los clústeres de Kubernetes: el repositorio de Git. A continuación, partimos de la premisa de que su organización ya utiliza un repositorio Git. Puede ser público o privado, pero debe ser accesible 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 implementaciones. Se recomienda tener permisos estrictos en el repositorio, ya que allí se almacenarán secretos, rutas y otras cosas sensibles a la seguridad.

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

Si los archivos de objetos YAML no se almacenaron localmente o en Git, tendrá que usar los binarios oc o kubectl. En la captura de pantalla siguiente, solicitamos YAML para nuestro espacio de nombres, implementación, servicio y ruta. Antes de esto, clonamos el repositorio recién creado y lo incorporamos.

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 editemos el archivo implementación.yaml para eliminar el campo que Argo CD no puede sincronizar.

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

Además, es necesario cambiar la ruta. Primero configuraremos una variable multilínea y luego reemplazaremos ingress: null con el contenido de esa variable.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Entonces, hemos ordenado los archivos, todo lo que queda es guardarlos en el repositorio de Git. Después de lo cual 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, partimos del hecho de que ya ha implementado ArgoCD (cómo hacer esto, ver anterior enviar). Por lo tanto, agregaremos al CD de 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 creemos la aplicación. La aplicación establece valores para que el kit de herramientas de GitOps comprenda qué repositorio y rutas usar, qué OpenShift se necesita para administrar objetos, 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 una aplicación en el CD de Argo, el kit de herramientas comienza a comparar los objetos ya implementados con las definiciones en el repositorio. En nuestro ejemplo, la sincronización automática y la limpieza están deshabilitadas, por lo que los elementos no cambian todavía. Tenga en cuenta que en la interfaz de Argo CD nuestra aplicación tendrá el estado "Fuera de sincronización" porque no hay ninguna etiqueta proporcionada por ArgoCD.
Es por eso que cuando comenzamos la sincronización un poco más tarde, los objetos no se volverán a implementar.

Ahora hagamos una prueba para asegurarnos 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 se han implementado.

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
...

Ahora puede habilitar la sincronización y la limpieza automáticas para garantizar que no se cree nada manualmente y que cada vez que se cree o actualice un objeto en el repositorio, se produzca una implementación.

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

Entonces, hemos logrado poner una aplicación bajo el control de GitOps que inicialmente no usaba GitOps de ninguna manera.

Fuente: habr.com

Introducción a GitOps para OpenShift