IT braucht Automatisierung. Nicht nur die Industrie baut Roboter für ihre Produktionsstätten, auch im Bereich Server, Middleware und generell Server-Anwendungen sollte alles automatisiert deployed werden. Doch es gibt kaum gute Tools für ein «Continuous-Operating» nach der Entwicklung.
Entwickler im Überfluss
Das Problem der heutigen Zeit ist, dass es zu viele Entwickler gibt. Ja, richtig gelesen! Es gibt zu viele Entwickler im Vergleich zu den wenigen Operator, welche die Anwendung der Entwicklung betreiben. Es ist in grösseren Betrieben – auch genannt «Enterprise-Umgebung» – nämlich nicht der Entwickler, der Nachts um 04 Uhr ein Disaster Recovery durchführt, sondern der Operator. Es ist nicht der Entwickler der die Logs der Applikation durchwühlt, nachdem ein Switch-Ausfall merkwürdiges Verhalten mit der DB-Verbindung hervorgerufen hat, sondern der Operator. DevOps im wörtlichen Sinne, das gibt es nur in Startups und KMU’s. Wie soll ein Entwickler auch Operator sein, dann müsste er ja 150-200% arbeiten. Er müsste nämlich Nachts aufstehen wenn der nächste Ausfall ansteht, nachdem er tagsüber 100% entwickelt hat. Er müsste die Schnittstelle zum Management spielen, also Rede und Antwort stehen bei Projekten und Störungen. Er müsste an Sitzungen mit den Betriebskollegen im Bereich Firewall, Netzwerk & Server um die Anforderungen seiner Umgebung einzuhalten. Hat er dann noch Zeit für die Entwicklung? Eher nicht. Dazu kommt, dass Entwickler immer etwas Eigenbrötler sind und meistens eine kleine Macke haben 🙂 Es liegt in der Natur eines Entwickler-Typs, ist er im Regelfall eine zurückhaltende Persönlichkeit.
Für Entwickler gibt es hunderte Tools zur Automatisierung, Continues Integration (CI) und Continuous Delivery (CD). Gerade die Test-Labs aufzubauen mit Docker bzw. Vagrant ist der totale Hip geworden. Ein Jenkins beispielsweise, ist in jedem Java-Entwicklerteam irgendwo vorhanden. Aber was kommt nach Jenkins, wenn es darum geht die Anwendung in den laufenden Betriebsprozess einzubinden? Ein Loch, eine Kluft, ein tiefer Abgrund. Es interessiert den Entwickler nämlich nicht, wie der Betrieb Anwendungen über alle Stages deployed. Mit dem Ende der Entwicklung ist für den Entwickler die Arbeit getan.
Operator tut mehr, als Entwickler denkt
Das ist organisatorisch erstmal okay, denn sonst hätte der Operator keine Daseinsberechtigung mehr. Was aber hier als «Loch» und «Abgrund» zu bezeichnen ist, sind die fehlenden Tools für den Operator. Der Operator muss nämlich viel mehr tun, als nur eine Applikation installieren. Im Beispiel Java-Middleware muss eine Laufzeitumgebung deployed werden (z.B. Weblogic, Tomcat, WebSphere), inklusive der Konfiguration für diejenige Applikation. Die Konfiguration ist manchmal sehr komplex, im Falle eines Weblogics kommen dann auch noch verkomplizierte WLST-Scriptings dazu. Das Deployment umfasst nicht selten auch Proxy und LoadBalancing. Es muss ein Monitoring eingebaut werden, welches nicht nur die Erreichbarkeit sondern auch Umsystem-Ausfälle registriert; Datenbank-Crashes, WebService-Ausfälle oder Netzwerkprobleme müssen jederzeit alarmiert werden. Zudem sollte eine Möglichkeit geschaffen werden, die Applikation in wenigen Minuten auf einen oder mehrere neue Server zu deployen – vollständig und mit nur einem Klick, mit allen Komponenten, sei es für einen Umzug oder weil man dank mehreren Knoten hoch skalieren möchte.
Damit ist die Anforderung für ein gutes Operating noch längst nicht zu Ende, denn als nächstes sollte das Zusammenspiel zwischen Entwicklung und Operating komplett verbessert werden. Der Entwickler will nämlich wissen, welche Konfiguration auf der Produktion eingesetzt wird, um im Falle eines Ausfalls (der garantiert schon bald ansteht) sehen zu können unter welcher Konfiguration der Crash verursacht wurde. In der Praxis ist es so, dass der Operator sehr schnell die Hilfe des Entwicklers beanspruchen muss, um wiederkehrende Ausfälle zu verhindern. Also muss der Entwickler Lese-Rechte auf die Laufzeitumgebungs-Konfiguration und Logs der Middleware bekommen, aber nicht auf die Passwörter. Diese Konfiguration ist bestenfalls im zentralen Deployment-Tool des Operators abgelegt. Zudem sollte der Entwickler mit demselben Werkzeug das der Operator benutzt den Test-Server jederzeit redeployen dürfen, inklusive einfachen Konfigurationsänderungen wie z.B. Java-Heap, JDBC-Connection oder WebService URL Properties. Diese Konfigurationsänderungen werden vor dem Go-Live auf Produktion mit dem Operating abgestimmt und bestenfalls für den nächsten Produktions-Release übernommen.
Gerade dann, wenn der Entwickler und der Operator die Konfiguration der Laufzeitumgebung in Test, Stage und Produktion gemeinsam sehen können, wird es nie wieder Probleme geben mit dem Spruch «Aber auf meinem Test-Server läuft es, nur bei dir in Produktion nicht!».
Deployment-Portale sind Mangelware
In diesem Bereich des Zusammenspiels zwischen Entwicklung und Operating gibt es deutlich weniger brauchbare Tools, als ein Entwickler für seine Zwecke zur Verfügung hat. Ganz viele Firmen haben ein Puppet oder ein ähnliches Server-Verwaltungstool im Einsatz, das sich auch für Deployments eignen mag, aber genau hier öffnet sich eine weitere Kluft: Der Systemadministrator als Puppet-Superadmin möchte keinem anderen Team Zugriff auf sein Puppet geben. Und der Application-Operator will eigentlich überhaupt kein Puppet, weil es sich für seine Zwecke sowieso schlecht eignet bzw. zu komplex und zu fest aufgeplustert ist.
Die wirklich guten Deployment-Lösungen waren bisher in der Regel eigene Entwicklungen des jeweiligen Konzerns und nicht Open Source. Auch mein früherer Arbeitgeber hat sich kurzerhand ein eigenes Deployment-Portal programmiert, wodurch das Deployen einer J2EE Anwendung über ein Zentrales Tool auf unendlich viele Server mit nur einem Klick möglich wurde, egal ob Weblogic, Tomcat, SOA-Suite oder Apache. Das Portal ist gleichzeitig auch ein Repository für die letzten Versionen, nebst dem üblichen Maven in der Entwicklung. Der Operator kann jederzeit eine vorherige Version redeployen. Der Zielserver ist auf 0, und mit nur einem Klick wird er mit der jeweiligen Applikation bestückt auf 100. Das Tool war in den meisten Fällen auch so programmiert, dass es auf dem Remote Server die komplette Middleware-Installation wegräumt und neu aufbaut – so ist man sicher, dass das Deployment immer und immer wieder auf egal welchem Server zu 100% funktioniert.
«Wenn etwas im Deployment-Prozess schmerzen verursacht, dann tu es immer und immer wieder – bis es problemlos durchrennt!»
Ansible, ist ein guter Ansatz!
Gibt es Alternativen als Open Source? Ich kenne da kaum gute Tools die sich wirklich grossflächig als Operator eignen und nicht schon wieder auf Entwickler zugeschnitten sind, aber ich denke Ansible ist ein wirklich guter Ansatz. Ansible deckt immer mehr die oben erwähnten Wünsche ab, Ansible ist selbst für den dümmsten Operator wirklich schnell zu erlernen und Ansible pusht nur das auf die Ziel-Server, was es soll. Dabei ist Ansible das genau richtige Tool, neben einem Puppet. Der Server-Admin braucht ein Puppet & Co. mit einem Agenten, denn damit holt sich jeder Server die Konfiguration (pull) in Regelmässigen Abständen vom Master-Server. Der Application-Operator hingegen interessiert sich weniger für die Network, Security oder Backup-Settings des jeweiligen Server, er möchte einfach die Applikation auf den Server deployen. Genau das macht Ansible.
Von Ansible bin ich extrem begeistert, entdeckt habe ich es erst vor wenigen Wochen. Ich selbst baue derzeit diverse automatisierte Installationen in Ansible, das schreiben so genannter Playbooks wird mit jedem Tag einfacher. Ansible hat auch eine Web-Oberfläche genannt «Ansible Tower» (ab 10 Server kostenpflichtig, aber große Konzerne wollen ja immer für alles eine Lizenz, das ist kein Gegenargument!), getestet habe ich sie noch nicht aber die Theorie klingt verlockend: Es können abgestufte Rechte gegeben werden, wodurch z.B. ein Entwickler dank LDAP sich einloggen kann und diese Projekte sieht, die er darf. Ob die Rechte-Vergabe so schlau ist, dass ein Entwickler die Konfiguration in der Produktion nur sehen, aber nicht verändern kann, weiß ich noch nicht. Was aber Ansible definitiv hat, sind Files die als Passwort-Vault dienen, wodurch in einem verschlüsselten YAML .yml File die sensiblen Daten passwortgeschützt abgelegt werden.
Damit ist Ansible gegenwärtig wirklich «Enterprise tauglich» und es sollte in keinem Fall gegen ein Puppet & Co. ausgetauscht werden. Puppet ist gut für den Server-Admin, Ansible ist gut für jedes andere Operating Team welches die eigene Middleware auf frisch installierte Server deployen muss. Vollautomatisch.
0 Kommentare