La modularización de la administración de las plantillas de Azure Resource Manager (plantillas de ARM) permite reducir la repetición, modelar los procedimientos recomendados en el desarrollo de la infraestructura y contar con implementaciones estándar coherentes.
Un caso de uso de ejemplo para implementar este tipo de modularización es la implementación de máquinas virtuales (VM) mediante la metáfora de las tallas de camiseta. Supongamos que ha implementado decenas o cientos de máquinas virtuales. Esas implementaciones usan la versión 1.0.0 de las plantillas y tienen un tamaño mediano estándar de una serie anterior. La transición a una nueva serie puede requerir una breve interrupción del servicio si simplemente ha implementado nuevas plantillas. Sin embargo, al compilar la versión 1.5.0 y usar la modularización, puede implementar una nueva infraestructura con el estándar actualizado y mantener la infraestructura antigua en un estado implementable. Al tener disponibles versiones anteriores de la infraestructura, los equipos de productos y aplicaciones contarán con una buena configuración conocida en la que confiar al actualizar a la nueva versión cuando tengan tiempo.
Capas de repositorios: un ejemplo para las empresas
En lo que respecta a los factores que influyen en su preferencia por dónde usar las plantillas, cómo actualizarlas, etc., hay dos consideraciones principales: ramificación e internalización.
Ramificación. Este escenario de ejemplo facilita los modelos de ramificación de Git que admiten Gitflow y el flujo de GitHub. Para más información sobre Gitflow, consulte la entrada de blog de Jeff Kreeftmeijer sobre el uso del flujo de Git para automatizar el flujo de trabajo de ramificación de Git. Para más información sobre el flujo de GitHub, consulte Flujo de GitHub en la documentación de GitHub.
Internalización. La segunda consideración es la internalización, que traslada las prácticas colaborativas del desarrollo de software de código abierto al desarrollo interno. En este escenario, puede compartir con mayor confianza diferentes plantillas y código fuente del módulo sin necesidad de preocuparse por los permisos de los propios modelos de implementación. Para más información sobre el desarrollo de recursos de internalización, consulte Introducción a la internalización en GitHub.
Bicep es un lenguaje declarativo para implementar recursos de Azure. El código reutilizable de Bicep puede usar Azure Container Registry como registro privado para hospedar plantillas de ARM con versiones. Al usar Container Registry de esta manera, la empresa puede disponer de un proceso de integración continua y entrega continua (CI/CD) para la infraestructura. Puede ejecutar pruebas unitarias y de integración como parte del proceso de CI, y el registro de contenedor puede recibir módulos después de que se hayan compilado correctamente. Los equipos de aplicaciones pueden seguir usando versiones anteriores hasta que estén listas para actualizarse o pueden actualizar para aprovechar las características de las versiones más recientes de las plantillas.
Además de este uso de Container Registry, puede combinar este modelo con algo como los Módulos verificados de Azure. La implementación podría consumir desde el registro público, o preferiblemente, supervisar los repositorios públicos y extraer cambios en el registro privado para su uso posterior. La extracción de cambios en su propio registro de contenedor le permite ejecutar pruebas en módulos públicos, a la vez que garantiza que no se usan en producción hasta que se incorporen las prácticas de calidad y seguridad.
Capas
El modelo propuesto en este escenario de ejemplo se apila. Las capas más cercanas a la parte superior de la pila tienen implementaciones más frecuentes y más personalizadas. El código de Bicep proporciona implementaciones coherentes. Los equipos de desarrollo, que trabajan en las capas para sus contribuciones, se crean a partir de los servicios y la infraestructura que se proporcionan en las capas siguientes. Nada de lo que haya en una capa inferior debe basarse en los recursos de una capa anterior. De la capa 0 a la 3 se encuentran la biblioteca global, la infraestructura global (servicios compartidos globalmente), la plataforma de productos (servicios compartidos) y las aplicaciones.
Este modelo crea autonomía con alineación, lo que significa que se dispone de lo siguiente:
Herramientas comunes para facilitar los procesos empresariales. Por ejemplo, todo el mundo usa Git para el control de código fuente y Acciones de GitHub para CI/CD. Sin embargo, no nos extralimitamos. Por ejemplo, no exigimos que todos los equipos usen Bicep; pueden usar Terraform, plantillas de ARM y otras herramientas.
La capacidad de compartir procedimientos recomendados. Podrían adoptar la forma de plantillas de ARM, imágenes maestras o fragmentos de código. Los procedimientos recomendados también pueden ser documentación de técnicas específicas. Por ejemplo, cómo rotar las claves en el entorno y cómo probar el código.
Algunos servicios se mueven hacia abajo en la pila. Por ejemplo, un equipo de aplicaciones puede desarrollar inicialmente una plantilla para implementar un clúster de Kubernetes, que posteriormente se extrae en la plataforma del producto como servicio compartido. Esta plantilla resulta tan útil que se extrae en la biblioteca de ejemplos.
Capa 0: biblioteca global
La capa inferior es la biblioteca global, que es un repositorio de curiosidades útiles que no se implementan en producción. Desde la perspectiva del control de acceso, se debe proporcionar acceso de lectura a cualquier persona de la empresa que lo solicite. Para los cambios, sugerencias, etc., el Centro de excelencia de la nube (CCoE) aprueba las solicitudes de incorporación de cambios y administra un trabajo pendiente como cualquier otro producto.
La capa 0 no debe contener:
- Plantillas que se implementan en producción.
- Secretos o configuraciones específicas del entorno.
La capa 0 debe contener:
- Fragmentos de código (en Python, C#, etc.).
- Ejemplos de Azure Policy.
- Plantillas de ARM, plantillas de Bicep o archivos de Terraform que se pueden usar como ejemplos.
Un ejemplo podría ser una arquitectura para el modo en que la empresa escribiría una implementación para una aplicación de tres niveles sin información específica del entorno. Esta arquitectura de ejemplo podría incluir etiquetas, redes, grupos de seguridad de red, etc. No incluir información específica para el entorno es útil, ya que no todo puede o debe colocarse en un módulo. De lo contrario, podría producirse una parametrización excesiva.
Además, la capa 0 podría vincularse a otros orígenes de código de ejemplo válidos conocidos, como Terraform Registry o Azure Resource Modules. Si su organización adopta código o un patrón de cualquiera de esos orígenes, se recomienda extraer el código o el patrón en su propia capa 0 en lugar de extraerlo directamente desde los orígenes públicos. Al basarse en la capa 0, puede escribir sus propias pruebas, ajustes y configuraciones de seguridad. Al no usar los orígenes públicos, se reduce el riesgo de depender de algo que se podría eliminar inesperadamente.
Para considerarse un buen código de ejemplo, las plantillas y los módulos deben seguir los procedimientos de desarrollo recomendados, incluida la validación de entradas para la seguridad y los requisitos de la organización. Para mantener este nivel de rigor, debe agregar directivas a la rama principal para requerir solicitudes de incorporación de cambios (PR) y revisiones de código para los cambios propuestos que darían lugar a cambios que fluyen al registro de contenedor principal si se combinan.
La capa 0 se envía a Azure Pipelines o Acciones de GitHub para crear automáticamente artefactos con versiones en Azure Container Registry. Puede compilar la automatización de los mensajes de confirmación de Git para implementar el control de versiones semántico de los artefactos. Para que esto funcione correctamente, debe tener un estándar de nomenclatura determinista, como <service>.bicep, para que la automatización se pueda mantener con el tiempo. Con las directivas de rama adecuadas, también puede agregar pruebas de integración como requisito previo para las revisiones de código. Puede instrumentar esto mediante herramientas como Pester.
Con estas directivas y protecciones implementadas, el registro de contenedor puede ser una fuente fiable para todos los módulos de infraestructura de la empresa que están listos para usarse. Debe considerar la posibilidad de estandarizar los registros de cambios, así como los índices de ejemplos de código disponibles, para permitir la detectabilidad de este código. El código que se desconoce no se usa.
Capa 1: infraestructura global: servicios compartidos globalmente
La capa 1 es el repositorio de sus construcciones de la zona de aterrizaje de Azure. Aunque Microsoft proporciona plantillas para la implementación de zonas de aterrizaje de Azure, es posible que desee modificar determinados componentes y proporcionar un archivo de parámetros. Esto es análogo a la forma en que extrae repositorios de módulos y del registro público en la capa 0, como se ha descrito anteriormente.
Azure Container Registry es una parte fundamental de esta arquitectura. Incluso si su empresa no tiene ningún plan para usar contenedores, debe implementar Container Registry para garantizar un adecuado control de versiones de las plantillas de Bicep. Container Registry permite una gran flexibilidad y reutilización de los módulos, a la vez que proporciona seguridad y control de acceso de nivel empresarial.
La capa 1 debe contener:
- Asignaciones y definiciones de directiva que se aplican en el nivel de grupo de administración o suscripción. Estas directivas deben coincidir con los requisitos de gobernanza corporativa.
- Plantillas para la infraestructura de red principal, como ExpressRoute, VPN, WAN virtual y redes virtuales (compartidos o de centro).
- DNS.
- Supervisión de infraestructura principal (análisis de registros).
- Registro de contenedor empresarial.
Debe configurar la protección de rama para restringir la capacidad de insertar cambios en este repositorio. Restrinja la aprobación de solicitudes de incorporación de cambios de otros desarrolladores a los miembros del CCoE o la gobernanza de la nube. Los colaboradores de esta capa son principalmente miembros de grupos que históricamente están asociados a los componentes de esta capa. Por ejemplo, el equipo de redes crea las plantillas para la red, el equipo de operaciones configura la supervisión, etc. Sin embargo, debe conceder acceso de solo lectura a las personas que lo soliciten, ya que desea permitir que los desarrolladores de otros grupos sugieran cambios en las infraestructuras principales. Estas personas pueden aportar mejoras, aunque no permitirá que sus cambios se combinen sin aprobación ni pruebas.
Estos archivos deben consumir los módulos del registro de contenedor para los componentes estándar. Sin embargo, también tendrá un archivo de Bicep, o una serie de archivos de Bicep, que se personalizan para la implementación de la empresa de las zonas de aterrizaje de Azure o una estructura de gobernanza similar.
Capa 2: Plataforma de productos: servicios compartidos
Puede considerar la capa 2 (la plataforma de productos) como los servicios compartidos de una línea de producto o unidad de negocio determinada. Estos componentes no son universales en toda la organización, pero están diseñados para ajustarse a una necesidad empresarial determinada. Esta sería una capa adecuada para una red virtual del mismo nivel que el centro en la infraestructura global de la capa 1. Un almacén de claves es otro componente de ejemplo para esta capa. El almacén de claves podría almacenar secretos compartidos en una cuenta de almacenamiento o en una base de datos compartida por las distintas aplicaciones de esta plataforma.
La capa 2 debe contener:
- Asignaciones de directiva que se aplican en una suscripción o grupo de recursos para que coincidan con los requisitos específicos del producto.
- Plantillas de ARM para almacenes de claves, análisis de registros, una base de datos de SQL (si varias aplicaciones del producto usan la base de datos) y Azure Kubernetes Service.
Debe implementar permisos que restrinjan la capacidad de insertar cambios en este repositorio. Al igual que las otras capas, debe usar la protección de ramas para asegurarse de que un responsable de producto o propietario pueda aprobar solicitudes de incorporación de cambios de otros desarrolladores. No hay reglas fijas sobre el acceso de lectura a la plataforma de productos, pero como mínimo, a los desarrolladores de cualquiera de los equipos de aplicaciones se les debe conceder acceso de lectura para poder sugerir cambios. Dado que la capa 2 podría contener cierta arquitectura propietaria o información similar, puede optar por restringir el acceso a los usuarios de la organización que usan la plataforma. Sin embargo, si es así, querrá asegurarse de crear un proceso de recopilación de procedimientos recomendados y fragmentos de código de este repositorio para compartirlos con la biblioteca global de la capa 0.
Capa 3: Aplicación
La capa 3, el nivel de aplicación, incluye los componentes que se basan en la plataforma de productos. Estos componentes proporcionan las características que solicita la empresa. Por ejemplo, para una plataforma de streaming, una aplicación podría proporcionar la función de búsqueda mientras que otra aplicación proporciona recomendaciones.
La capa 3 debe contener:
- Código de aplicación en C#, Python, etc.
- Infraestructura para componentes individuales (es decir, solo se usan en esta aplicación): funciones, Azure Container Instances, Event Hubs.
Los permisos están restringidos para poder insertar cambios en este repositorio. Debe usar la protección de rama para permitir que un miembro del equipo de esta aplicación apruebe una solicitud de incorporación de cambios realizada por otro miembro del equipo. No se debe permitir que los miembros del equipo aprueben sus propios cambios. Dado que esta capa podría contener arquitectura propietaria, lógica de negocios o información similar, puede optar por restringir el acceso a los usuarios de la organización que compilan esta aplicación. Sin embargo, si es así, también debe crear un proceso de recopilación de procedimientos recomendados y fragmentos de código de esta capa para compartirlos con la biblioteca global de la capa 0.
Elementos comunes entre capas
Aunque en este artículo se describen algunos detalles específicos de cada capa, también hay algunas cualidades para todas las capas que debe tener en cuenta.
La infraestructura debe funcionar como si fuera una aplicación. Esto significa que debe tener un proceso de integración continua (CI) en el que se prueban completamente las nuevas características, con pruebas unitarias, pruebas de aceptación de la compilación y pruebas de integración. Solo debe combinar código que supere estas pruebas a la rama de versión principal.
También debe asegurarse de que tiene directivas de rama implementadas para evitar que los usuarios sorteen el proceso, incluso para mayor comodidad. Si su proceso de CI se considera un impedimento, significa que ha incurrido en deuda técnica que debe resolver. Esto no significa que tenga que quitar las directivas y protecciones.
Por último, aunque es posible que no tenga un índice de todos los repositorios y el código existente dentro de ellos, su organización debe desarrollar un proceso para que los usuarios soliciten acceso a los repositorios. Algunas reglas podrían automatizarse completamente. Por ejemplo, podría implementar una regla que conceda acceso de lectura, sin revisión, a un colaborador que esté en el equipo del producto para cualquier aplicación de ese producto. Estas reglas se pueden implementar a menudo con la pertenencia basada en grupos y las asignaciones de roles basadas en grupos en los entornos. La configuración de este tipo de acceso debe ayudar a facilitar la internalización y los conocimientos de la organización.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Tim Sullivan | Especialista técnico sénior
Otros colaboradores:
- Gary Moore | Programador/escritor
Pasos siguientes
- Área de diseño: automatización de la plataforma y DevOps
- Estructuras de equipo maduras
- ¿Qué es la infraestructura como código?
- Azure/ResourceModules: este repositorio incluye una plataforma de CI para la recopilación de módulos de Bicep maduros y mantenidos. La plataforma admite tanto Azure Resource Manager como Bicep, y puede usar sus características con Acciones de GitHub y Azure Pipelines.
- Creación de un registro privado para el módulo de Bicep