Nobod ist unsere Antwort auf eine immer komplexer werdende Welt.

Hiermit lassen sich beliebig komplexe Infrastrukturen verwalten. Verschiedene Provider und verschiedene Rechenzentren, genauso wie Road Warrior und Cloud Services.

NO BOT Development

Der Name wird etwas anders geschrieben, aber es ist so gemeint. Und doch nicht. So verwirrend, wie dieser Satz, so verwirrend war auch die Entwicklung von NOBOD.

Am Anfang ging es darum, ein immer wiederkehrendes Problem zu lösen. Man baut einen Server auf, installiert Software, löst irgendwelche Konfigurationsprobleme und fasst das dann blos nie wieder an. Never touch a running system ist darauf entstanden. Die Hoffnung, ohne Eingriff den Betrieb einer vermeintlich wackligen Lösung nicht gefährden.

Das Problem löste man eingangs, in dem man die Arbeiten dokumentierte, die zum Erfolg führten. Wir wollten daraus mal ein Buch machen, aber kaum das man das Buch fertig hat, war die Welt eine andere. Ich hab so viele HowTos gelesen, die fast alle veraltet waren, weil sich irgendeine Lösung geändert, und dann saß man da. Ohne Wissen über die Innerereien war man verloren. Man konnte den Erfolg nicht wieder herstellen.

Die nächste Phase war dann die Automatisierung. Eigentlich komisch, aber man machte etwas kompliziertes noch komplizierter. Denn bevor man richtig loslegte, brauchte es einige Vorraussetzungen.

Dieser Bootstrap-Prozess wurde dann auch irgendwann automatisiert und so entstand Ansible.

Kurz gefasst beschreibt man mit Ansible all das, was ein Server, ein Service ausmacht, wie man ihn zum Laufen bringt.

Aber auch Ansible ist nicht das Ende, denn auch Ansible braucht einiges an Wissen. Zum Einen das Wissen, wie man etwas zum Laufen bringt. Zum Anderen muss es wissen, wo man das tun soll. Und selten kommt eine Service ohne andere Services aus. Also braucht Ansible auch dieses Wissen. Dafür kennt Ansible sogenannte Inventories. Ein Inventar aller Dinge, die in einer Umgebung gebraucht werden.

Aber diese Umgebung ändert sich, sie wächst, sie bewegt sich und zudem ist das alles ab einer bestimmten Größe ziemlich unübersichtlich. Und da kommt NOBOD ins Spiel.

Struktur

NOBOD hat die Aufgabe, eine Umgebung zu dokumentieren und zu parametrisieren. Das Ergebnis wird dann von Ansible genutzt, um die Umgebung den Wünschen entsprechend vorzuhalten.

Es gibt eine Reihe von Variablen in NOBOD

• Kunden - als Obermenge jemand, der andere Dienste besitzt oder nutzt.
• Provider - eine Menge an Providern, die Dienste zur Verfügung stellen
• Hosts - physische Maschinenen, auf denen Dienste oder virtuelle Maschinen laufen können
• VM - virtuelle Maschinen, auf denen Dienste laufen
• Dienste - genauer Instanzen von Diensten, die ein Kunde nutzt

Und auch diese Komponenten haben wieder Abhängigkeiten

• Provider brauchen Provider-Konten, um auf Dienste zuzugreifen
• Hosts und VMs brauchen Netze, um miteinander verbunden zu werden (siehe zB. WireGate).
• Dienste brauchen Datenbanken, um ihre Daten zu speichern
• und alles braucht irgendwie Nutzer, die auf die Resourcen Zugriff bekommen.

Hier mal eine grobe Idee, worüber wir reden.

Dies ist eine einfache Struktur. NOBOD greift auf Provider zu, um Resourcen verfügbar zu machen. Anschließend richtet es auf den Resourcen Netzwerke, Datenbanken und Storages ein und erzeugt dann Dienste, die von Kunden genutzt werden wollen.