Folgendes Problem: Eine große Menge an virtuellen Maschinen muss angelegt werden und verwaltet werden auf mehreren Hypervisors. Um die Verwaltung zu vereinheitlichen sollen die Arbeiten über eine zentrale API erledigt werden. Nach aktuellem Stand der Technik nutzt man JSON für die API Kommunikation nach außen, zusätzlich ist es hilfreich wenn man eine grafische Oberfläche zur Verfügung hat. Hierfür bietet sich z.B. das Ruby on Rails Framework an. Dies bietet mit einfachen Mitteln die Erstellung einer JSON-API + HTML Oberfläche in einer App.
Nur wie greift diese API wiederum auf die einzelnen Hypervisor zu?
1) Die einfachste Möglichkeit ist hier eine SSH Verbindung und dann direkt Shellkommandos ausführen. SSH hat hier den Vorteil der starken Verschlüsselung, allerdings dauert der Verbindungsaufbau relativ lange, dies kann mit Connection Pools und Queueing umgangen werden was allerdings nicht trivial in der Implementierung ist. Wenn Zielserver eine hohe Auslastung haben werden SSH Verbindungen sehr träge und brechen ab da Sie dafür nicht konzipiert sind. Dies könnte wiederum mit Mosh geworkarounded werden, entspricht dann aber auch nicht mehr dem KISS Prinzip. Ein großes Problem ist hier die Sicherheit, die API müsste zusammengesetzte Strings via SSH ausführen, viele Kommandos benötigen Rootrechte. Der Aufwand um Strings auf eingeschleusten Code zu überprüfen und zu bereinigen (data serialization) ist sehr hoch.
2) AMQP bietet eine einfache Möglichkeit serialisierte Nachrichten von einem Server zu beliebig vielen anderen zu schicken. Die meisten Daemons die dieses Protokoll implementieren bieten die Verschlüsselung über SSL Zertifikate an, sowie Clustering. AMQP stellt sicher das Nachrichten schnell verschickt werden können, Queueing ist ebenfalls eingebaut sowie der Support für HA Setups um dem Verlust von Nachrichten vorzubeugen. Openstack nutzt ebenfalls AMQP und hat sich dort bewährt. Doch was nutzt man auf den Hypervisors um die Nachrichten zu interpretieren?
Hier müsste ein eigener Daemon entwickelt werden welcher die Nachrichten parst, mit doppelten Nachrichten umgehen kann, die passenden Libraries triggert und Antworten verschicken kann. Mir sind hier keine fertigen Open Source Lösungen bekannt weshalb man “From Scratch” entwickeln müsste.
3) Ich nutze exzessiv Puppet zum Automatisieren meiner Infrastrukturen, Puppet ist in erster Linie ein Configuration Management System und kümmert sich darum dass auf allen Systemen die benötigten Pakete installiert sind, alle Konfigurationsdateien entsprechend angepasst sind und alle benötigten Dienste laufen. Im Regelfall verbinden sich Puppet Agents alle X Minuten zu einem Master und erfragen eine Konfiguration welche Sie dann anwenden (Details). Im Optimalfall installiert man auf einem Server eine Standarddistribution + Puppet, lässt den Agent einmalig laufen und hat danach ein komplett eingerichtetes System. Bei einem minimalen Hypervisor komme ich auf ca 370 Ressourcen pro Node die Puppet verwalten muss (Jedes Paket, jede Konfigurationsänderung ist eine Ressource). Neben eingebauter Verschlüsselung und Authentifizierung mit Client-SSL-Zertifikaten bietet Puppet eine eigene Datenbank für Reports um Änderungen naczuvollziehen, automatisierte Tests + Testumgebungen sowie diverse andere Tolle Features, aber das Feature, weshalb Puppet überhaupt hier im Vergleich ist, ist die Möglichkeit eine Konfiguration dynamisch aus einer Datenbank oder einem Scriptaufruf heraus zu erzeugen. Benötigt wird dazu eine API mit zwei Seiten, auf der einen befinden sich die Administratoren, dann kommt die API und dahinter die Hypervisors + Puppet. Die Admins legen über die API neue VMs an oder änderen deren Specs, auf der anderen Seite befindet sich der Puppet Master welcher sich bei jeder eingehenden Agent Verbindung zu API verbindet und fragt welche VMs mit welchen Specs auf den Nodes liegen sollen. Puppet kann die VMs dann entsprechend anlegen(z.B. mit diesem Modul).
Diese Idee schwebt mir schon lange im Kopf und ist meine favorisierte, hat allerdings einen Nachteil:
Das managen von 100 VMs mit diversen Attributen + das verwalten von ~370 Ressourcen benötigt eine gewisse Zeit und erzeugt eine gewisse Systemlast. Um schnell Änderungen der VMs zu aktivieren sollte der Agent alle 5 Minuten laufen. Es ist aber sinnlos die zusätzlichen 370 Ressourcen so häufig zu überprüfen. Um dieses Problem zu lösen habe ich vorhin eine Lösung mit Adrien Thebo von Puppetlabs erdacht (ganz unten zu finden).
Grobe Zusammenfassung:
Zum Einen kann ich verschiedene Laufzeitumgebungen auf dem Puppet Master für die Agents konfigurieren die in verschiedenen Zeitintervallen abgefragt werden, zum Anderen kann ich einen Katalog aufsplitten in einen infrastructure Bereich und einen virtualization Bereich (mit Tags), die dritte Option ist das Setzen von bestimmten Attributen auf dem Hypervisor (FACTER_doodoo=”infra”) welche dann einen Infrastrukturspezifischen Katalog oder einen Virtualisierungsspezifischen Katalog erstellen lassen auf dem Master.
Das Regelmäßige springen zwischen Laufzeitumgebungen entspricht nicht den Best Practices, das Setzen von Tags funktioniert, führt aber manchmal zu komischen Effekten. Lösung Eins möchte ich ausschließen, Lösung zwei und drei muss ich in der Praxis evaluieren.
Von diesen drei Ansätzen eines API Konzepts halte ich die Puppet Variante für die einzig skalierende, ich bin hier aber für weitere Vorschläge und Anregungen offen.
2015-02-27 22:20:58 bastelfreak finch: I need to do dirty stuff with puppet and you're probably the right guy to help me
2015-02-27 22:21:35 bastelfreak I manage many hypervisors with puppet, managing their configs, installing packages, stuff like that
2015-02-27 22:21:48 bastelfreak currently around 360 resources on each node
2015-02-27 22:22:07 bastelfreak I also want to deploy my virtual maschines on these nodes via puppet
2015-02-27 22:22:32 +finch kay
2015-02-27 22:22:44 bastelfreak handling xml shit with libvirt takes some time, and I've around 100 maschines on each node
2015-02-27 22:22:59 bastelfreak deploying VMs should happen every 5minutes
2015-02-27 22:23:25 +finch https://github.com/carlasouza/puppet-virt ?
2015-02-27 22:23:25 bastelfreak handling all VMs + the normal 360 resources would create a huge system load if I do it every 5min
2015-02-27 22:23:39 +finch oh, you want to avoid touching certain resources
2015-02-27 22:23:41 bastelfreak so my thought was to create two environments
2015-02-27 22:24:20 +finch you might be able to use https://docs.puppetlabs.com/puppet/latest/reference/lang_tags.html#restricting-catalog-runs
2015-02-27 22:24:21 bastelfreak the agent runs every 5min in the env virtualisation and every hour or so in the env infrastructure
2015-02-27 22:24:52 bastelfreak uh
2015-02-27 22:24:54 bastelfreak sweet
2015-02-27 22:24:56 +finch one catalog, one environment, and if you're using roles and profiles then you just run puppet with `--tag profile::virt
` or `--tag profile::env` 2015-02-27 22:25:21 +finch be aware that tags are strange, and you should definitely test with --noop first to make sure it works like you expect
2015-02-27 22:25:29 +finch barring that, two environments would work.
2015-02-27 22:25:32 bastelfreak can the daemon handle tags?
2015-02-27 22:25:35 +finch that, or you change the classification via a fact
2015-02-27 22:25:40 +finch `puppet agent -t --tags etc`
2015-02-27 22:25:43 bastelfreak ah cool
2015-02-27 22:26:01 +finch you could also do FACTER_classification='infra' puppet agent -t
2015-02-27 22:26:15 +finch in your site.pp you inspect the classification fact, and then conditionally include classes
2015-02-27 22:26:42 +finch be warned that you need to validate the hell out of a fact if you do this; don't allow the fact to include arbitrary cl
asses 2015-02-27 22:26:53 bastelfreak oh yeah
2015-02-27 22:27:02 bastelfreak but doesn't sound as dirty as I thought
2015-02-27 22:27:38 bastelfreak current style is "A API does a login via ssh and trigger a shell script"
2015-02-27 22:27:44 bastelfreak I want to avoid ssh access
2015-02-27 22:27:45 +finch FACTER_doodoo="infra"
2015-02-27 22:27:47 +finch it's dirty now
2015-02-27 22:27:50 bastelfreak :D
2015-02-27 22:28:22 +finch if it's viable to run different command invocations, either of these approaches, with tags or with fact based classific
ation, could work 2015-02-27 22:28:25 +finch anywho. meeting, bbl
2015-02-27 22:28:31 bastelfreak bb, thanks
(Toll formatiert gibt es den Text Hier)
