Ich habe Puppet für die Bereitstellung der Infrastruktur verwendet und arbeite hauptsächlich mit Web 2.0-Unternehmen, die sich intensiv mit testgetriebener Entwicklung für ihre Webanwendung beschäftigen. Verwendet hier jemand einen testgetriebenen Ansatz zur Entwicklung seiner Serverkonfigurationen? Mit welchen Tools verwenden Sie dies? Wie tief gehen Ihre Tests?
Antworten:
Ich glaube nicht, dass Sie eine testgetriebene Entwicklung gebrauchen könnten . Aber Sie könnten sicherlich Unit-Tests auf neuen Servern versuchen .
Grundsätzlich müssten Sie Server bereitstellen, die Dienste in einem Testmodus starten und dann Tests von einem anderen Server (oder einer Reihe von Servern) für die Dienste ausführen. Dann endlich in Produktion gehen.
Verwenden Sie möglicherweise Python-Skripte, um eine Verbindung zu Datenbanken, Webseiten und SSH-Diensten herzustellen. Und dann einen PASS / FAIL zurückgeben. Wäre ein guter Start für Sie.
Oder Sie können dies einfach zu einer Überwachungslösung wie Zenoss, Nagios oder Munin zusammenfassen. Anschließend können Sie während der Bereitstellung testen. Und während der Produktion überwachen.
Ich denke, Joseph Kern ist mit den Überwachungstools auf dem richtigen Weg. Der typische TDD-Zyklus lautet: Schreiben Sie einen neuen Test, der fehlschlägt, und aktualisieren Sie das System so, dass alle vorhandenen Tests bestanden werden. Dies lässt sich leicht an Nagios anpassen: Fügen Sie die fehlgeschlagene Prüfung hinzu, konfigurieren Sie den Server und führen Sie alle Prüfungen erneut aus. Kommen Sie und denken Sie darüber nach, ich habe manchmal genau das getan.
Wenn Sie einen wirklich harten Kern erhalten möchten, sollten Sie Skripte schreiben, um alle relevanten Aspekte der Serverkonfigurationen zu überprüfen. Ein Überwachungssystem wie Nagios ist für einige von ihnen möglicherweise nicht relevant (z. B. "überwachen" Sie möglicherweise nicht Ihre Betriebssystemversion), aber es gibt keinen Grund, warum Sie nicht entsprechend mischen und anpassen können.
Obwohl ich TDD mit Puppet-Manifesten noch nicht durchführen konnte, haben wir einen ziemlich guten Zyklus, um zu verhindern, dass Änderungen ohne Tests in die Produktion gehen. Wir haben zwei Puppenspieler eingerichtet, einer ist unser Produktionspuppenmeister und der andere ist unser Entwicklungspuppenmeister. Wir verwenden die "Umgebungen" von Puppet, um Folgendes einzurichten:
Unsere Anwendungsentwickler arbeiten an virtuellen Maschinen, die ihre Puppet-Konfigurationen aus der "Test" -Umgebung der Entwicklungs-Puppetmaster beziehen. Wenn wir Puppet-Manifeste entwickeln, richten wir normalerweise eine VM ein, die während des Entwicklungsprozesses als Testclient dient, und verweisen auf unsere persönliche Entwicklungsumgebung. Sobald wir mit unseren Manifesten zufrieden sind, schieben wir sie in die Testumgebung, wo die Anwendungsentwickler die Änderungen auf ihren VMs erhalten - sie beschweren sich normalerweise laut, wenn etwas kaputt geht :-)
Auf einer repräsentativen Teilmenge unserer Produktionsmaschinen befindet sich eine zweite Puppe, die im Noop-Modus ausgeführt wird und auf die Testumgebung zeigt. Wir nutzen dies, um potenzielle Probleme mit den Manifesten zu erkennen, bevor sie in die Produktion gehen.
Sobald die Änderungen abgeschlossen sind, dh die Maschinen des Anwendungsentwicklers nicht beschädigen und keine unerwünschten Ausgaben in den Protokollen des "noop" -Puppenprozesses der Produktionsmaschinen erzeugen, schieben wir die neuen Manifeste in die Produktion. Wir haben einen Rollback-Mechanismus eingerichtet, damit wir zu einer früheren Version zurückkehren können.
Ich habe in einer Umgebung gearbeitet, die gerade auf ein TDD-Betriebsmodell migriert wurde. Für einige Dinge wie das Überwachen von Skripten funktionierte dies sehr gut. Wir haben Buildbot verwendet, um die Testumgebung einzurichten und die Tests auszuführen. In diesem Fall nähern Sie sich TDD aus der Perspektive von "Legacy Code". In TDD ist "Legacy Code" vorhandener Code, der keine Tests enthält. Damit die ersten Tests nicht fehlschlagen, definieren sie den korrekten (oder erwarteten) Betrieb.
Bei vielen Konfigurationsjobs besteht der erste Schritt darin, zu testen, ob die Konfiguration vom Dienst analysiert werden kann. Viele Dienste bieten einige Einrichtungen, um genau dies zu tun. Nagios hat den Preflight-Modus, cfagent hat keine Handlung, Apache, Sudo, Bind und viele andere haben ähnliche Funktionen. Dies ist im Grunde ein Flusenlauf für die Konfigurationen.
Ein Beispiel wäre, wenn Sie Apache und separate Konfigurationsdateien für unterschiedliche Teile verwenden. Sie können die Teile auch testen. Verwenden Sie einfach eine andere httpd.conf-Datei, um sie für die Ausführung auf Ihrem Testcomputer zu verpacken. Anschließend können Sie testen, ob der Webserver auf dem Testgerät dort die richtigen Ergebnisse liefert.
Jeder Schritt auf dem Weg folgt dem gleichen Grundmuster. Schreiben Sie einen Test, bestehen Sie den Test und überarbeiten Sie die von Ihnen geleistete Arbeit. Wie oben erwähnt, schlagen die Tests möglicherweise nicht immer auf die akzeptierte TDD-Weise fehl, wenn Sie diesem Pfad folgen.
Rik
Ich glaube, die folgenden Links könnten von Interesse sein
cucumber-nagios - Projekt, mit dem Sie Ihre Cucumber- Suite in ein Nagios-Plugin verwandeln können und das Schrittdefinitionen für SSH-, DNS-, Ping-, AMQP- und generische Aufgabentypen "Befehl ausführen" enthält
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Es gibt auch einige Anstrengungen auf der Puppet / Python-Seite der Dinge http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php