Recomendaciones para usar la infraestructura como código

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

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. Prefiere un enfoque declarativo cuando 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 le permite integrar las implementaciones de infraestructura y la administración en sus prácticas de desarrollo de software existentes. Proporciona una metodología estándar coherente 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 no seguro.

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 se debe cambiar 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 en su lugar. 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 las guías de procesos y herramientas de estandarización y cadena de suministro, 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 exige coherencia en los procesos para todas las implementaciones de IaC, minimiza el riesgo de desfase de configuración en todos 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. Entre las recomendaciones de la guía de estilo se incluyen:

Preferir las herramientas declarativas sobre imperativos. 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 el código imperativo, como los scripts de implementación, que se pueden acumular con el tiempo.

Use las herramientas nativas de la plataforma en la nube y otras herramientas probadas en el sector que se integran 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 tengan 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 los actualiza continuamente, lo que les hace más útil 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 correr 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 última versión válida conocida para la carga de trabajo.

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 usa para crear scripts de implementaciones, como Bicep, podría no ser la mejor herramienta para cada operación de administración.

Del mismo modo, la aplicación de 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 configuración (como Azure App Configuration) 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 sus 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.

Los scripts y 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 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 deberían abstraerse.

Nota

Evite el uso de diferentes recursos de IaC para distintos entornos. 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 diferentes entornos según sea necesario.

Estratega 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 crean 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 no distinguen.

Documente los estándares para los pasos manuales. Puede haber pasos relacionados con la implementación y el mantenimiento de la infraestructura que son particulares de su entorno y que requieren intervención manual. Asegúrese de que estos pasos se minimizan tanto como sea posible y se documentan claramente. 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.

Documente los estándares para controlar los recursos huérfanos. En función de las herramientas que use para la administración de configuración y sus limitaciones, es posible que haya 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 carga 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.

Otras estrategias de IaC

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

Use un enfoque por capas para alinear las canalizaciones de IaC dentro de la pila de cargas de trabajo. Separar las canalizaciones de IaC en capas le 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 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 facilita la administración de implementaciones de IaC.

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 de bajo contacto . Es posible que tenga una o varias canalizaciones de IaC media y táctil para los recursos, en función de la complejidad de la carga de trabajo. Con 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.

Trate la iaC y el código de la aplicación igual. Tratar los artefactos de IaC igual que los artefactos de código de la aplicación le ayuda a aplicar el mismo rigor para administrar el 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.

Colabore con otros equipos de su organización para la normalización y la reutilización. A veces, las organizaciones grandes pueden tener varios equipos desarrollando y admitiendo cargas de trabajo. La colaboración entre equipos para acordar 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.

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.

Infraestructura mutable frente a inmutable

La elección entre la implementación de una infraestructura mutable frente a inmutable depende de algunos factores. Si la carga de trabajo es crítica para la empresa, es mejor usar la infraestructura inmutable. Del mismo modo, si tiene un diseño de infraestructura maduro basado en sellos 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 las 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 carga 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: El mantenimiento de la base de código y las herramientas es necesario para mantener la implementación de IaC actualizada y segura. Realice un seguimiento correcto de su deuda técnica y fomente 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 Acciones de GitHub canalizaciones de CI/CD.

Terraform es otra herramienta declarativa de IaC 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 archivos proporcionados Resource Manager, Bicep o Terraform.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa