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.
goss
. Entonces, por ejemplo, RPM se instala (ansible) y luego se prueba si el archivo predeterminado esperado está en su lugar, o si el servicio se está ejecutando y escuchando un puerto específico. No quiero solucionar este problema automáticamente, pero recibir una notificación y detener el progreso. Sure Ansible también puede probar el sistema por usted, solo necesita ser explícito al respecto, pero en nuestro caso, usamosgoss
para probar el comportamiento del servicio dentro de un contenedor