Geschichte¶
Schon seit Ende 2013 verwendet das Serverteam zur Verwaltung unserer insgesamt 16 physikalischen und 12 virtuellen Server Ansible, welche die bis zu diesem Zeitpunkt genutzte Puppet-Implementierung ablöste. Hauptgrund der damaligen Migration von Puppet zu Ansible war in erster Linie die einfachere Integration in unsere Infrastruktur und die Tatsache, dass Ansible keinen Dienst außer SSH auf dem zu verwaltenden System benötigt. Ein netter Nebeneffekt war zudem, dass Ansible, genau wie Inyoka, Python als Programmiersprache nutzt.
Was ist Ansible? Wieso Automatisieren?¶
Ansible ist ein Konzept, um klar festgelegte Zustände eines Servers zu definieren. Ähnlich wie bei puppet kann Ansible dafür sorgen, dass der Server genau die Pakete installiert hat und genau die passende Konfiguration besitzt, wie es sich der Administrator vorstellt. Vorteil bei den Automatisierungen liegt hier bei der einfachen Verwaltbarkeit und der geringeren Fehleranfälligkeit. Egal ob ein oder 100 Server, jede Maschine bekommt die gleiche Konfiguration und Programme. Die Fehlerquelle „Mensch“ wird so sehr gering gehalten. Natürlich ist sie immer noch vorhanden, da ja der Mensch die Anweisungen in Form von Playbooks – so nennt sich eine Aufgabensammlung bei Ansible – erstellt.
Anders als puppet, welches eine Datenbank, einen Masterserver und auf jedem Host einen Client benötigt, nutzt Ansible die bestehende SSH-Verbindung zum Host, um die Anweisungen auszuführen. Hierfür greift Ansible auf Python zurück, was auf dem Zielrechner installiert sein muss. Das vereinfacht die Benutzung und spart Ressourcen.
Wie sieht das ganze nun im Alltag aus?¶
Administrative Aufgaben lassen sich in den meisten Fällen in kleinere, sehr ähnliche, Aufgaben zerlegen. Dazu gehören unter anderem das Anlegen von Benutzern, die Veränderung von Konfigurationen oder das Verwalten von System-Diensten. Einzeln betrachtet relativ einfach und schnell per Hand erledigt, können solche Aufgaben multipliziert mit 100 enorm viel Zeit in Anspruch nehmen. Genau hier liegt die Stärke der Automatisierung.
Das Ziel von Werkzeugen wie Ansible, Puppet, Saltstack oder CFEngine ist es, Aufgaben wie zuvor genannt, auf sämtlichen Computersystemen reproduzierbar, nachvollziehbar und flexibel zu gestalten. Viele Aufgaben, die traditionell per Shell-Script erledigt wurden, werden heute zunehmend in derartige Automatisierungswerkzeuge verlagert. Das hat zudem den Vorteil, dass in gewissem Umfang automatisch eine Art Dokumentation entsteht. Im Idealfall muss nur das Playbook noch einmal ausgeführt werden und man hat zum Beispiel beim Ausfall eines Servers einen neuen Server mit exakt der Konfiguration des ausgefallenen Servers.
Warum Ansible Tower?¶
Während das Serverteam mit Ansible auf der Kommandozeile arbeitet und somit direkt mit der Infrastruktur kommuniziert, gibt es zunehmend die Anfrage weiterer Teammitglieder, selbst Aufgaben in die Wege leiten zu können, um so unabhängiger vom Serverteam zu sein. Gegenwärtig werden viele Seiten, die früher mit Drupal oder anderen Content Management Systemen verwaltet wurden, auf Static Page Generatoren wie z.B. Pelican 🇬🇧 umgestellt. Es wird also keine Datenbank mehr benötigt, sondern es müssen nur die statischen Seiten, üblicherweise nach einem git checkout, neu gebaut werden. Dies betrifft zwar nicht ubuntuusers.de, doch ist dies für die Seite des ubuntu Deutschland e.V. sowie der Ubucon Deutschland der Fall.
Mit Ansible Tower können derart einfache Tätigkeiten durch ein Berechtigungssystem delegiert werden, so dass der Autor einer solchen Seite direkt das Aktualisieren anstoßen kann – ganz
ohne SSH Zugang zu den Servern oder Anfrage an das Serverteam. Hierdurch wird das Gesamtteam mehr in die Entwicklung und Administration einbezogen und längere Anfragen können so verringert werden.
Eine andere Aufgabe, die Tower zukünftig übernehmen soll, sind sogenannte „scheduled Tasks“. Darunter versteht man Aufgaben, die regelmäßig durchgeführt werden müssen. Die wichtigste dieser Aufgaben ist das Erneuern unserer Let's Encrypt-Zertifikate. Außerdem wird es das Aktualisieren von Paketlisten auf den Servern übernehmen, auch wenn es alleine hierfür mehr als genug Alternativen gäbe.
Ausblick¶
Für die Zukunft relevanter wird jedoch vor allem der Umgang mit Containersystemen jeglicher Art (beispielsweise Docker oder LXD). Hier prüft das Serverteam die verschiedenen technischen Möglichkeiten, um unsere vorhandenen Dienste noch mehr voneinander zu isolieren.
Ebenfalls wichtig ist es, ausgefallene Systeme schneller ersetzen zu können und dadurch auch die Beständigkeit der einzelnen Portale zu gewährleisten. Es ist nur noch eine Basisinstallation erforderlich, den Rest übernimmt Ansible – und damit langfristig auch Tower bei uns. In den letzten Jahren mussten wir sehr wenige Hardwareausfälle kompensieren und durch Dezentralisierung und Automatisierung können wir diese mittlerweile deutlich besser ausgleichen als noch vor einigen Jahren.
Entwicklung¶
So wie wir gegenwärtig in den letzten Zügen an einer Veröffentlichung von Inyoka arbeiten, arbeitet auch Red Hat an der Veröffentlichung von Tower als Open-Source-Software. Wer als Community Projekt eine Lizenz benötigt, wendet sich am Besten mit einer Begründung an das Sales Team. Diese helfen in der Regel schnell, auch bei den ersten Schritten mit Tower, weiter. Ebenso wie es für Inyoka (bisher) noch kein Veröffentlichungsdatum gibt, ist dies auch bei Tower der Fall. Wetten, wer zuerst fertig ist, sind aber ausdrücklich gestattet. 😉
Vielen Dank an das Serverteam für den eingereichten Artikel.
