Realizar implementaciones en infraestructura de Azure con Acciones de GitHub

  • Artículo

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 las arquitecturas de Azure.

Ventajas del uso de IaC y automatización para las implementaciones

Hay muchas maneras de implementar en Azure, como Azure Portal, CLI, API y muchas más. Para esta guía, usaremos IaC y automatización de CI/CD. Las ventajas de este enfoque 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: se puede capacitar a los equipos para implementar sus propias infraestructuras 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 la 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

Architecture overview of using CI/CD to deploy Azure

Flujo de datos

  1. Cree una nueva rama y compruebe las modificaciones de código IaC necesarias.
  2. Cree una solicitud de incorporación de cambios (PR) en GitHub una vez que esté preparado para combinar los cambios en su entorno.
  3. Se desencadenará un flujo de trabajo de Acciones de GitHub para asegurar que el código tiene un formato correcto, es 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 revisada correctamente, la solicitud de incorporación de cambios se puede combinar en la 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) También debe ejecutarse un flujo de trabajo de Acción de GitHub programado periódicamente para buscar cualquier desfase de configuración en el entorno y crear un problema nuevo si se detectan cambios.

Requisitos previos

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 entorno production, configure una regla de protección y agregue los aprobadores necesarios que desee que tengan que aprobar las implementaciones de producción. También puede limitar el entorno a la rama principal. Aquí puede encontrar instrucciones detalladas.

  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). Para obtener instrucciones detalladas, consulte la Documentación de Azure. Es necesario agregar tres credenciales federadas:

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

  3. Agregar secretos de GitHub

    Nota:

    Aunque ninguno de los datos sobre las identidades de Azure contiene secretos o credenciales, todavía usamos los 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: identificador de la aplicación (cliente) del registro de la aplicación en Azure
    • AZURE_TENANT_ID : 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.

    Aquí puede encontrar instrucciones para agregar los secretos al repositorio.

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í la documentación).

  2. Creación del 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 entorno production, configure una regla de protección y agregue los aprobadores necesarios que desee que tengan que aprobar las implementaciones de producción. También puede limitar el entorno a la rama principal. Aquí puede encontrar instrucciones detalladas.

  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 una aplicación independiente para read-only y read/write cuentas y asígneles los permisos adecuados en la 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). Para obtener instrucciones detalladas, consulte la Documentación de Azure.

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

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

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

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

  4. Agregar secretos de GitHub

    Nota:

    Aunque ninguno de los datos sobre las identidades de Azure contiene secretos o credenciales, todavía usamos los 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 read-only:

    • AZURE_CLIENT_ID: identificador de la aplicación (cliente) del registro de la aplicación en Azure
    • AZURE_TENANT_ID : 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.

    Aquí puede encontrar instrucciones para agregar los secretos al repositorio.

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

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

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

Implementación con acciones de GitHub

Uso de Bicep

La arquitectura de referencia incluye dos flujos de trabajo principales:

  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 la compilación de bicep para compilar el bicep en una plantilla de ARM. Esto garantiza que no haya errores de formato. A continuación, realiza una validación para asegurar que la plantilla se puede implementar. Por último, se ejecutará checkov, una herramienta de análisis de código estático de código abierto para IaC, para detectar problemas de seguridad y cumplimiento. Si el repositorio usa GitHub Advanced Security (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 entonces 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 hipótesis cuando se desencadena el flujo de trabajo mediante una inserción en la rama principal. Esta fase implementará la plantilla en Azure después de que se haya aprobado una revisión manual.

Uso de Terraform

La arquitectura de referencia incluye tres flujos de trabajo principales:

  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 asegurar que el linting del código se ha realizado correctamente y que 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, se ejecutará checkov, una herramienta de análisis de código estático de código abierto para IaC, para detectar problemas de seguridad y cumplimiento. Si el repositorio usa GitHub Advanced Security (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 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 de terraform plan. Este informe se adjunta entonces a la solicitud de incorporación de cambios para facilitar la revisión. La fase de aplicación se ejecuta después del plan cuando el flujo de trabajo se desencadena mediante una inserción en la rama principal. Esta fase tomará el documento del plan y aplicará los cambios después de que se haya aprobado una revisión manual si hay cambios pendientes en el entorno.

  3. Terraform Drift Detection

    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.