He estado usando Puppet para el despliegue de infraestructura, y la mayor parte del trabajo que hago es con compañías Web 2.0 que están muy interesadas en el desarrollo basado en pruebas para su aplicación web. ¿Alguien aquí utiliza un enfoque basado en pruebas para desarrollar sus configuraciones de servidor? ¿Qué herramientas utilizas para hacer esto? ¿Qué tan profundo van tus pruebas?
Respuestas:
No creo que puedas usar el desarrollo basado en pruebas . Pero ciertamente podría probar pruebas unitarias en nuevos servidores.
Básicamente, necesitaría implementar servidores, iniciar los servicios en un modo de prueba y luego ejecutar pruebas desde otro servidor (o serie de servidores) contra los servicios. Luego, finalmente, ponerlos en producción.
Tal vez usando scripts de python para conectarse a bases de datos, páginas web y servicios ssh. Y luego devolver un PASS / FAIL. Sería un buen comienzo para ti.
O podría simplemente enrollar esto en una solución de monitoreo, como Zenoss, Nagios o Munin. Luego puede probar, durante la implementación; Y monitor durante la producción.
Creo que Joseph Kern está en el camino correcto con las herramientas de monitoreo. El ciclo típico de TDD es: escriba una nueva prueba que falle, luego actualice el sistema para que pasen todas las pruebas existentes. Esto sería fácil de adaptar a Nagios: agregue la comprobación fallida, configure el servidor, vuelva a ejecutar todas las comprobaciones. Ahora que lo pienso, he hecho exactamente esto a veces.
Si desea obtener un núcleo realmente duro, asegúrese de escribir scripts para verificar cada aspecto relevante de las configuraciones del servidor. Un sistema de monitoreo como Nagios podría no ser relevante para algunos de ellos (por ejemplo, es posible que no "monitoree" la versión de su sistema operativo), pero no hay razón para que no pueda mezclar y combinar según corresponda.
Si bien aún no he podido hacer TDD con manifiestos de Puppet, sí tenemos un ciclo bastante bueno para evitar que los cambios entren en producción sin pruebas. Tenemos dos titiriteros configurados, uno es nuestro puppetmaster de producción y el otro es nuestro puppetmaster de desarrollo. Utilizamos los "entornos" de Puppet para configurar lo siguiente:
Nuestros desarrolladores de aplicaciones hacen su trabajo en máquinas virtuales que obtienen sus configuraciones de Puppet del entorno de "prueba" de Puppetmaster de desarrollo. Cuando desarrollamos manifiestos de Puppet, generalmente configuramos una VM para que sirva como cliente de prueba durante el proceso de desarrollo y apuntemos a nuestro entorno de desarrollo personal. Una vez que estamos contentos con nuestros manifiestos, los llevamos al entorno de prueba donde los desarrolladores de aplicaciones obtendrán los cambios en sus máquinas virtuales; por lo general, se quejan en voz alta cuando algo se rompe :-)
En un subconjunto representativo de nuestras máquinas de producción, hay un segundo puppetd que se ejecuta en modo noop y apunta al entorno de prueba. Usamos esto para detectar posibles problemas con los manifiestos antes de que sean empujados a la producción.
Una vez que los cambios han pasado, es decir, no rompen las máquinas del desarrollador de la aplicación y no producen resultados indeseables en los registros del proceso "noop" de las máquinas de producción, empujamos los nuevos manifiestos a la producción. Tenemos un mecanismo de reversión para poder volver a una versión anterior.
Trabajé en un entorno que estaba en proceso de migrar a un modelo de operaciones TDD. Para algunas cosas como monitorear scripts esto funcionó muy bien. Utilizamos buildbot para configurar el entorno de prueba y ejecutar las pruebas. En este caso, se acerca a TDD desde la perspectiva del "Código heredado". En TDD "Legacy Code" es un código existente que no tiene pruebas. Entonces, las primeras pruebas no fallan, definen la operación correcta (o esperada).
Para muchos trabajos de configuración, el primer paso es probar si el servicio puede analizar la configuración. Muchos servicios brindan algunas facilidades para hacer esto. Nagios tiene modo de verificación previa, cfagent no tiene acto, apache, sudo, bind y muchos otros tienen instalaciones similares. Esto es básicamente una pelusa para las configuraciones.
Un ejemplo sería si usa apache y archivos de configuración separados para diferentes partes, también puede probar las partes, simplemente use un archivo httpd.conf diferente para envolverlas y ejecutarlas en su máquina de prueba. Luego puede probar que el servidor web en la máquina de prueba da los resultados correctos allí.
En cada paso del camino sigues el mismo patrón básico. Escriba una prueba, apruebe la prueba, refactorice el trabajo que ha realizado. Como se mencionó anteriormente, al seguir este camino, las pruebas pueden no siempre fallar en la forma TDD aceptada.
Rik
Creo que los siguientes enlaces podrían ser de interés
cucumber-nagios - proyecto que le permite convertir su suite Cucumber en el complemento Nagios y que viene con definiciones de pasos para SSH, DNS, Ping, AMQP y tipos genéricos de tareas de "ejecutar comando"
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
También hay algo de esfuerzo en el lado de Puppet / Python de las cosas http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php