Compartir vía

Recomendaciones para usar la infraestructura como código

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa del marco de trabajo bien diseñado de Azure:

OE:05 Prepare los recursos y sus configuraciones mediante un enfoque estandarizado de infraestructura como código (IaC). Al igual que otro código, diseñe IaC con estilos coherentes, modularización adecuada y control de calidad. Se prefiere un enfoque declarativo siempre que sea posible.

En esta guía se describen las recomendaciones para usar IaC como estándar para las implementaciones de infraestructura. El uso de IaC permite integrar las implementaciones y la administración de la infraestructura en las prácticas de desarrollo de software existentes. Proporciona una metodología coherente y estándar para el desarrollo y la implementación de todos los componentes de la carga de trabajo. Confiar en implementaciones manuales pone la carga de trabajo en riesgo de configuraciones incoherentes y un diseño potencialmente inseguro.

Definiciones

Término Definición
Herramientas declarativas Categoría de herramientas que definen el estado final de una implementación y dependen del sistema para determinar cómo implementar los recursos para que coincidan con el estado final definido.
Infraestructura inmutable Una infraestructura que está pensada para reemplazarse por una nueva infraestructura que ejecuta la nueva configuración con cada implementación. No debe cambiarse en su lugar.
Herramientas imperativas Categoría de herramientas que enumeran los pasos de ejecución que dan como resultado el estado final deseado.
Módulo Unidad de abstracción para dividir grupos de recursos para simplificar las implementaciones complejas.
Infraestructura mutable Una infraestructura que está pensada para cambiarse. Las implementaciones cambian la configuración de la infraestructura en lugar de reemplazarla por la nueva infraestructura.

Estrategias de diseño principales

Como se describe en la cadena de suministro y las guías de estandarización de herramientas y procesos , debe tener una directiva estricta de implementación de cambios de infraestructura (incluidos los cambios de configuración) solo a través del código. Debe implementar IaC a través de las canalizaciones de integración continua y entrega continua (CI/CD). La adopción de estas directivas aplica coherencia en los procesos para todas las implementaciones de IaC, minimiza el riesgo de desfase de configuración en los entornos y garantiza la coherencia de la infraestructura en todos los entornos. Además, debe estandarizar las herramientas y procesos de desarrollo e implementación de IaC en una guía de estilo. Las recomendaciones para la guía de estilo incluyen:

Preferir herramientas declarativas sobre imperativas

Las herramientas declarativas y sus archivos asociados son una mejor opción general para implementar y administrar IaC que las herramientas imperativas. Las herramientas declarativas usan una sintaxis más sencilla para sus archivos de definición, definiendo solo el estado deseado del entorno una vez finalizada la implementación. Las herramientas imperativas dependen de definir los pasos necesarios para llegar al estado final deseado, por lo que los archivos pueden ser mucho más complejos que los archivos declarativos. Los archivos de definición declarativos también ayudan a reducir la deuda técnica de mantener código imperativo, como los scripts de implementación, que pueden acumularse con el tiempo.

Uso de herramientas nativas y estándar del sector

Use las herramientas nativas de la plataforma en la nube y otras herramientas probadas en el sector que se integren de forma nativa en la plataforma. La plataforma en la nube proporciona herramientas para facilitar y simplificar la implementación de IaC. Aproveche estas herramientas y otras herramientas de terceros que tienen integración nativa, como Terraform, en lugar de desarrollar sus propias soluciones. Las herramientas nativas son compatibles con la plataforma e incluyen funcionalidad integrada para la mayoría de sus necesidades. El proveedor de plataforma actualiza continuamente, lo que hace que sean más útiles a medida que evoluciona la plataforma.

Nota:

Tenga en cuenta que, a medida que los proveedores de nube y los desarrolladores de terceros actualizan sus herramientas y API, puede ejecutar el riesgo de problemas imprevistos al usar la versión más reciente de la carga de trabajo. Asegúrese de probar exhaustivamente las nuevas versiones de las herramientas y las API antes de adoptarlas. Del mismo modo, evite usar la marca "latest" al llamar a en una herramienta o API en el código de implementación. Tenga intención de llamar a la versión correcta más reciente conocida para la carga de trabajo.

Usar la herramienta adecuada para la tarea

Use las herramientas adecuadas para tareas específicas y tipos de infraestructura. Varias tareas, más allá de las implementaciones, están implicadas en un ciclo de vida de la infraestructura. Es necesario aplicar y mantener la configuración, por ejemplo, y la herramienta que se usa para crear scripts, como Bicep, podría no ser la mejor herramienta para cada operación de administración.

Del mismo modo, aplicar la configuración de estado deseado (DSC) para diferentes tipos de infraestructura puede requerir herramientas diferentes. Por ejemplo, hay herramientas específicas como Ansible para administrar DSC para vm, mientras que Flux es una buena herramienta para administrar DSC en clústeres de Kubernetes. Los servicios de plataforma como servicio (PaaS) pueden proporcionar diferentes herramientas para la administración de configuraciones (como App de Azure Configuración) que se pueden controlar a través de IaC. Los servicios de software como servicio (SaaS) pueden ser más limitados porque están más controlados por la plataforma.

Piense en todas las tareas y tipos de infraestructura que están en el ámbito de las prácticas de IaC y normalice las herramientas que realizan los trabajos que necesita que realicen y se puedan integrar en sus prácticas de desarrollo y administración.

Compatibilidad con varios entornos

Los scripts y las plantillas deben ser lo suficientemente flexibles como para implementar fácilmente una variedad de entornos. Use parámetros, variables y archivos de configuración para implementar un conjunto estándar de recursos que se pueden modificar para implementar cualquier entorno en la pila de promoción de código. Configuración abstracta, como el tamaño del recurso, el recuento, el nombre, las ubicaciones en las que se van a implementar y algunas opciones de configuración. Tenga cuidado de no abstraer demasiado, sin embargo. Hay configuraciones que se pueden abstraer con un parámetro o variable que podría no cambiar realmente durante el ciclo de vida de la carga de trabajo o que podrían cambiar rara vez. No deben abstraerse.

Nota:

Evite usar diferentes recursos de IaC para entornos diferentes. Por ejemplo, no debe tener archivos de Terraform diferentes para entornos de producción y prueba. Todos los entornos deben usar un archivo. Puede manipular ese archivo para implementarlo en entornos diferentes según sea necesario.

Usar el equilibrio adecuado al encapsular la funcionalidad

Estratifique y normalice el uso de módulos. Al igual que los parámetros y las variables, los módulos pueden hacer que las implementaciones de infraestructura se puedan repetir. Tenga cuidado, sin embargo, sobre cómo los usa. Una estrategia de abstracción estandarizada ayuda a garantizar que los módulos se compilan para cumplir objetivos específicos y acordados. Use módulos para encapsular configuraciones complejas o combinaciones de recursos. Evite los módulos si usa solo la configuración predeterminada del recurso. Además, sea prudente en el desarrollo de nuevos módulos. Use módulos de código abierto mantenidos cuando corresponda, por ejemplo, escenarios que no distinguen.

Pasos manuales del documento

Documente los estándares para los pasos manuales. Puede haber pasos relacionados con la implementación y el mantenimiento de la infraestructura que son específicas de su entorno y que requieren intervención manual. Asegúrese de que estos pasos se minimicen tanto como sea posible y estén claramente documentados. En la guía de estilo y los procedimientos operativos estándar, normalice los pasos manuales para asegurarse de que las tareas se realizan de forma segura y coherente.

Estándares de documento para controlar recursos huérfanos. En función de las herramientas que use para la administración de configuración y sus limitaciones, puede haber ocasiones en las que la carga de trabajo ya no necesite un recurso determinado y las herramientas de IaC no puedan quitar automáticamente el recurso. Por ejemplo, supongamos que va a pasar de máquinas virtuales a un servicio PaaS para alguna función y las herramientas de IaC no tienen lógica para quitar los recursos retirados. Esos recursos pueden quedar huérfanos si el equipo de cargas de trabajo no recuerda eliminarlos manualmente. Para controlar estos escenarios, normalice una estrategia para buscar recursos huérfanos y eliminarlos. También debe tener en cuenta cómo asegurarse de que las plantillas están actualizadas. Investigue las limitaciones de las herramientas de IaC para comprender lo que podría necesitar planear en estas situaciones.

Tenga en cuenta las siguientes recomendaciones que se aplican al uso de IaC para la carga de trabajo.

Uso de un enfoque en capas para canalizaciones de IaC

Use un enfoque en capas para alinear las canalizaciones de IaC dentro de la pila de cargas de trabajo. Separar las canalizaciones de IaC en capas ayuda a administrar entornos complejos. La implementación de docenas o cientos de recursos como un paquete monolítico es ineficaz y puede presentar varios problemas, como las dependencias rotas. El uso de varias canalizaciones que están alineadas con capas compuestas de recursos cuyos ciclos de vida de implementación o factores como la funcionalidad coinciden estrechamente hace que la administración de implementaciones de IaC sea más fácil.

La infraestructura principal, como los recursos de red, rara vez necesita cambios más complejos que las actualizaciones de configuración, por lo que esos recursos deben componer una canalización de IaC táctil baja. Es posible que tenga una o más canalizaciones de IaC táctiles y de alta interacción para los recursos, en función de la complejidad de la carga de trabajo. El uso de una pila de aplicaciones basada en Kubernetes como ejemplo, una capa táctil media podría estar compuesta de clústeres, recursos de almacenamiento y servicios de base de datos. Las capas táctiles altas se componerían de los contenedores de aplicaciones que se actualizan con mucha frecuencia en un modo de entrega continua.

Tratar iaC y el código de aplicación igual

El tratamiento de los artefactos de IaC de la misma manera que los artefactos de código de la aplicación ayuda a aplicar el mismo rigor para administrar código en todas las canalizaciones. Además, los procedimientos de desarrollo e implementación de IaC deben reflejar las prácticas de aplicación. Los estándares de control de versiones, bifurcación, promoción de código y calidad deben ser idénticos. Considere también la posibilidad de colocar los recursos de IaC junto con los recursos de código de la aplicación. Esto ayuda a garantizar que se siguen los mismos procesos con cada implementación y le ayuda a evitar problemas como la implementación involuntaria de la infraestructura antes del código de aplicación necesario, o viceversa.

Uso de estándares y recursos centralizados

Colabore con otros equipos de su organización para la estandarización y reutilización. A veces, las organizaciones grandes pueden tener varios equipos que desarrollan y admiten cargas de trabajo. La colaboración entre equipos para aceptar estándares le ayuda a reutilizar bibliotecas, plantillas y módulos para obtener eficacia y coherencia en los entornos de carga de trabajo. Del mismo modo, las herramientas de IaC deben estandarizarse en toda la organización en la medida en que hacerlo sea práctico.

Aplicación de la seguridad en el código iaC

Aplique el principio de "seguridad como código" para asegurarse de que la seguridad forma parte de la canalización de implementación. Incluya el examen de vulnerabilidades y la protección de la configuración como parte del proceso de desarrollo de IaC. Examine los repositorios de IaC para conocer las claves y los secretos que se exponen. Una ventaja de usar IaC es que los miembros del equipo centrados en la seguridad pueden revisar el código antes de la implementación para asegurarse de que la configuración aprobada para su lanzamiento por seguridad es realmente lo que se implementa en producción. Para obtener instrucciones detalladas, consulte Recomendaciones para proteger un ciclo de vida de desarrollo.

Probar actividades rutinarias y no rutinarias. Pruebe las implementaciones, las actualizaciones de configuración y los procesos de recuperación, incluidos los procesos de reversión de la implementación.

Adopción de un modelo de implementación inmutable

La elección entre implementar una infraestructura mutable frente a inmutable depende de algunos factores. Si la carga de trabajo es fundamental para la empresa, es mejor usar la infraestructura inmutable. Del mismo modo, si tiene un diseño de infraestructura maduro basado en stamps de implementación, el uso de una infraestructura inmutable puede tener sentido, ya que puede implementar código de aplicación y nueva infraestructura de forma confiable. Por el contrario, el uso de la infraestructura mutable puede ser una mejor opción si los procedimientos de implementación seguros dictan que la puesta al día con implementaciones cuando surgen problemas de implementación mitigables es la opción preferida. En este caso, probablemente actualizaría la infraestructura en su lugar.

Consideraciones

Mayor especialización: en algunos casos, la introducción de nuevos idiomas en el equipo de cargas de trabajo incluye una curva de aprendizaje y el bloqueo del proveedor puede hacer que sea una opción deficiente. Es necesario entrenar a los miembros del equipo y analizar la herramienta adecuada en función de la compatibilidad con herramientas de los proveedores de nube.

Mayor esfuerzo de mantenimiento: se requiere el mantenimiento de la base de código y las herramientas para mantener la implementación de IaC actualizada y segura. Realiza un seguimiento adecuado de tu deuda técnica y fomenta una cultura en la que se recompensa la reducción de la deuda.

Mayor tiempo para los cambios de configuración: la implementación de la infraestructura mediante instrucciones de línea de comandos o directamente desde un portal no requiere tiempo de codificación ni artefactos de prueba. Minimice el tiempo de implementación siguiendo los procedimientos recomendados, como las revisiones de código y las prácticas de control de calidad.

Mayor complejidad de la modularización: el uso de más módulos y parametrización aumenta el tiempo necesario para depurar y documentar el sistema y agrega una capa de abstracción. Equilibre el uso de la modularización para reducir la complejidad y evitar el exceso de ingeniería.

Facilitación de Azure

Las plantillas de Azure Resource Manager (plantillas de ARM) y Bicep son herramientas nativas de Azure para implementar la infraestructura mediante la sintaxis declarativa. Las plantillas de ARM se escriben en JSON, mientras que Bicep es un lenguaje específico del dominio. Ambos se pueden integrar fácilmente en canalizaciones de Azure o canalizaciones de CI/CD de Acciones de GitHub.

Terraform es otra herramienta de IaC declarativa que es totalmente compatible con Azure. Se puede usar para implementar y administrar la infraestructura, y se puede integrar en la canalización de CI/CD.

Puede usar Microsoft Defender for Cloud para detectar configuraciones incorrectas en IaC.

Ejemplo

Consulte la arquitectura del acelerador de zonas de aterrizaje de Azure Virtual Desktop y la implementación de referencia asociada para ver un ejemplo de una implementación de Virtual Desktop que se puede implementar a través de los archivos de Resource Manager, Bicep o Terraform proporcionados.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa