Compartir a través de

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

  • Artículo

En este tutorial, 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 puede llevar a cabo las siguientes tareas:

  • Conecte los repositorios de la aplicación y de GitOps a Azure DevOps (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.

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:

  • 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

  • O bien, 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:

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

  • Repositorio de GitOps 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 crea sincroniza automáticamente los manifiestos en el directorio del manifiesto y actualiza 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, debe 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 Guardar para crear la conexión.

Configuración de la conexión del servicio PR

La canalización de CD manipula las solicitudes de cambios (PR) en el repositorio de GitOps, lo que requiere 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 Guardar 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 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 Des
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 entornos 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 cambios. Para habilitar estos permisos, siga estos pasos:

  1. En Azure DevOps, abra Configuración del proyecto.
  2. En Repositorios, seleccione Repositorios.
  3. Seleccione Seguridad.
  4. Busque <Project Name> Build Service (<Organization Name>) y Project Collection Build Service (<Organization Name>) (use la búsqueda si no los ve) y permita Contribuir, Contribuir a solicitudes de cambios y Crear rama.
  5. En Canalizaciones, seleccione Configuración.
  6. Desactive la opción Proteger el acceso a repositorios en canalizaciones YAML.

Para obtener más información, consulte Concesión de permisos de control de versiones al servicio de compilación y 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, si ve un error de autorización de recursos al leer el nombre de la conexión de servicio, haga lo siguiente:

  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. Realiza 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 crea una confirmación, la inserta y crea una solicitud 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 git commit en la pestaña Historial de confirmaciones. Una vez que se succeeded, la canalización de CD inicia 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, la habilitación de aprobaciones de entorno ayuda a evitar que el problema se produzca en entornos posteriores.

  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 Definición de aprobación 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 está sincronizado correctamente y pasa 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, realiza 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, sustituya los valores que son razonablemente similares a los que se usarían 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.

La ejecución de canalización finaliza, confirmando la calidad del código de la aplicación y la plantilla que lo implementa. Ahora puede aprobar y completar la solicitud de incorporación de cambios. La canalización de CI se ejecuta 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, asegúrese de establecer directivas de rama para asegurarse de que la solicitud de cambios supera las comprobaciones de calidad. Para obtener más información, consulte Directivas y configuraciones 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 humo básica, vaya a la página de la aplicación y compruebe que la aplicación de votación ahora muestra la 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:

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

El siguiente paso es crear secretos de entorno y repositorio de GitHub.

Creación de secretos del repositorio de GitHub

Use los siguientes valores para los secretos del repositorio de GitHub:

Secreto Valor
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 Valor
ENVIRONMENT_NAME Des
TARGET_NAMESPACE dev
  1. Cree un entorno az-vote-app-stage con los siguientes secretos:
Secreto Valor
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 usan 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.

Una vez completados estos pasos:

  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 git commit en la pestaña Historial de confirmaciones. Una vez que se succeeded, se inicia el flujo de trabajo de CD Stage.

  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, configurará 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.

Concepto: Proceso de CD con implementación de ejemplo de GitOps: exploración del flujo de CI/CD con GitOps