Compartir a través de

Implementación en la infraestructura de Azure con Acciones de GitHub

En esta guía, trataremos cómo usar CI/CD e infraestructura como código (IaC) para implementar en Azure con Acciones de GitHub de forma automatizada y repetible.

Este artículo es una introducción a la arquitectura y presenta una solución estructurada para diseñar una aplicación en Azure que es escalable, segura, resistente y de alta disponibilidad. Para ver ejemplos más reales de arquitecturas en la nube e ideas de soluciones, examine arquitecturas de Azure.

Ventajas del uso de IaC y automatización para implementaciones

Hay muchas maneras de implementar en Azure, como Azure Portal, la CLI, la API y mucho más. Para esta guía, usaremos IaC y la automatización CI/CD. Entre las ventajas de este enfoque se incluyen:

  • Declarativo: al definir el proceso de implementación e infraestructura en el código, se puede versionar y revisar mediante el ciclo de vida de desarrollo de software estándar. IaC también ayuda a evitar cualquier desfase en la configuración.

  • Coherencia: el seguimiento de un proceso de IaC garantiza que toda la organización siga un método estándar y bien establecido para implementar la infraestructura que incorpore procedimientos recomendados y se proteja para satisfacer sus necesidades de seguridad. Las mejoras realizadas en las plantillas centrales se pueden aplicar fácilmente en toda la organización.

  • Seguridad: las plantillas administradas centralmente se pueden proteger y aprobar mediante un equipo de operaciones o seguridad en la nube para cumplir los estándares internos.

  • Autoservicio: Teams se puede capacitar para implementar su propia infraestructura mediante el uso de plantillas administradas centralmente.

  • Productividad mejorada: mediante el uso de plantillas estándar, los equipos pueden aprovisionar rápidamente nuevos entornos sin necesidad de preocuparse por todos los detalles de implementación.

Puede encontrar información adicional en infraestructura repetible en el Centro de arquitectura de Azure o en qué es la infraestructura como código en el Centro de recursos de DevOps.

Architecture

Introducción a la arquitectura del uso de CI/CD para implementar Azure

Flujo de datos

  1. Cree una nueva rama y compruebe las modificaciones de código iaC necesarias.
  2. Cree un Pull Request (PR) en GitHub una vez que esté listo para fusionar sus cambios en su entorno.
  3. Un flujo de trabajo de Acciones de GitHub se desencadenará para asegurarse de que el código tiene un formato correcto, coherente internamente y genera una infraestructura segura. Además, se ejecutará un análisis de hipótesis de Terraform o Bicep para generar una vista previa de los cambios que se producirán en el entorno de Azure.
  4. Una vez apropiadamente revisado, el PR puede integrarse en tu rama principal.
  5. Otro flujo de trabajo de Acciones de GitHub se desencadenará desde la rama principal y ejecutará los cambios mediante el proveedor de IaC.
  6. (exclusivo de Terraform) Un flujo de trabajo de acción de GitHub programado periódicamente también debe ejecutarse para buscar cualquier desfase de configuración en el entorno y crear un problema nuevo si se detectan cambios.

Prerrequisitos

Uso de Bicep

  1. Creación de entornos de GitHub

    Los flujos de trabajo usan entornos y secretos de GitHub para almacenar la información de identidad de Azure y configurar un proceso de aprobación para las implementaciones. Cree un entorno denominado production siguiendo estas instrucciones. En el production entorno, configure una regla de protección y agregue los aprobadores necesarios que desee para aprobar las implementaciones de producción. También puedes limitar tu entorno a la rama principal. Puede encontrar instrucciones detalladas aquí.

  2. Configuración de La identidad de Azure:

    Se requiere una aplicación de Azure Active Directory que tenga permisos para implementar dentro de la suscripción de Azure. Cree una sola aplicación y asígnele los permisos de lectura y escritura adecuados en la suscripción de Azure. A continuación, configure las credenciales federadas para permitir que GitHub use la identidad mediante OpenID Connect (OIDC). Consulte la documentación de Azure para obtener instrucciones detalladas. Es necesario agregar tres credenciales federadas:

    • Establezca Tipo de entidad en Environment y use el nombre del production entorno.
    • Establezca Tipo de entidad en Pull Request.
    • Establezca el tipo de entidad en Branch y use el nombre de la rama main.

  3. Adición de secretos de GitHub

    Nota:

    Aunque ninguno de los datos sobre las identidades de Azure contiene secretos o credenciales, todavía usamos secretos de GitHub como un medio práctico para parametrizar la información de identidad por entorno.

    Cree los siguientes secretos en el repositorio mediante la identidad de Azure:

    • AZURE_CLIENT_ID : el identificador de aplicación (cliente) del registro de la aplicación en Azure
    • AZURE_TENANT_ID : el identificador de inquilino de Azure Active Directory donde se define el registro de la aplicación.
    • AZURE_SUBSCRIPTION_ID : identificador de suscripción donde se define el registro de la aplicación.

    Puede encontrar instrucciones para agregar los secretos al repositorio aquí.

Uso de Terraform

  1. Configuración de la ubicación de estado de Terraform

    Terraform utiliza un archivo de estado para almacenar información sobre el estado actual de la infraestructura administrada y la configuración asociada. Este archivo deberá conservarse entre distintas ejecuciones del flujo de trabajo. El enfoque recomendado es almacenar este archivo dentro de una cuenta de Azure Storage u otro back-end remoto similar. Normalmente, este almacenamiento se aprovisionaría manualmente o a través de un flujo de trabajo independiente. El bloque back-end de Terraform necesitará actualizarse con la ubicación de almacenamiento seleccionada (consulte aquí para obtener documentación).

  2. Creación de un entorno de GitHub

    Los flujos de trabajo usan entornos y secretos de GitHub para almacenar la información de identidad de Azure y configurar un proceso de aprobación para las implementaciones. Cree un entorno denominado production siguiendo estas instrucciones. En el production entorno, configure una regla de protección y agregue los aprobadores que desee y sean necesarios para aprobar los despliegues en producción. También puedes limitar tu entorno a la rama principal. Puede encontrar instrucciones detalladas aquí.

  3. Configuración de La identidad de Azure:

    Se requiere una aplicación de Azure Active Directory que tenga permisos para implementar dentro de la suscripción de Azure. Cree aplicaciones independientes para las cuentas de read-only y read/write y asígneles los permisos adecuados en su suscripción de Azure. Además, ambos roles también necesitarán al menos Reader and Data Access permisos para la cuenta de almacenamiento donde reside el estado de Terraform del paso 1. A continuación, configure las credenciales federadas para permitir que GitHub use la identidad mediante OpenID Connect (OIDC). Consulte la documentación de Azure para obtener instrucciones detalladas.

    Para la read/write identidad, cree una credencial federada de la siguiente manera:

    • Establezca Entity Type en Environment y use el nombre del entorno production.

    Para la identidad read-only, cree dos credenciales federadas de la siguiente manera:

    • Establece Entity Type en Pull Request.
    • Establezca Entity Type en Branch y use el nombre de la rama main.

  4. Adición de secretos de GitHub

    Nota:

    Aunque ninguno de los datos sobre las identidades de Azure contiene secretos o credenciales, todavía usamos secretos de GitHub como un medio práctico para parametrizar la información de identidad por entorno.

    Cree los siguientes secretos en el repositorio mediante la read-only identidad:

    • AZURE_CLIENT_ID : el identificador de aplicación (cliente) del registro de la aplicación en Azure
    • AZURE_TENANT_ID : el identificador de inquilino de Azure Active Directory donde se define el registro de la aplicación.
    • AZURE_SUBSCRIPTION_ID : identificador de suscripción donde se define el registro de la aplicación.

    Puede encontrar instrucciones para agregar los secretos al repositorio aquí.

    Cree otro secreto en el production entorno mediante la read-write identidad:

    • AZURE_CLIENT_ID : el identificador de aplicación (cliente) del registro de la aplicación en Azure

    Puede encontrar instrucciones para agregar los secretos al entorno aquí. El secreto de entorno invalidará el secreto del repositorio al realizar el paso de implementación en el production entorno cuando se requieran permisos elevados de lectura y escritura.

Implementación con Acciones de GitHub

Uso de Bicep

Hay dos flujos de trabajo principales incluidos en la arquitectura de referencia:

  1. Pruebas unitarias de Bicep

    Este flujo de trabajo se ejecuta en cada confirmación y se compone de un conjunto de pruebas unitarias en el código de infraestructura. Ejecuta bicep build para compilar bicep en una plantilla ARM. Esto garantiza que no haya errores de formato. A continuación, realiza una validación para asegurarse de que la plantilla se puede implementar. Por último, checkov, una herramienta de análisis de código estático de código abierto para IaC, se ejecutará para detectar problemas de seguridad y cumplimiento. Si el repositorio usa Seguridad avanzada de GitHub (GHAS), los resultados se cargarán en GitHub.

  2. Bicep What-If/Deploy

    Este flujo de trabajo se ejecuta en cada solicitud de incorporación de cambios y en cada confirmación en la rama principal. La fase what-if del flujo de trabajo se usa para comprender el impacto de los cambios de IaC en el entorno de Azure mediante la ejecución de what-if. Este informe se adjunta a la solicitud de incorporación de cambios para facilitar la revisión. La fase de implementación se ejecuta después del análisis de escenarios hipotéticos cuando se desencadena el flujo de trabajo por un push a la rama principal. Esta fase implementará la plantilla en Azure después de que se haya cerrado una revisión manual.

Uso de Terraform

Hay tres flujos de trabajo principales incluidos en la arquitectura de referencia:

  1. Pruebas unitarias de Terraform

    Este flujo de trabajo se ejecuta en cada confirmación y se compone de un conjunto de pruebas unitarias en el código de infraestructura. Ejecuta terraform fmt para asegurarse de que el código está correctamente lintado y sigue los procedimientos recomendados de terraform. A continuación, realiza la validación de terraform para comprobar que el código es sintácticamente correcto e internamente coherente. Por último, checkov, una herramienta de análisis de código estático de código abierto para IaC, se ejecutará para detectar problemas de seguridad y cumplimiento. Si el repositorio usa Seguridad avanzada de GitHub (GHAS), los resultados se cargarán en GitHub.

  2. Terraform Plan/Apply

    Este flujo de trabajo se ejecuta en cada solicitud de incorporación de cambios y en cada confirmación en la rama principal. La fase del plan del flujo de trabajo se usa para comprender el impacto de los cambios de IaC en el entorno de Azure mediante la ejecución del plan de Terraform. Este informe se adjunta a la solicitud de incorporación de cambios para facilitar la revisión. La etapa de aplicación se ejecuta después del plan cuando el flujo de trabajo se activa por un push en la rama principal. Esta fase tomará el documento del plan y aplicará los cambios una vez que se haya dado la aprobación de la revisión manual, en caso de que existan cambios pendientes en el entorno.

  3. Detección de desfase de Terraform

    Este flujo de trabajo se ejecuta periódicamente para examinar el entorno en busca de cualquier desfase de configuración o cambios realizados fuera de Terraform. Si se detecta algún desfase, se genera un problema de GitHub para alertar a los mantenedores del proyecto.

  • Last updated on