Codificación de todo en IaC

Todas las especificaciones de infraestructura deben codificarse explícitamente en un archivo de configuración, por ejemplo, como configuraciones de Terraform o playbooks de Ansible. Los archivos de configuración son la única fuente de verdad de su especificación de infraestructura y describen qué componentes de infraestructura se utilizan en su configuración.

Minimizar documentación

IaC es la documentación. Con IaC en su lugar, los archivos de configuración representan la documentación y siempre están actualizados, lo que reduce el esfuerzo. La documentación restante es sobre el proceso. Mantener código en un sistema de control de versiones.

Los archivos de configuración de IaC deben conservarse en sistemas de control de versiones (VCS), como GitHub o GitLab. Esto proporciona un seguimiento de auditoría para los cambios de código, pero también ofrece la oportunidad de colaborar o revisar por igual y probar los cambios antes de que entren en funcionamiento.

Con esta práctica, puede realizar fácilmente un seguimiento, gestionar y revertir cualquier cambio potencial en los sistemas, con una rastreabilidad y visibilidad mejoradas.

Pruebas

Una de las prácticas que IaC toma prestada del desarrollo de software es la prueba. Las pruebas rigurosas de la configuración de la infraestructura desempeñan un papel en la reducción de los problemas posteriores al despliegue. Cuando se combina con sistemas de control de versiones, las pruebas se pueden activar automáticamente cada vez que haya una modificación en el código.

Con Continuous Integration (CI) en su lugar, la configuración de la infraestructura de plantilla se puede implementar en varios entornos como, por ejemplo, el entorno development, UAT, QA o production con los cambios mínimos aplicados de forma efectiva.

Infraestructura modular

El desglose de la infraestructura en módulos permite reutilizarla, mejorar la fiabilidad y facilitar la adopción. Similar al uso de módulos y paquetes en lenguajes de programación. A continuación, las ventajas de esta práctica.

• Las configuraciones utilizadas con frecuencia pueden codificarse como módulos y reutilizarse varias veces entre entornos.
• La fiabilidad aumenta a medida que los módulos se pueden probar y se endurecen con el tiempo con el uso.
• La composición de los módulos reutilizables reduce la barrera de habilidades para la adopción de IaC.
• Los cambios son más fáciles de realizar y probar a nivel de módulo.
• El riesgo de cambio se reduce a medida que se localizan los cambios de configuración.

Enfoques declarativos frente a imperativos para IaC

Al adoptar IaC, un aspecto a considerar es qué enfoque adopta su utillaje. Hay dos estilos diferentes, declarativos o imperativos, también a veces descritos como procedimentales.

Un enfoque declarativo define el estado deseado del sistema, incluidos los recursos que necesita y las propiedades que deben tener, y la herramienta se configura automáticamente. La propia herramienta determina las operaciones para llegar al estado deseado desde cualquier punto de partida.

En su lugar, un enfoque imperativo define los mandatos específicos necesarios para lograr la configuración deseada y, a continuación, dichos mandatos deben ejecutarse en el orden correcto.

El chef es considerado como una herramienta imperativa. Terraform se clasifica como declarativo. Ansible es declarativo, pero también se puede utilizar con mandatos imperativos.

Terraform declarativo y gestión del ciclo de vida

Schematics admite tanto Terraform como Ansible como herramientas de IaC con espacios de trabajo y acciones de Schematics. Cuando la gestión del ciclo de vida es importante, se recomienda utilizar Terraform con Schematics espacios de trabajo. Terraform mantiene un registro del estado actual de la infraestructura de nube desplegada y Schematics puede eliminar la infraestructura en orden inverso de dependencia sin intervención manual.

Idempotence

Una ventaja del enfoque declarativo utilizado por Terraform y Ansible es idempotence. Las tareas idempotentes se pueden ejecutar varias veces con el mismo resultado final. Independientemente del estado anterior o del lugar de inicio al reiniciar después de las anomalías, la infraestructura suministrada y la configuración son siempre las mismas. Este aspecto es clave para garantizar la coherencia y la repetibilidad de los entornos desplegados utilizando Schematics.

La forma en que se utiliza una herramienta y los módulos utilizados tienen un impacto en idempotency. Generalmente, los módulos de Terraform y Ansible se escriben como idempotente. Con ambas herramientas, podemos escribir código que no arroje un resultado idempotente. En este caso, la configuración puede desviarse del estado de destino deseado. Con Terraform, esta forma de desviación es más probable cuando se utilizan null-resources para ampliar la funcionalidad del proveedor con scripts personalizados que no son idempotente.

La inmutabilidad es una práctica de IaC que minimiza el riesgo de desviación del estado de destino.

Inmutable

La infraestructura inmutable hace referencia a la gestión de servicios y despliegues de software en los que se sustituyen recursos como contenedores o máquinas virtuales en lugar de cambiarlos (utilizando scripts). El principal deseo aquí de inmutabilidad es evitar la deriva de configuración. Incoherencias que surgen debido a cambios locales o manuales, o diferencias en la secuencia de operaciones automatizadas. Cambios que dificultan la depuración y resolución de problemas y aumentan los costes de soporte.

Para garantizar la inmutabilidad y eliminar la desviación, todos los cambios se deben realizar a través de la configuración de Schematics IaC y los recursos como las VSI se deben volver a desplegar cuando sea necesario actualizarlos.