Implementación de GitOps mediante Flux en AWS

  • 399 visualizaciones
  • 18 minuto de lectura
Hadi Bahadori
  • 8 de abril de 2024
0 acciones
0
0
0
0
0
acciones
0
0
0
0

Introducción

Si bien muchas empresas han adoptado Kubernetes en sus entornos de producción, a menudo se encuentran con dudas sobre cómo lograr la implementación continua, la alta seguridad, el aislamiento de permisos y la auditoría, todo ello garantizando la agilidad empresarial con múltiples clústeres de Kubernetes ejecutándose simultáneamente en diferentes etapas. El uso de GitOps permite dicha implementación continua basada en clústeres de Kubernetes, cumpliendo a la vez con los requisitos empresariales, como la seguridad y el aislamiento de permisos.

En este blog, implementaremos GitOps en un entorno de Amazon EKS utilizando AWS CodeCommit, AWS CodePipeline y Flux. Mostraremos en detalle cómo configurar un flujo de trabajo de GitOps que cumpla con los requisitos de producción en este entorno de Amazon EKS y demostraremos cómo las aplicaciones de microservicios logran la integración continua y la entrega continua en una canalización CI/CD al estilo de GitOps.

Requisitos previos
  • Experiencia de AWS
  • cuenta de AWS

¿Qué es GitOps?

GitOps es una metodología para implementar el despliegue continuo de aplicaciones en la nube. Se centra en una experiencia centrada en el desarrollador, aprovechando la infraestructura mediante el uso de herramientas con las que los desarrolladores ya están familiarizados, como Git y las herramientas de despliegue continuo.

La idea básica de GitOps es tener un repositorio Git que contenga una descripción detallada de la infraestructura en producción y un proceso automatizado para alinear el entorno de producción con el estado descrito en el repositorio. Si quieres desplegar una nueva aplicación o actualizar una existente, solo necesitas actualizar el repositorio. El proceso automatizado se encarga de todo. Es como tener un piloto automático para gestionar tus aplicaciones en producción.

¿Por qué usar GitOps?

Git es la única fuente de estado fiable del sistema. Permite el despliegue repetible y automatizado, la gestión de clústeres y la monitorización. Los desarrolladores reutilizan los flujos de trabajo de Git ya establecidos en la organización para la compilación, las pruebas, el análisis y otros pasos de integración continua. Una vez que el estado más reciente del sistema se confirma en la rama principal del repositorio Git, se utiliza la cadena de herramientas de GitOps para verificar el despliegue, visualizar las alertas y corregir errores. Basándonos en los principios fundamentales de GitOps, creemos que es la mejor manera de desplegar clústeres de Kubernetes de forma continua. El proceso es el siguiente:


Mejores prácticas para GitOps basadas en Amazon EKS

El pipeline general de CI/CD, según las mejores prácticas, se muestra en la figura siguiente.


Existen tres repositorios de código bajo el repositorio AWS CodeCommit. Uno repositorio de flujo es el repositorio de configuración para CD Flux, que se utiliza para definir recursos relacionados con Flujo El otro repositorio es microservices-repo, que almacena las configuraciones de la aplicación de microservicios y los archivos de despliegue. El tercero es el repositorio de código fuente para los servicios empresariales. En este artículo se utiliza un proyecto de front-end como ejemplo. Usamos AWS CodePipeline para la integración continua en el pipeline. CI/CD Utilizamos la imagen de Docker en Amazon ECR Guardamos y guardamos, y finalmente implementamos el motor Flux CD como un pod en el entorno Amazon EKS.

El flujo de trabajo básico es:
  • Los ingenieros de programación escriben el código y suben la versión final al repositorio de la aplicación.
  • Los cambios de código en el repositorio de la aplicación activan AWS CodePipeline.
  • AWS CodePipeline edita y empaqueta el código, genera imágenes de contenedor y las envía al repositorio de imágenes de contenedor/Amazon ECR.
  • El motor Flux CD, que se ejecuta en el entorno EKS, escanea regularmente el repositorio de imágenes de contenedores ECR y extrae los metadatos de las imágenes de contenedores para las aplicaciones.
  • La URL de la nueva imagen del contenedor se sincroniza automáticamente con el archivo de despliegue de la aplicación almacenado en el repositorio de microservicios mediante git commit/push cuando se detecta una nueva versión de la imagen del contenedor.
  • Flux descarga periódicamente las configuraciones de las aplicaciones y los archivos de despliegue del repositorio Flux-repo. Dado que este repositorio hace referencia al repositorio de microservicios, Flux verifica la coherencia del estado de ejecución de las cargas de trabajo del clúster con las expectativas descritas en los archivos del repositorio de microservicios. Si se detectan diferencias, Flux habilita automáticamente el clúster EKS para sincronizarlas y garantizar que las cargas de trabajo se ejecuten en el estado esperado.

Una vez explicado el concepto de GitOps y la arquitectura del pipeline CI/CD, utilizaremos un caso práctico para completar este ejercicio, revisando los siguientes cuatro módulos:

  • Despliegue de infraestructura en la nube utilizando Infraestructura como Código (IaC)
  • Implementar Flux CD en un clúster de AWS EKS
  • Implementa flujos de trabajo GitOps usando Flux CD.
  • Despliegue automatizado basado en imágenes mediante flujos de trabajo GitOps

1. Despliegue de infraestructura en la nube con IaC

Un principio fundamental de DevOps es que la infraestructura es equivalente al código. La Infraestructura como Código (IaC) utiliza código para habilitar el despliegue de infraestructura en la nube y la gestión del entorno en la nube. Los ingenieros de programación utilizan archivos de configuración o código para definir la infraestructura y la construyen con código para garantizar la consistencia y la repetibilidad. Con IaC, los ingenieros de programación también gestionan el ciclo de vida de los recursos, como el alojamiento de las definiciones de infraestructura en repositorios de control de versiones y el uso de integración y despliegue continuos (CI/CD) que sean consistentes con la programación para modificar la definición de IaC, coordinando los entornos (por ejemplo, desarrollo, pruebas, producción) con los cambios en el código de IaC. Además, es posible la reversión automática en caso de fallo, y la detección de desviaciones ayuda a identificar anomalías con respecto al estado esperado.

En la nube, los ingenieros de software pueden usar el Kit de Desarrollo en la Nube (CDK) de AWS para crear su modelo de infraestructura con Python, Java y TypeScript. El CDK proporciona componentes avanzados llamados Constructos que preconfiguran los recursos de la nube con valores predeterminados válidos. También permite a los ingenieros escribir y compartir sus propios constructos personalizados para adaptarlos a las necesidades de su organización. Todo esto agiliza los proyectos.

1.1 Crea un proyecto con la CLI de CDK.

Un proyecto CDK de TypeScript con cdk init Create, que crea la estructura de carpetas e instala los módulos necesarios para el proyecto TypeScript CDK.

cdk init --language typescript

1.2 Crear un clúster EKS con EKS Blueprints

Los planos de EKS le ayudan a crear clústeres de EKS completos, totalmente equipados con el software operativo necesario para implementar y ejecutar cargas de trabajo. Con los planos de EKS, usted describe la configuración del estado deseado de su entorno de EKS, como el panel de control, los nodos de trabajo y los complementos de Kubernetes, como un plano de IaC. Una vez configurado un plano, puede usarlo para implementar entornos consistentes en varias cuentas y regiones de AWS mediante automatización continua.

Puedes usar EKS Blueprints para configurar fácilmente un clúster EKS con los plugins de Amazon EKS, así como con una amplia gama de plugins populares de código abierto, incluidos Prometheus, Karpenter, Nginx, Traefik, AWS Load Balancer Controller, Fluent Bit, Keda, ArgoCD y muchos más. EKS Blueprints también te ayuda a implementar los controles de seguridad necesarios para ejecutar cargas de trabajo de varios equipos en un clúster.

Directorio Inicio rápido Cree y luego ejecute los siguientes códigos para instalar las dependencias del proyecto.

mkdir quickstart
cd quickstart
npm install @aws-quickstart/eks-blueprints

lib/quickstart-stack.ts Ábrelo e introduce el código. Planos de EKS Agregue lo siguiente.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as blueprints from '@aws-quickstart/eks-blueprints';
import { KubernetesVersion } from 'aws-cdk-lib/aws-eks';
export class QuickstartStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const account = props?.env?.account!;
const region = props?.env?.region!;
const clusterProvider = new blueprints.GenericClusterProvider({
version: KubernetesVersion.V1_23,
managedNodeGroups: [
{
id: "default-ng",
desiredSize: 2,
minSize: 1,
maxSize: 2,
}
]
});
const cluster = blueprints.EksBlueprint.builder()
.clusterProvider(clusterProvider)
.account(account)
.region(region)
.addOns(
new blueprints.AwsLoadBalancerControllerAddOn,
)
.teams();
}
}

En el paso anterior, creamos un clúster EKS, definimos su NodeGroup y agregamos el complemento AwsLoadBalancerController.


Si bien resulta práctico implementar una pila con la herramienta de línea de comandos de CDK, recomendamos configurar un pipeline automatizado para implementar y actualizar su infraestructura EKS. Esto facilita la implementación de entornos de desarrollo, pruebas y producción en distintas regiones.

CodePipelineStack es un marco de trabajo para la entrega continua de aplicaciones AWS CDK. Cuando el código fuente de una aplicación AWS CDK se sube a Git, el stack compila, prueba y ejecuta automáticamente las nuevas versiones. A medida que se agrega cada etapa o pila de la aplicación, se reconfigura automáticamente para implementar estas nuevas etapas o pilas.

A continuación, ejecutamos el comando cdk deploy para desplegar la pila.

Finalmente, utilizamos un comando para verificar que el balanceador de carga de la aplicación se había instalado correctamente.

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s
aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s
aws-node-9hsvz 1/1 Running 0 99m
coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m
coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m
kube-proxy-wr5jn 1/1 Running 0 99m

1.3 Resumen

En esta sección, presentamos el concepto de IaC, creamos un clúster EKS personalizado con CDK e instalamos el complemento AWS Application Load Balancer. Esto sienta las bases para acceder a las páginas web de los microservicios en el futuro. A continuación, se presenta un resumen de esta sección:

  • Se inició un proyecto CDK utilizando cdk init.
  • Definí rápidamente un clúster EKS con EKS Blueprint agregando el complemento AWS Application Load Balancer.

2. Implementar Fluxcd en un clúster de Amazon EKS

Flux CD es una herramienta de entrega continua desarrollada por Weaveworks y de código abierto para la CNCF. Su uso está muy extendido debido a su fácil configuración y su capacidad para comprender los cambios en Kubernetes. Una de sus características más importantes es que permite a los equipos gestionar sus despliegues de Kubernetes de forma declarativa. Flux CD sincroniza los archivos de manifiesto de Kubernetes almacenados en el repositorio de origen con el clúster de Kubernetes mediante sondeos periódicos del repositorio. Flux CD garantiza que el clúster de Kubernetes esté siempre sincronizado con la configuración definida en el repositorio de origen, sin necesidad de preocuparse por el estado operativo de `kube ctl` ni por monitorizar las cargas de trabajo con herramientas y servicios adicionales. Así pues, instalemos Flux.

2.1 Instalación de Flux CLI

Flux CLI es un archivo binario ejecutable para todas las plataformas que puedes descargar desde la página de lanzamientos de GitHub.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 Preparar las credenciales de AWS CodeCommit

Necesitamos crear un usuario y utilizar CodeCommit como fuente Git, así como el acceso requerido por AWS CodeCommit a través de las credenciales Git HTTPS.

2.3 Instalar Flux en el clúster

Clona el código GitOps preparado. La estructura del proyecto es la siguiente:

.
├── apps // Define Application
│ ├── base // Application Infrastructure Layer
│ └── overlays // Application Overlays Layer
├── clusters // Cluster configuration portal
│ └── dev-cluster
├── infrastructure // Infrastructure Shared Components
│ ├── base // Infrastructure Infrastructure layer
│ └── overlays // Infrastructure Overlays layer
└── README.md

Instala Flux en tu clúster de Kubernetes y configúralo para que se gestione desde un repositorio Git mediante el arranque de Flux. Si los componentes de Flux están presentes en el clúster, el comando de arranque realizará las actualizaciones necesarias. El arranque no tiene permisos de administrador y el comando se puede ejecutar varias veces sin problemas. Reemplaza el nombre de usuario y la contraseña en el siguiente comando con tus credenciales de Git HTTPS para AWS CodeCommit.

flux bootstrap git \ 
--url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ 
--username=__replace_with_your_Git_credential_username__ \ 
--password=__replace_with_your_Git_credential_password__ \ 
--token-auth=true \ 
--path="./clusters/dev-cluster" \ 
--components-extra=image-reflector-controller,image-automation-controller

Utilice `git pull` para comprobar las actualizaciones que realizó el programa de arranque. Aparecerán tres archivos nuevos en el directorio `clusters/dev-cluster/flux-system` del repositorio Git:

  • gotk-components.yaml: Define seis controladores Flux: helm, Kustomize, source, notification, image automation y image reflector.
  • gotk-sync.yaml: Fuente de Git Flux, Source Controller, cambios en el código de monitoreo del clúster en el repositorio GitOps y confirma los cambios correspondientes.
  • kustomization.yaml: Configuración multiclúster.

Comprueba si Flux se instaló correctamente con `flux get kustomizations --watch`. El resultado debería ser similar a:

$ flux get kustomizations --watch
NAME REVISION SUSPENDED READY MESSAGE 
flux-system master/83b7e66 False True Applied revision: master/83b7e66
infrastructure master/83b7e66 False True Applied revision: master/83b7e66

Comprueba los componentes desplegados por flux-system con kubectl -n flux-system get pod,services . El resultado será el siguiente:

$ kubectl -n flux-system get pod,services
NAME READY STATUS RESTARTS AGE
pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m
pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m
pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m
pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m
pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m
pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/notification-controller ClusterIP 172.20.60.72 <none> 80/TCP 11m
service/source-controller ClusterIP 172.20.133.44 <none> 80/TCP 11m
service/webhook-receiver ClusterIP 172.20.196.178 <none> 80/TCP 11m

2.4 Resumen

En esta sección, utilizamos el comando `flux bootstrap` para instalar Flux en un clúster de Kubernetes y presentamos tres archivos de configuración importantes: `gotk-components.yaml`, `gotk-sync.yaml` y `kustomization.yaml`. A continuación, se muestra un resumen de esta sección:

  • Instalación del cliente Flux
  • Creación de un usuario de IAM y credenciales de CodeCommit
  • Instala Flux en un clúster de Amazon EKS y habilita la función de actualización automática de imágenes.

3. Implementar flujos de trabajo GitOps con Flux CD

En las canalizaciones de CI/CD de GitOps, los cambios de configuración y de estado en los clústeres de EKS y las cargas de trabajo que se ejecutan en ellos se generan mediante cambios de código en Git (generados por `git push` o solicitudes de extracción; GitOps recomienda las solicitudes de extracción). La canalización de CI/CD tradicional funciona con el motor de CI y ejecuta el comando `kubectl create/apply` o `install/upgrade` para implementar el clúster. De esta forma, GitOps crea una canalización de CI/CD más eficiente y concisa.

Demostraremos una aplicación específica – “Sock Shop” – y ejercicios prácticos para mostrar cómo lograr la integración y entrega continuas en una canalización GitOps CI/CD.

3.1 Acerca de la tienda de calcetines

Utilizaremos como ejemplo la interfaz de usuario de una tienda online de calcetines. Está desarrollada con Spring Boot, GoKit y Node, y empaquetada en contenedores Docker. Tal y como muestra una demostración estándar de microservicios:

  • Buenas prácticas para el despliegue de microservicios (incluidos ejemplos de errores)
  • Capacidades de implementación multiplataforma
  • Beneficios de la integración/despliegue continuo
  • La naturaleza complementaria de DevOps y los microservicios
  • Una aplicación "real" y comprobable para diferentes plataformas de orquestación

El proyecto Socks Store consta de 8 microservicios de front-end y back-end. El front-end es una página web creada con NodeJS. El nombre del proyecto es: front-end. Accede a varios servicios de back-end mediante peticiones HTTP, entre los que se incluyen: pedidos, pagos, gestión de usuarios, gestión de productos y carrito de la compra, etc. Los datos de los servicios de back-end se almacenan en MongoDB y MySQL.

La arquitectura de referencia es la siguiente:


3.2 Acerca de Kustomize

Además de configurar flujos de trabajo de GitOps, también necesitamos saber cómo configurar Kubernetes. A medida que aumenta la complejidad del sistema y del entorno, resulta cada vez más difícil mantener la gestión tradicional basada en inventarios de recursos (YAML). Es necesario mantener y gestionar casos de uso empresariales complejos, múltiples entornos (desarrollo, pruebas, prelanzamiento, producción) y una gran cantidad de inventarios de recursos YAML. Si bien Helm puede resolver algunos problemas, como la gestión unificada de archivos de recursos dispersos, la distribución de aplicaciones, las actualizaciones y las reversiones, Helm dificulta el manejo de pequeñas diferencias entre entornos. También requiere dominar la compleja sintaxis DSL (Template Syntax), lo que supone una alta barrera de entrada. Por ello, surgió Kustomize, una herramienta de gestión de configuración declarativa. Kustomize ayuda a los equipos a gestionar grandes cantidades de recursos YAML de Kubernetes en diferentes entornos y equipos. Esto permite gestionar las pequeñas diferencias entre entornos de forma ágil, facilita la reutilización de configuraciones de recursos, reduce el esfuerzo de copia y modificación, y minimiza los errores de configuración. Todo el proceso de configuración de la aplicación no requiere aprender la sintaxis de plantillas.

Kustomize resuelve los problemas anteriores de las siguientes maneras:
  • Kustomize mantiene la configuración de la aplicación en diferentes entornos mediante Base & Overlays.
  • Kustomize utiliza Patch para reutilizar la configuración e implementación base, y la reutilización del código fuente se logra a través de la sección de diferencias entre la descripción de la superposición y la configuración de la aplicación base.
  • Kustomize gestiona archivos YAML nativos de Kubernetes sin necesidad de aprender la sintaxis DSL.

Según su sitio web oficial, Kustomize se ha convertido en una herramienta nativa de gestión de configuración para Kubernetes que permite a los usuarios personalizar los ajustes de las aplicaciones sin necesidad de plantillas. Kustomize utiliza conceptos nativos de Kubernetes para facilitar la creación y reutilización de configuraciones de origen (YAML), permitiendo a los usuarios utilizar un archivo de descripción de la aplicación (YAML) como base (Base YAML) y, posteriormente, generar el archivo de descripción necesario para la aplicación final desplegada mediante Overlays.


3.3 Configuración de múltiples clústeres

Comprendiendo la herramienta de gestión de configuración Kustomize, utilizamos Kustomization (base, superposiciones) para habilitar la transformación de la implementación en múltiples clústeres.

Creamos dos directorios en el proyecto de microservicios: el directorio base para almacenar los archivos de configuración fuente completos (YAML) y el directorio de superposiciones para almacenar diferentes entornos o configuraciones de clúster diferenciales.

Por ejemplo, en este caso, el archivo de configuración completo para el microservicio es full-demo.yaml y lo copiamos a la carpeta principal.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

Luego hacemos referencia al archivo a través de kustomization.yaml:

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./complete-demo.yaml

Para el entorno de desarrollo, si existen requisitos diferenciales, como cambiar el número de puertos de servicio y copias, simplemente configure los ajustes diferenciales en el archivo overlays/development/kustomization.yaml sin copiar ni modificar el archivo full-demo.yaml existente.

3.4 Despliegue de microservicios con el flujo de trabajo de GitOps

Tras completar la compatibilidad con múltiples clústeres para microservicios, Flux necesita saber que la configuración de los microservicios ha cambiado, por lo que registramos la URL de CodeCommit del repositorio de microservicios (microservices-repo) en el repositorio de Flux (flux-repo).

3.4.1 Agregar la dirección del repositorio de microservicios

Volvemos al repositorio Flux, a la carpeta application layer/applications:

.
├── base
│ ├── kustomization.yaml
│ └── sock-shop
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── rbac.yaml
│ └── tenant.yaml
└── overlays
└── development
├── kustomization.yaml
└── sock-shop
└── kustomization.yaml

Abra el archivo tenant.yaml en apps/base/sock-shop/ y reemplace MICRO_SERVICES_REPO con la URL de microservicios: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: sock-shop-tenant
namespace: sock-shop
spec:
interval: 1m
url: __MICRO_SERVICES_REPO__
ref:
branch: main
secretRef:
name: microservices-basic-access-auth
......

3.4.2 Adición de credenciales de CodeCommit

Busque la cuenta y la contraseña para "Preparar las credenciales de AWS CodeCommit". Convierta el valor de los datos a codificación base64 antes de ejecutar el comando.

A continuación, abre el archivo base/sock-shop/basic-access-auth.yaml y reemplaza BASE64_USERNAME y BASE64_PASSWORD con la codificación base64 generada:

---
apiVersion: v1
kind: Secret
metadata:
name: microservices-basic-access-auth
namespace: sock-shop
type: Opaque
data:
username: __BASE64_USERNAME__
password: __BASE64_PASSWORD__

3.4.3 Despliegue

Al agregar la URL de Git del microservicio al repositorio de configuración de Flux, Flux escanea automáticamente los cambios de configuración. Una vez confirmado el código, Flux verifica si hay microservicios desplegados en el clúster y si coinciden con la definición del repositorio de Git; de lo contrario, Flux despliega automáticamente los microservicios en el clúster.

Tras ejecutar el código, ejecute el comando `flux get kustomizations -watch` y espere a que Flux se actualice. El despliegue se completa cuando el estado READY de todas las personalizaciones es True.

Busque pods y servicios en el espacio de nombres de la tienda de calcetines, que se muestra a continuación:

$ kubectl get pod,service -n sock-shop
NAME READY STATUS RESTARTS AGE
pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s
pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s
pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s
pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s
pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s
pod/orders-7664c64d75-lqwbm 1/1 Running 0 5m28s
pod/orders-db-659949975f-qv7pl 1/1 Running 0 5m28s
pod/payment-7bcdbf45c9-szrfq 1/1 Running 0 5m28s
pod/queue-master-5f6d6d4796-nkktx 1/1 Running 0 5m28s
pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Running 0 5m28s
pod/session-db-7cf97f8d4f-9mz6v 1/1 Running 0 5m28s
pod/shipping-7f7999ffb7-95rlc 1/1 Running 0 5m27s
pod/user-68df64db9c-kh247 1/1 Running 0 5m27s
pod/user-db-6df7444fc-jlkp9 1/1 Running 0 5m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/carts ClusterIP 172.20.33.124 <none> 80/TCP 5m29s
service/carts-db ClusterIP 172.20.75.163 <none> 27017/TCP 5m29s
service/catalogue ClusterIP 172.20.92.254 <none> 80/TCP 5m29s
service/catalogue-db ClusterIP 172.20.242.255 <none> 3306/TCP 5m29s
service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s
service/orders ClusterIP 172.20.8.252 <none> 80/TCP 5m29s
service/orders-db ClusterIP 172.20.40.212 <none> 27017/TCP 5m29s
service/payment ClusterIP 172.20.6.218 <none> 80/TCP 5m29s
service/queue-master ClusterIP 172.20.153.80 <none> 80/TCP 5m29s
service/rabbitmq ClusterIP 172.20.99.37 <none> 5672/TCP,9090/TCP 5m29s
service/session-db ClusterIP 172.20.37.111 <none> 6379/TCP 5m29s
service/shipping ClusterIP 172.20.43.252 <none> 80/TCP 5m29s
service/user ClusterIP 172.20.220.174 <none> 80/TCP 5m29s
service/user-db ClusterIP 172.20.70.57 <none> 27017/TCP 5m29s

Acceda al nombre DNS del balanceador de carga de AWS.


3.5 Resumen

En esta sección, presentamos una aplicación empresarial de microservicios, la tienda online Sock Shop, y completamos su configuración multiclúster. También creamos un flujo de trabajo GitOps estándar basado en Flux que sincroniza automáticamente el clúster de destino con los cambios en los archivos de configuración para completar el despliegue del microservicio en el clúster EKS. Asimismo, presentamos una herramienta práctica de gestión de configuración, K8s-Kustomize, y cómo gestionar los archivos de recursos de la aplicación. A continuación, un resumen de esta sección:

  • Presentamos la tienda de calcetines
  • Aprenda a utilizar la herramienta de gestión de configuración Kustomize (base, overlays) y cómo modificar las implementaciones de microservicios en múltiples clústeres.
  • Crea un flujo de trabajo GitOps e implementa microservicios.

4. Despliegue automatizado basado en imágenes con flujos de trabajo GitOps

Elegimos el microservicio front-end de Sock Shop como ejemplo para demostrar el proceso detallado de cambios de código, compilación de imágenes y lanzamiento personalizado con un flujo de trabajo GitOps.

4.1 Definición de CodePipeline CI

El front-end es un servicio front-end puro de Node.js para dar soporte al empaquetado de imágenes Docker (consulte la sección «Arquitecto de Sock Shop» en el capítulo 3.1 para obtener más detalles). Para definir el proceso de CI que se ejecuta en CodePipeline, añada un archivo buildspec.yml al código fuente del proyecto front-end:

version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws --version
- AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
- AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
- echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
- echo $IMAGE_TAG
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG

Este proceso de integración continua crea automáticamente una imagen y la sube al repositorio ECR weaveworksdemos/front-end cuando se modifica el código del front-end. El formato de la etiqueta de la imagen es [rama]-[commit]-[número de compilación].

4.2 Actualización automática de imágenes

Cuando trabajas en un entorno ágil con integración continua, como al realizar pruebas de desarrollo, actualizar tu repositorio GitOps o usar scripts para gestionar nuevas imágenes de servicio puede ser muy engorroso. Por suerte, Flux cuenta con una excelente función de actualización automática de imágenes que se encarga de esto. Para usarla, solo necesitas habilitar el componente de actualización de imágenes en tu configuración. Si aún no lo has hecho, no te preocupes, simplemente agrega los parámetros `--components-extra=image-reflector-controller,image-automation-controller` al iterar sobre el bootstrap de Flux para habilitarlo.

Para lograr actualizaciones automáticas basadas en imágenes, debemos realizar los siguientes pasos:

  • Registre el repositorio de imágenes del microservicio front-end para permitir que Flux escanee periódicamente el informe del repositorio de imágenes ECR en el proyecto front-end.
  • Configure las credenciales para acceder al repositorio de imágenes. Flux requiere credenciales para acceder al repositorio de imágenes ECR y leer la información de las imágenes.
  • Configure la política de actualización de imágenes. En la mayoría de los casos, no queremos que todos los cambios en las versiones de las imágenes activen la implementación de CD cada vez. En cambio, solo queremos que el código de la rama (raíz) especificada active la implementación de CD. Se necesita una política de actualización especial para cumplir con este requisito.

A continuación, completaremos las operaciones anteriores una por una.

4.2.1 Agregar una política de imágenes al frontend de un repositorio Git

En el proyecto del repositorio de microservicios, utilizaremos overlays de Kustomization en el entorno de desarrollo para reemplazar la interfaz de usuario del microservicio con una versión personalizada y actualizada. Modifique el archivo deploy/kubernetes/overlays/development/kustomization.yaml. (Nota: Reemplace ACCOUNT_ID con su ACCOUNT_ID).

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: weaveworksdemos/front-end
newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 Registro del front-end de un microservicio en Flux-repo

En el proyecto flux-repo, cree un nuevo archivo apps/overlays/development/sock-shop/registry.yaml y reemplace ACCOUNT_ID con su ACCOUNT_ID.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: sock-shop-front-end
namespace: sock-shop
spec:
image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
interval: 1m0s

4.2.3 Configuración de las credenciales de acceso para Amazon ECR

En Flux existen dos métodos para obtener las credenciales de Amazon ECR.

  • Mecanismo de autenticación automática (Image Reflector Controller recupera las credenciales por sí mismo, solo para: Amazon ECR, GCP GCR, Azure ACR)
  • Recuperar periódicamente las credenciales (almacenadas en el clúster mediante Secret) con CronJob.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
- patch: |-
- op: add
path: /spec/template/spec/containers/0/args/-
value: --aws-autologin-for-ecr
target:
version: v1
group: apps
kind: Deployment
name: image-reflector-controller
namespace: flux-system

4.2.4 Configuración de la política de actualización de imágenes

Agregue el archivo gitops/apps/overlays/development/sock-shop/policy.yaml. Las siguientes reglas corresponden a versiones de imagen como master-d480788-1, master-d480788-2 y master-d480788-3.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: sock-shop-front-end
spec:
imageRepositoryRef:
name: sock-shop-front-end
filterTags:
pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
extract: '$buidnumber'
policy:
numerical:
order: asc

Agregue el archivo gitops/apps/overlays/development/sock-shop/image-automation.yaml. La automatización de imágenes de Flux especifica un repositorio Git para la configuración de la aplicación, incluyendo la rama, la ruta y otra información.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: [email protected]
name: fluxcdbot
messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
push:
branch: main
interval: 5m0s
sourceRef:
kind: GitRepository
name: sock-shop-tenant
namespace: sock-shop
update:
path: ./deploy/kubernetes/overlays/development
strategy: Setters

4.3 Publicación y aprobación

Verificamos todo el proceso de actualización automática de imágenes modificando el código fuente del front-end.

4.3.1 Actualizar el código del front-end

Cambie el pie de página del front-end y modifique el archivo: front-end/public/footer.html.


4.3.2 Comprobar CodePipeline

Los cambios de código en el front-end activan automáticamente la ejecución de CodePipeline.


4.3.3 Confirmación del cambio de versión de la imagen ECR

Una vez finalizado CodePipeline, inicie sesión en la consola de Amazon ECR para comprobar la versión de la imagen weaveworksdemos/front-end:


4.3.4 Comprobación de la información de la imagen de flujo

A través de Flux CLI, compruebe si ImageRepository e ImagePolicy han recuperado correctamente la última versión.

$ flux get images all --all-namespaces
NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE 
sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags
NAMESPACE NAME LATEST IMAGE READYMESSAGE 
sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24
NAMESPACE NAME LAST RUN SUSPENDED READY MESSAGE 
sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True no updates made; last commit 1ff6d91 at 2022-09-18T14:34:40Z

4.3.5 El código fuente del microservicio se actualiza automáticamente

Flux actualizó automáticamente la versión de la imagen del front-end. El último commit lo realizó fluxcdbot y la etiqueta de la imagen se modificó correctamente a la última versión: master-1f49071-24.


4.3.6 Verificación de la versión de la imagen del pod

Verifique el nombre del pod con `kubectl get pod -n sock-shop | grep front-end`. Consulte los detalles del pod con `kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep`. Imagen: Para verificar la actualización de la versión de la imagen, se mostrará lo siguiente:

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image:
Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 Verifique que la página estática esté actualizada.


4.4 Resumen

En esta sección, hemos descrito en detalle el proceso completo de despliegue automatizado basado en imágenes. En resumen, utilizamos la capacidad de monitorización continua de Flux para los repositorios de imágenes. Cuando se detecta un cambio en la versión de una imagen, se modifica automáticamente su configuración en el repositorio Git y se completa el despliegue automatizado conectándose al flujo de trabajo estándar de GitOps descrito en la sección anterior. En resumen:

  • Ejecuta el proceso de CI a través de CodePipeline para lograr la integración continua del código front-end.
  • Localice y modifique el archivo de configuración empresarial con anotaciones Flux.
  • Configure la política de actualización de imágenes de Flux para permitir que Flux supervise versiones específicas de las imágenes y automatice completamente la implementación.

Resultado

Este artículo se centra en cómo usar FluxCD para automatizar el despliegue de microservicios en un clúster de Amazon EKS en la nube, así como en las mejores prácticas para pipelines de GitOps. GitOps es una metodología de entrega continua que engloba un conjunto de buenas prácticas. No existen límites estrictos para crear herramientas de CI/CD siempre que se adhieran a los fundamentos de GitOps.

En este artículo:
,
Artículo escrito por:
Seguir
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Artículo anterior
Artículo siguiente
También te puede gustar