Infraestructura como código y TDD


11

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.

Respuestas:


6

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.


Entonces, después de un tiempo, esta es exactamente la postura que tomé. Las partes ejecutadas por ansible no se prueban por sí mismas, pero los efectos secundarios de esas acciones se prueban usando 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, usamos gosspara probar el comportamiento del servicio dentro de un contenedor
JackLeo

1

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.


¿Aplica el mismo pensamiento para garantizar que SSH (o lo que sea) esté habilitado en un puerto personalizado específico, que se analiza desde un archivo de configuración externo? Eso no descansa en unidades probadas, esa es una lógica novedosa.
Jon Lauridsen

1
Debería ser parte de IaaC, si es compatible. Si no, entonces esta discusión no se aplica realmente. Sí, esto podría deslizarse en la cantidad de cosas que IaaC puede cubrir, pero esa es una discusión diferente.
Dan Cornilescu

1
También estoy asumiendo que no estamos en un contexto donde se requieren verificaciones redundantes, en algunos casos, verificaciones redundantes que siguen rutas de código completamente diferentes o incluso pueden ser necesarias infraestructuras.
Dan Cornilescu

1

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


1
Sería al menos educado agregar algún comentario con un voto negativo, ¿no te parece un votante malo? Especialmente en este tipo de preguntas donde el debate podría ser muy informativo o incluso constructivo.
Pier

Supongo que el tono de su respuesta, que es bastante agresivo para todos los que han interactuado con esta pregunta, se agregó al hecho de que no está dando ninguna referencia de su propio ejemplo ni describiendo ningún mal funcionamiento observado fue la razón del voto negativo. Finalmente terminas diciendo lo mismo que dicen otras respuestas: hazte pruebas de humo en tu sistema de aprovisionamiento para asegurarte de que el sistema esté bien, lo que la mayoría de los sistemas falla si no pueden converger el sistema en el estado deseado. Con respecto a su edición, por lo general, la fusión se realiza después de implementar en la puesta en escena y garantizar que las pruebas de humo pasen ...
Tensibai

Definitivamente no tenía la intención de ser agresivo, no estoy usando mi idioma nativo aquí (esto es obvio, supongo :)).
Pier

Podemos discutirlo en DevOps Chat si lo desea, creo que vi esta presentación o una similar en un evento devoxx hace unos años. Estoy un poco en desacuerdo con llamar a esa prueba unitaria, eso es más pruebas funcionales.
Tensibai

Alguien de mi equipo de desarrollo me dijo lo mismo, esto no era una prueba unitaria, no soy un desarrollador, así que puedo estar equivocado al llamar a esta prueba unitaria, definitivamente
Pier

1

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!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.