Tutorial: Implementación de CI/CD con GitOps (Flux v2)

En este tutorial va a configurar una solución de CI/CD con GitOps con Flux v2 y los clústeres de Kubernetes habilitados para Azure Arc o los clústeres de Azure Kubernetes Service (AKS). Con la aplicación de votaciones de ejemplo de Azure llevará a cabo las siguientes tareas:

• Crear un clúster de Kubernetes habilitado para Azure Arc o un clúster de AKS.
• Conecte los repositorios de la aplicación y de GitOps a Azure Repos o GitHub.
• Implemente el flujo de CI/CD con Azure Pipelines o GitHub.
• Conecte la instancia de Azure Container Registry a Azure DevOps y Kubernetes.
• Cree los grupos de variables de entorno o los secretos.
• Implementar los entornos dev y stage.
• Probar los entornos de la aplicación.

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.

Para iniciar Azure Cloud Shell:

Opción	Ejemplo o vínculo
Seleccione Pruébelo en la esquina superior derecha de un bloque de código o de comandos. Solo con seleccionar Pruébelo no se copia automáticamente el código o comando en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la esquina superior derecha de Azure Portal.

Para usar Azure Cloud Shell:

1. Inicie Cloud Shell.

2. Seleccione el botón Copiar en un bloque de código (o bloque de comandos) para copiar el código o comando.

3. Pegue el código o comando en la sesión de Cloud Shell. Para ello, seleccione Ctrl+Mayús+V en Windows y Linux, o bien seleccione Cmd+Mayús+V en macOS.

4. Seleccione Enter para ejecutar el código o comando.

Requisitos previos

• Complete el tutorial anterior para obtener información sobre cómo implementar GitOps para su entorno de CI/CD.

• Conozca las ventajas y arquitectura de esta característica.

• Compruebe que tiene:

  • Un clúster de Kubernetes conectado habilitado para Azure Arc con el nombre arc-cicd-cluster.
  • Una instancia conectada de Azure Container Registry con la integración de AKS o la autenticación de un clúster que no es de AKS.

• Instale las versiones más recientes de estas extensiones de la CLI de Kubernetes habilitado para Azure Arc y Configuración de Kubernetes:

  az extension add --name connectedk8s
  az extension add --name k8s-configuration
  

  • Para actualizar las extensiones a la versión más reciente, ejecute los siguientes comandos:

    az extension update --name connectedk8s
    az extension update --name k8s-configuration
    

Conexión de Azure Container Registry a Kubernetes

Habilite el clúster de Kubernetes para extraer imágenes de la instancia de Azure Container Registry. Si es privada, se requiere autenticación.

Conexión de Azure Container Registry a clústeres existentes de Kubernetes

Integre una instancia de Azure Container Registry existente con los clústeres de AKS existentes mediante el siguiente comando:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Creación de un secreto de extracción de imágenes

Para conectar los clústeres locales y los que no son de AKS a la instancia de Azure Container Registry, cree un secreto de extracción de imágenes. Kubernetes usa secretos de extracción de imágenes para almacenar la información necesaria para autenticarse en el registro.

Cree un secreto de extracción de imágenes con el siguiente comando kubectl: Repita el procedimiento con los espacios de nombres dev y stage.

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Para evitar tener que establecer un secreto de extracción de imágenes para cada pod, considere la posibilidad de agregar el secreto de extracción de imágenes a la cuenta de servicio en los espacios de nombres dev y stage. Consulte el tutorial de Kubernetes para más información.

En función del orquestador de CI/CD que prefiera, puede continuar con las instrucciones para Azure DevOps o para GitHub.

Implementación de CI/CD con Azure DevOps

En este tutorial se da por supuesto que está familiarizado con Azure DevOps, Azure Repos, Azure Pipelines y la CLI de Azure.

Asegúrese de completar los pasos siguientes primero:

• Inicie sesión en Azure DevOps Services.
• Debe tener permisos de "Administrador de compilación" y "Administrador de proyectos" para Azure Repos y Azure Pipelines.

Importación de los repositorios de la aplicación y de GitOps en Azure Repos

Importe un repositorio de aplicaciones y un repositorio de GitOps en Azure Repos. Para este tutorial, use los siguientes repositorios de ejemplo:

• Repositorio de la aplicación arc-cicd-demo-src

  • Dirección URL: https://github.com/Azure/arc-cicd-demo-src
  • Contiene la aplicación de votaciones de Azure de ejemplo que se va a implementar con GitOps.
  • Importar el repositorio con el nombre arc-cicd-demo-src

• Repositorio de GitOps arc-cicd-demo-gitops

  • Dirección URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funciona como base para los recursos del clúster que hospedan la aplicación de votaciones de Azure.
  • Importar el repositorio con el nombre arc-cicd-demo-gitops

Obtenga más información sobre la Importación de repositorios de Git.

Nota

La importación y el uso de dos repositorios diferentes para la aplicación y los repositorios de GitOps puede mejorar la seguridad y la simplicidad. Los permisos y la visibilidad de los repositorios de la aplicación y de GitOps se pueden optimizar individualmente. Por ejemplo, es posible que el administrador del clúster no encuentre los cambios en el código de la aplicación correspondientes al estado deseado del clúster. Por el contrario, un desarrollador de aplicaciones no necesita conocer los parámetros específicos de cada entorno: un conjunto de valores de prueba que proporcione cobertura para los parámetros puede ser suficiente.

Conexión del repositorio de GitOps

Para la implementación continua de la aplicación, conecte el repositorio de la aplicación al clúster mediante GitOps. El repositorio de GitOps arc-cicd-demo-gitops contiene los recursos básicos para poner en funcionamiento la aplicación en el clúster arc-cicd-cluster.

El repositorio inicial de GitOps solo contiene un manifiesto que crea los espacios de nombres dev y stage correspondientes a los entornos de implementación.

La conexión de GitOps que va a crear realizará automáticamente las siguientes acciones:

• Sincronizar los manifiestos en el directorio de manifiestos.
• Actualizar el estado del clúster.

El flujo de trabajo de CI/CD rellena el directorio de manifiestos con manifiestos adicionales para implementar la aplicación.

1. Cree una nueva conexión de GitOps al repositorio arc-cicd-demo-gitops recién importado en Azure Repos.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace flux-system \
      --resource-group myResourceGroup \
      -u https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

   Sugerencia

   Para un clúster de AKS (en lugar de un clúster habilitado para Arc), use -cluster-type managedClusters.

2. Compruebe el estado de la implementación en Azure Portal.

   • Si se realiza correctamente, verá que se han creado en el clúster los espacios de nombres dev y stage.
   • También puede confirmar que, en la página Azure Portal del clúster, se crea una configuración cluster-config en la pestaña fGitOps.

Importación de las canalizaciones de CI/CD

Ahora que ha sincronizado una conexión de GitOps, deberá importar las canalizaciones de CI/CD que crean los manifiestos.

El repositorio de la aplicación contiene la carpeta .pipeline con las canalizaciones que se van a utilizar para las solicitudes de incorporación de cambios (PR), CI y CD. Importe y cambie el nombre de las tres canalizaciones proporcionadas en el repositorio de ejemplo:

Nombre del archivo de la canalización.	Descripción
.pipelines/az-vote-pr-pipeline.yaml	Canalización de PR de la aplicación, llamada arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml	Canalización de CI de la aplicación, llamada arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml	Canalización de CD de la aplicación, llamada arc-cicd-demo-src CD

Conexión de Azure Container Registry a Azure DevOps

Durante el proceso de CI, implementará los contenedores de la aplicación en un registro. Empiece por crear una conexión de servicio de Azure:

1. En Azure DevOps, abra la página Conexiones de servicio desde la página de configuración del proyecto. En TFS, abra la página Servicios desde el icono de Configuración en la barra de menús superior.
2. Elija + Nueva conexión de servicio y seleccione el tipo de conexión de servicio que necesite.
3. Rellene los parámetros para la conexión de servicio. En este tutorial:
   • Asigne el nombre arc-demo-acr a la conexión de servicio.
   • Seleccione myResourceGroup como grupo de recursos.
4. Seleccione Conceder permiso de acceso a todas las canalizaciones.
   • Esta opción autoriza los archivos de canalización de YAML para las conexiones de servicio.
5. Elija Aceptar para crear la conexión.

Configuración de la conexión del servicio PR

La canalización de CD manipula elementos de PR en el repositorio de GitOps. Para esto necesita una conexión de servicio. Para configurar esta conexión:

1. En Azure DevOps, abra la página Conexiones de servicio desde la página de configuración del proyecto. En TFS, abra la página Servicios desde el icono de Configuración en la barra de menús superior.
2. Elija + Nueva conexión de servicio y seleccione el tipo Generic.
3. Rellene los parámetros para la conexión de servicio. En este tutorial:
   • Dirección URL del servidor https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
   • Deje vacíos los campos Nombre de usuario y Contraseña.
   • Asigne a la conexión de servicio el nombre azdo-pr-connection.
4. Seleccione Conceder permiso de acceso a todas las canalizaciones.
   • Esta opción autoriza los archivos de canalización de YAML para las conexiones de servicio.
5. Elija Aceptar para crear la conexión.

Instalación del conector de GitOps

1. Agregue el repositorio del conector de GitOps a los repositorios de Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Instale el conector en el clúster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=AZDO \
         --set ciCdOrchestratorType=AZDO \
         --set gitOpsOperatorType=FLUX \
         --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
         --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
         --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
         --set orchestratorPAT=<Azure Repos PAT token>
   

   Nota:

   Azure Repos PAT token debe tener permisos de Build: Read & execute y Code: Full.

3. Configure Flux para enviar notificaciones al conector de GitOps:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config 
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Para obtener más información sobre la instalación, consulte el repositorio del Conector de GitOps.

Creación de grupos de variables de entorno

Grupo de variables del repositorio de aplicaciones

Cree un grupo de variables llamado az-vote-app-dev. Establezca los valores siguientes:

Variable	Value
AZURE_SUBSCRIPTION	(conexión de servicio de Azure, que debe ser arc-demo-acr, creada anteriormente en el tutorial)
AZ_ACR_NAME	Nombre de Azure ACR, por ejemplo arc-demo-acr
ENVIRONMENT_NAME	Desarrollo
MANIFESTS_BRANCH	master
MANIFESTS_REPO	arc-cicd-demo-gitops
ORGANIZATION_NAME	Nombre de la organización de Azure DevOps
PROJECT_NAME	Nombre del proyecto de GitOps en Azure DevOps
REPO_URL	Dirección URL completa del repositorio de GitOps
SRC_FOLDER	azure-vote
TARGET_CLUSTER	arc-cicd-cluster
TARGET_NAMESPACE	dev
VOTE_APP_TITLE	Aplicación de votación
AKS_RESOURCE_GROUP	Grupo de recursos de AKS. Es necesario para las pruebas automatizadas.
AKS_NAME	Nombre de AKS. Es necesario para las pruebas automatizadas.

Grupo de variables del entorno de fase

1. Clone el grupo de variables az-vote-app-dev.
2. Cambie el nombre a az-vote-app-stage.
3. Asegúrese de establecer los siguientes valores para las variables correspondientes:

Variable	Value
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	stage

Ahora está listo para realizar la implementación en los entornos dev y stage.

Creación de entornos

En el proyecto de Azure DevOps, cree los entornos Dev y Stage. Consulte Creación de un entorno y selección como destino para más detalles.

Concesión de más permisos al servicio de compilación

La canalización de CD usa el token de seguridad de la compilación en ejecución para autenticarse en el repositorio de GitOps. Se necesitan más permisos para que la canalización cree una nueva rama, inserte cambios y cree solicitudes de extracción.

1. Vaya a Project settings desde la página principal del proyecto de Azure DevOps.
2. Seleccione Repos/Repositories.
3. Seleccione Security.
4. Para <Project Name> Build Service (<Organization Name>) y para Project Collection Build Service (<Organization Name>) (escriba en el campo de búsqueda, si no aparece), permita Contribute, Contribute to pull requestsy Create branch.
5. Vaya a Pipelines/Settings.
6. Opción desactivar Protect access to repositories in YAML pipelines

Para más información, consulte:

• Concesión de permisos de VC al servicio de compilación
• Administración de permisos de cuenta de servicio de compilación

Implementación en el entorno de desarrollo por primera vez

Con las canalizaciones de CI y CD creadas, ejecute la canalización de CI para implementar la aplicación por primera vez.

Canalización de CI

Durante la ejecución inicial de la canalización de CI, puede obtener un error de autorización de recursos al leer el nombre de la conexión de servicio.

1. Compruebe que la variable a la que se accede es AZURE_SUBSCRIPTION.
2. Autorice el uso.
3. vuelva a ejecutar la canalización.

La canalización de CI:

• Garantiza que el cambio de la aplicación supera todas las comprobaciones de calidad automatizadas para la implementación.
• Realiza cualquier validación adicional que no se pudo completar en la canalización de PR.
  • Específicamente para GitOps, la canalización también publica los artefactos para la confirmación que se implementará mediante la canalización de CD.
• Comprueba que la imagen de Docker ha cambiado y que se ha insertado la nueva imagen.

Canalización de CD

Durante la ejecución inicial de la canalización de CD, deberá proporcionar acceso a la canalización al repositorio de GitOps. Seleccione Ver cuando se le indique que la canalización necesita permiso para acceder a un recurso. A continuación, seleccione Permitir para conceder permiso de uso del repositorio de GitOps para las ejecuciones actuales y futuras de la canalización.

La ejecución correcta de la canalización de CI desencadena la canalización de CD para completar el proceso de implementación. Realizará la implementación en cada entorno de forma incremental.

Sugerencia

Si la canalización de CD no se desencadena automáticamente:

1. Compruebe que el nombre coincide con el desencadenador de rama en .pipelines/az-vote-cd-pipeline.yaml.
   • Debería ser arc-cicd-demo-src CI.
2. Vuelva a ejecutar la canalización de CI.

Una vez que se hayan generado los cambios de plantilla y de manifiesto en el repositorio de GitOps, la canalización de CD creará una confirmación, la insertará y creará una solicitud de incorporación de cambios para su aprobación.

1. Busque el elemento PR que ha creado la canalización en el repositorio de GitOps.

2. Compruebe los cambios en el repositorio de GitOps. Debería ver lo siguiente:

   • La plantilla de Helm de alto nivel ha cambiado.
   • Los manifiestos de Kubernetes de bajo nivel que muestran los cambios subyacentes en el estado deseado. Flux implementa estos manifiestos.

3. Si todo parece correcto, apruebe y complete la solicitud de incorporación de cambios.

4. Después de unos minutos, Flux recoge el cambio e inicia la implementación.

5. Supervise el estado de confirmación de Git en la pestaña Historial de confirmaciones. Una vez que sea succeeded, la canalización de CD iniciará las pruebas automatizadas.

6. Reenvíe el puerto de forma local mediante kubectl y asegúrese de que la aplicación funciona correctamente mediante:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Vaya a la aplicación de votaciones de Azure en el explorador en http://localhost:8080/.

8. Vote a sus favoritos y prepárese para realizar algunos cambios en la aplicación.

Configuración de las aprobaciones de entorno

Tras la implementación de la aplicación, no solo puede realizar cambios en el código o las plantillas, sino que también puede poner involuntariamente el clúster en un estado incorrecto.

Si el entorno de desarrollo revela una interrupción después de la implementación, evite que siga en entornos posteriores con las aprobaciones de entorno.

1. En el proyecto de Azure DevOps, vaya al entorno que se va a proteger.
2. Vaya a Aprobaciones y comprobaciones en el recurso.
3. Seleccione Crear.
4. Proporcione los aprobadores y un mensaje opcional.
5. Seleccione de nuevo Crear para completar la adición de la comprobación de aprobación manual.

Para más información, consulte el tutorial Definición de aprobaciones y comprobaciones.

La próxima vez que se ejecute la canalización de CD, la canalización se pondrá en pausa después de la creación de la PR de GitOps. Compruebe que el cambio se haya sincronizado correctamente y de que supera la funcionalidad básica. Apruebe la comprobación desde la canalización para permitir que el cambio fluya al siguiente entorno.

Realización de un cambio en la aplicación

Con este conjunto de plantillas y manifiestos de línea base que representan el estado del clúster, va a realizar un pequeño cambio en la aplicación.

1. En el repositorio arc-cicd-demo-src, edite el archivo azure-vote/src/azure-vote-front/config_file.cfg.

2. Como "gatos frente a perros" no está obteniendo suficientes votos, cámbielo a "tabuladores frente a espacios" para impulsar la participación.

3. Confirme el cambio en una nueva rama, insértelo y cree una solicitud de incorporación de cambios. Esta secuencia de pasos es el flujo de desarrollador típico que iniciará el ciclo de vida de CI/CD.

Canalización de validación de PR

La canalización de PR es la primera línea de defensa contra un cambio erróneo. Las comprobaciones de la calidad del código de la aplicación habituales incluyen el linting y el análisis estático. Desde la perspectiva de GitOps, también debe asegurarse de la misma calidad para la infraestructura resultante que se va a implementar.

El archivo Dockerfile y los gráficos de Helm de la aplicación pueden usar el linting de una manera similar a la aplicación.

Errores encontrados durante el intervalo de linting desde archivos YAML con formato incorrecto, hasta sugerencias de procedimientos recomendados, como establecer límites de CPU y memoria para la aplicación.

Nota

Para obtener la mejor cobertura del linting de Helm en una aplicación real, deberá sustituir los valores que sean razonablemente similares a los que se usan en un entorno real.

Los errores encontrados durante la ejecución de la canalización aparecen en la sección de resultados de las pruebas de la ejecución. Desde aquí, puede:

• Realizar un seguimiento de las estadísticas de utilidad sobre tipos de error.
• Buscar la primera confirmación en la que se detectaron.
• Realizar un seguimiento de la pila de los vínculos de estilo a las secciones de código que produjeron el error.

Una vez finalizada la ejecución de la canalización, habrá asegurado la calidad del código de la aplicación y de la plantilla que lo implementará. Ahora puede aprobar y completar la solicitud de incorporación de cambios. La canalización de CI se ejecutará de nuevo, con lo que se volverán a generar las plantillas y los manifiestos antes de desencadenar la canalización de CD.

Sugerencia

En un entorno real, no olvide establecer directivas de rama para asegurarse de que la solicitud de incorporación de cambios supera las comprobaciones de calidad. Para más información, consulte Establecimiento de las directivas de rama.

Aprobaciones del proceso de CD

La ejecución correcta de la canalización de CI desencadena la canalización de CD para completar el proceso de implementación. Esta vez, la canalización requiere que apruebe cada entorno de implementación.

1. Apruebe la implementación en el entorno dev.
2. Una vez que se hayan generado los cambios de plantilla y de manifiesto en el repositorio de GitOps, la canalización de CD creará una confirmación, la insertará y creará una solicitud de incorporación de cambios para su aprobación.
3. Compruebe los cambios en el repositorio de GitOps. Debería ver lo siguiente:
   • La plantilla de Helm de alto nivel ha cambiado.
   • Los manifiestos de Kubernetes de bajo nivel que muestran los cambios subyacentes en el estado deseado.
4. Si todo parece correcto, apruebe y complete la solicitud de incorporación de cambios.
5. Espere a que la implementación se complete.
6. Como prueba de aceptación de la compilación básica, vaya a la página de la aplicación y compruebe que la aplicación de votación ahora muestra la encuesta Tabuladores frente a espacios.
   • Reenvíe el puerto de forma local mediante kubectl y asegúrese de que la aplicación funciona correctamente mediante: kubectl port-forward -n dev svc/azure-vote-front 8080:80
   • Vaya a la aplicación de votaciones de Azure en el explorador en http://localhost:8080/ y compruebe que las opciones de votación han cambiado a la encuesta Tabuladores frente a espacios.
7. Repita los pasos del 1 al 7 para el entorno stage.

La implementación ha finalizado.

Para información general detallada de todos los pasos y técnicas implementados en los flujos de trabajo de CI/CD que se usan en este tutorial, consulte el diagrama de flujo de GitOps de Azure DevOps.

Implementación de CI/CD con GitHub

En este tutorial se da por supuesto que está familiarizado con GitHub y GitHub Actions.

Aplicación de bifurcación y repositorios de GitOps

Bifurque un repositorio de aplicaciones y un repositorio de GitOps. Para este tutorial, use los siguientes repositorios de ejemplo:

• Repositorio de la aplicación arc-cicd-demo-src

  • Dirección URL: https://github.com/Azure/arc-cicd-demo-src
  • Contiene la aplicación de votaciones de Azure de ejemplo que se va a implementar con GitOps.

• Repositorio de GitOps arc-cicd-demo-gitops

  • Dirección URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funciona como base para los recursos del clúster que hospedan la aplicación de votaciones de Azure.

Conexión del repositorio de GitOps

Para la implementación continua de la aplicación, conecte el repositorio de la aplicación al clúster mediante GitOps. El repositorio de GitOps arc-cicd-demo-gitops contiene los recursos básicos para poner en funcionamiento la aplicación en el clúster arc-cicd-cluster.

El repositorio inicial de GitOps solo contiene un manifiesto que crea los espacios de nombres dev y stage correspondientes a los entornos de implementación.

La conexión de GitOps que va a crear realizará automáticamente las siguientes acciones:

• Sincronizar los manifiestos en el directorio de manifiestos.
• Actualizar el estado del clúster.

El flujo de trabajo de CI/CD rellena el directorio de manifiestos con manifiestos adicionales para implementar la aplicación.

1. Cree una nueva conexión de GitOps al repositorio arc-cicd-demo-gitops recién importado en GitHub.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace cluster-config \
      --resource-group myResourceGroup \
      -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

2. Compruebe el estado de la implementación en Azure Portal.

   • Si se realiza correctamente, verá que se han creado en el clúster los espacios de nombres dev y stage.

Instalación del conector de GitOps

1. Agregue el repositorio del conector de GitOps a los repositorios de Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Instale el conector en el clúster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=GITHUB \
         --set ciCdOrchestratorType=GITHUB \
         --set gitOpsOperatorType=FLUX \
         --set gitHubGitOpsRepoName=arc-cicd-demo-src \
         --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
         --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
         --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
         --set orchestratorPAT=<GitHub PAT token>
   

3. Configure Flux para enviar notificaciones al conector de GitOps:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Para obtener más información sobre la instalación, consulte el repositorio del Conector de GitOps.

Creación de secretos de GitHub

Creación de secretos del repositorio de GitHub

Secreto	Value
AZURE_CREDENTIALS	Credenciales de Azure con el siguiente formato {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME	Nombre de Azure ACR, por ejemplo arc-demo-acr
MANIFESTS_BRANCH	master
MANIFESTS_FOLDER	arc-cicd-cluster
MANIFESTS_REPO	https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE	Aplicación de votación
AKS_RESOURCE_GROUP	Grupo de recursos de AKS. Es necesario para las pruebas automatizadas.
AKS_NAME	Nombre de AKS. Es necesario para las pruebas automatizadas.
PAT	Token PAT de GitHub con permiso para PR en el repositorio de GitOps

Creación de secretos de entorno en GitHub

1. Cree un entorno az-vote-app-dev con los siguientes secretos:

Secreto	Value
ENVIRONMENT_NAME	Desarrollo
TARGET_NAMESPACE	dev

1. Cree un entorno az-vote-app-stage con los siguientes secretos:

Secreto	Value
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	stage

Ahora está listo para realizar la implementación en los entornos dev y stage.

Flujo de trabajo de desarrollo de CI/CD

Para iniciar el flujo de trabajo de desarrollo de CI/CD, cambie el código fuente. En el repositorio de la aplicación, actualice los valores del archivo .azure-vote/src/azure-vote-front/config_file.cfg e implemente los cambios en el repositorio.

Flujo de trabajo de desarrollo de CI/CD:

• Garantiza que el cambio de la aplicación supera todas las comprobaciones de calidad automatizadas para la implementación.
• Realiza cualquier validación adicional que no se pudo completar en la canalización de PR.
• Comprueba que la imagen de Docker ha cambiado y que se ha insertado la nueva imagen.
• Publica los artefactos (etiquetas de imagen de Docker, plantillas de manifiesto, utilidades) que se usarán en las siguientes fases de CD.
• Implementa la aplicación en el entorno de desarrollo.
  • Genera manifiestos en el repositorio de GitOps.
  • Crea una solicitud de incorporación de cambios en el repositorio de GitOps para su aprobación.

1. Busque el elemento PR que ha creado la canalización en el repositorio de GitOps.

2. Compruebe los cambios en el repositorio de GitOps. Debería ver lo siguiente:

   • La plantilla de Helm de alto nivel ha cambiado.
   • Los manifiestos de Kubernetes de bajo nivel que muestran los cambios subyacentes en el estado deseado. Flux implementa estos manifiestos.

3. Si todo parece correcto, apruebe y complete la solicitud de incorporación de cambios.

4. Después de unos minutos, Flux recoge el cambio e inicia la implementación.

5. Supervise el estado de confirmación de Git en la pestaña Historial de confirmaciones. Una vez que sea succeeded, el flujo de trabajo CD Stage se iniciará.

6. Reenvíe el puerto de forma local mediante kubectl y asegúrese de que la aplicación funciona correctamente mediante:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Vaya a la aplicación de votaciones de Azure en el explorador en http://localhost:8080/.

8. Vote a sus favoritos y prepárese para realizar algunos cambios en la aplicación.

Flujo de trabajo de la fase de CD

El flujo de trabajo de la fase de CD se inicia automáticamente una vez que Flux implementa correctamente la aplicación en el entorno de desarrollo y notifica la acciones de GitHub a través del conector de GitOps.

Flujo de trabajo de la fase de CD:

• Ejecuta pruebas de humo de la aplicación en el entorno de desarrollo.
• Implementa la aplicación en el entorno de fase.
  • Genera manifiestos en el repositorio de GitOps.
  • Crea un PR en el repositorio de GitOps para su aprobación.

Una vez que se combina la solicitud de incorporación de cambios de manifiesto en el entorno de fase y Flux aplica correctamente todos los cambios, se actualiza el estado de confirmación de Git en el repositorio de GitOps. La implementación ha finalizado.

Para información general detallada de todos los pasos y técnicas implementados en los flujos de trabajo de CI/CD que se usan en este tutorial, consulte el diagrama de flujo de GitOps de GitHub.

Limpieza de recursos

Si no va a seguir usando esta aplicación, elimine los recursos mediante los siguientes pasos:

1. Elimine la conexión de configuración de GitOps de Azure Arc:

   az k8s-configuration flux delete \
         --name cluster-config \
         --cluster-name arc-cicd-cluster \
         --resource-group myResourceGroup \
         -t connectedClusters --yes
   

2. Eliminación del conector de GitOps:

   helm uninstall gitops-connector -n flux-system
   kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
   kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system
   

Pasos siguientes

En este tutorial, ha configurado un flujo de trabajo completo de CI/CD que implementa DevOps desde el desarrollo de la aplicación hasta la implementación. Los cambios en la aplicación desencadenan automáticamente la validación y la implementación, que se vigilan mediante aprobaciones manuales.

Avance a nuestro artículo conceptual para más información sobre GitOps y configuraciones con Kubernetes habilitado para Azure Arc.

Flujo de trabajo de CI/CD conceptual mediante GitOps