Infraestructura como código y TDD

La infraestructura como código nos dice que usemos herramientas que automaticen sus compilaciones. Excelente. Herramientas como ansible , chef , marioneta , pila de sal y otras nos empujan a escribir cómo se ve la infraestructura, al tiempo que resuelven las diferencias.

En Salt Stack, esos bits se llaman estados . Si el estado no coincide con la realidad, la herramienta lo resolverá por nosotros. En otras palabras, estamos escribiendo una prueba para nuestra infraestructura y si la prueba falla, la herramienta la solucionará por sí sola. Al menos esa es la idea.

XP nos enseña a usar TDD y la pregunta es si es aplicable a la infraestructura. Las herramientas sugieren que sí.

Me imagino algunos tipos de pruebas que pueden ser muy útiles.

Escribimos pruebas de humo que se incluyen con el servicio implementado para garantizar que el servicio implementado de extremo a extremo funcione y se ejecute como se esperaba. Esta sería una llamada a la API o una comprobación de systemctl para asegurarse de que lo que acabamos de implementar funcione. Gran parte de esta funcionalidad se puede cubrir en los mismos estados, ya que las herramientas como ansible tienen estados para asegurarse de que un servicio se esté ejecutando.

Existe el proyecto Molecule que permite ejecutar roles individuales (como ansible llama a sus estados) contra docker u otro motor de virtualización temporal. Esto obliga a desacoplar los roles y permite ejecutarlos de forma aislada del libro de jugadas mientras se trabaja en ellos. Las pruebas en su mayoría permiten burlarse de las variables con las que se supone que el rol debe trabajar. Sin embargo, otros ejemplos parecen una duplicación del motor ansible (afirmar que un archivo pertenece a un usuario ...).

ThoughtWorks radar de tecnología ahora elogia herramientas como INSPEC , serverspec o Goss para validar que el servidor cumple la especificación. Pero estamos escribiendo una especificación, ¿no?

Entonces, ¿hay algún punto en probar más la infraestructura si estamos describiendo la infraestructura en estados / roles? Podría sospechar que esto se vuelve más necesario en organizaciones más grandes donde un equipo proporciona la especificación y otro sigue, o si hay un gran conjunto de roles, ¿tal vez desee ejecutar un subconjunto de esos y obtener un beneficio de velocidad de las pruebas? Me cuesta ver por qué escribirías una prueba si pudieras tener un rol / estado para la misma pregunta en mente.

En resumen, veo dos categorías de pruebas para su infraestructura: 1) tiene todo lo que necesita para ejecutar su aplicación y 2) no tiene cosas superfluas.

En primer lugar, puede tratar el conjunto de pruebas de su software real como una especie de "meta prueba" para su infraestructura. Siempre que cree la infraestructura desde cero para cada ejecución de prueba, y el conjunto de pruebas se ejecute completamente en esa infraestructura (es decir, no use servicios externos), el hecho de que todo el conjunto sea verde significa que su infraestructura codificada también es suficiente .

En segundo lugar, especialmente desde la perspectiva de la seguridad, puede escribir pruebas en su infraestructura. Es decir, si una parte de su infraestructura es una VM que ejecuta Linux, puede escribir una prueba que haga un escaneo de puertos contra esa VM, para asegurarse de que no haya puertos involuntarios abiertos, que pueden haber sido instalados por un apt-get installefecto secundario no deseado . O bien, podría escribir pruebas que verifiquen si se modificaron archivos inesperados después de que se haya completado su conjunto de pruebas adecuado. O bien, puede verificar los psresultados de sus máquinas virtuales o contenedores Docker en busca de procesos inesperados y demás, crear listas blancas, etc., y así recibir una notificación automática si algún paquete de terceros cambia de forma no documentada (o desapercibida) en alguna actualización.

Este segundo tipo de pruebas son, de alguna manera, similares a lo que haría en una configuración de operaciones clásica de todos modos, es decir, endurecer sus servidores y verificar intrusiones, evitando el recurso completo y demás.

En mi humilde opinión, es bastante redundante escribir pruebas TDD para elementos cubiertos por la especificación de estado IaaC. Hacerlo implica que la efectividad de IaaC es cuestionable: ¿por qué lo usarías si es así?

Mirándolo desde un IaaC prospectivo diferente (si / cuando se hace correctamente) incorpora capacidades ya probadas y consideradas que funcionan de manera confiable. Es lo que lo hace atractivo y lo que hace que la escritura de pruebas de coincidencia TDD sea redundante.

Por ejemplo, una configuración de IaaC que especifica un sistema con SSH instalado ya incorpora una verificación confiable para que SSH esté instalado correctamente y, si no, mecanismos para instalarlo correctamente. Lo que hace una prueba TDD para verificar si SSH está instalado de forma redundante. Si su configuración de IaaC también especifica que sshd se iniciará y escuchará en un puerto específico, entonces las pruebas de TDD para ejecutar sshd y escuchar el puerto respectivo también serían redundantes.

Tenga en cuenta que mi respuesta no está dirigida a TDD ni a ningún otro tipo de prueba que verifique si la configuración de IaaC en su conjunto cumple un determinado propósito. Eso sigue siendo válido y se puede usar en TDD, CI o verificaciones similares durante el desarrollo de esa especificación IaaC; creo que la respuesta de @ AnoE es aplicable en tal caso.

Parece que todos aquí asumen que una herramienta IAC siempre se ejecuta como se esperaba, pero puedo decir (por mi propia experiencia) que este no es siempre el caso, de lo contrario la prueba unitaria sería realmente inútil.

Recuerdo una foto que decía "El libro de jugadas de Ansible funcionó, todo está bien" con un edificio ardiendo en el fondo ...

Ejecutar un estado declarativo y tener el servidor en este estado declarado real son 2 cosas diferentes desde mi punto de vista y experiencia al menos.

Un entorno amplio y heterogéneo, extendido a través de múltiples DC, accesible a través de una red pública, etc. Hay varias razones por las cuales un estado no puede aplicarse, ni total ni parcialmente.

Por todas estas razones, hay espacio para pruebas unitarias que permiten obtener una instantánea del estado real del servidor, que, de nuevo, puede diferir del estado deseado.

Entonces diría que sí, las pruebas unitarias son útiles incluso en un entorno administrado por IAC.

EDITAR

¿Qué pasa con el lado de no regresión de la rama de desarrollo de la base de código IaC? Entonces, ¿haría cambios en su código en la rama de desarrollo y lo fusionaría con la rama de producción con la esperanza de no romperlo todo? Las pruebas unitarias son tan valiosas y, por lo general, fáciles de implementar. No veo por qué uno codificaría sin esta función.

Referencia (en francés lo siento): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

En mi experiencia, una de las principales diferencias entre Dev y Ops son las "grandes dependencias de tiempo de ejecución". La instalación de paquetes depende en gran medida de repositorios, redes o claves válidas, o digamos instanciar un nuevo servidor en la nube: depende de los recursos de su proveedor.

En términos de aprovisionamiento del servidor, incluso si no cambió su código de aprovisionamiento, su imagen será válida la mayoría de las veces, pero a veces no. Así que creo que las pruebas son realmente esenciales para proporcionar imágenes de trabajo.

Si va más allá de los servidores individuales, las cosas empeoran aún más ... ¿cómo probará la accesibilidad en configuraciones de red completas? ¿Incluyendo resolución DNS, enrutamiento y firewall? Incluso si su API de proveedores de IaaC funciona como se esperaba (he visto problemas con el cable en esta área), realmente me gusta TDD en este caso.

Como no he encontrado ninguna herramienta de prueba en esta área, escribimos una en nuestro tiempo libre: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

¡Entonces creo que TDD es realmente importante en el mundo de DevOps!