Server mit Icinga 1 in Docker migrieren

[PHuV]

Hat hier jemand schon mal einen Server in Docker "konvertiert"? Geht sowas überhaupt? Ich habe mit Docker leichte Erfahrunge, sprich, ich kann eines frisch installieren, adminstrieren etc. Ich bin leider kein Icinga-Kenner, und übernehme den Server, wo keiner mehr weiß, wer das alles erstellt hatte.
Aktuell habe ich das Problem, daß wir von einem Hoster weg müssen, und dort noch ein Monitoring-Server mit Icinga 1 läuft. Das muß woanders übertragen, und würde das gerne als Docker machen.

Probleme sind hier:

• Neuer Server mit CenOS 7, welches kein Icinga 1 mehr als yum bietet.
• Ich habe im Netz kein vernünftiges fertiges Docker mit Icinga 1 gefunden
• Das Monitoring ist sehr groß und aufwendig, so daß man es leider nicht so einfach nach Icinga 2 konvertieren kann

Wenn ich aus der ganze Icinga-Umgebung einfach ein Docker-Image erstellen kann, welches ich dann einfach auf den neuen Server übertrage und dort als Container laufen lassen könnte, wäre das IMHO erst mal die beste Lösung. Dann kann man immer noch später mal vernüftig das nach Icinga 2 in Form eines kleinen Projektes migrieren (oder von einem Studenten/Praktikanten migrieren lassen).

Ich bin für gute Vorschläge dankbar.

 

[john.smiles]

Ich kann dir nicht helfen, aber ich muss antworten, weil dein Post so herrlich ist.

Wir sollen dir (natürlich gratis) Arbeit erledigen und dann darf später eine kostenlose den Rest erledigen.

Einfach göttlich diese Einstellung Als nächstes werden statt Kaufberatungen gleich die Produkte gratis verteilt. Internet Gratiskultur halt

 

[Moe.Joe]

Grundprinzip von docker nicht verstanden. Das was du willst ist ein clone deiner Maschine. Dafür muss eine VM herhalten, VMware, kvm oder was auch immer. Docker ist keine VM. Man kann docker zwar so verbasteln dass es einer vm gleich kommt aber...unterstütze ich nicht.
Migrier das Ding als vm und lass deinen Studenten sich in docker einarbeiten.
Zusammengefasst kannst du ein docker run xyz Paket ausführen und sollst einen Server migrieren dessen Funktionsweise noch nicht kennst.
Schritt 1. sich mit dem Monitoring beschäftigen und den dazugehörigen Komponenten (werden für einen docker benötigt)
Schritt 2. sich mit docker beschäftigen und zunächst mal kleine Projekte testen. Nicht nur docker run(Update,Backup, etc).

Ich halte das Projekt für denkbar ungeeignet, zumindest mit dem Wissensstand (nichts für ungut). Hau das Ding auf ne vm und gut is.

 

[snaxilian]

+1 für Moe.Joe.

@PHuV: Was du suchst nennt sich Virtualisierung, kannst auf dem neuen Server z.B. mit KVM/QEMU umsetzen. Alten Incinga Server kannst im besten Fall mit p2v umziehen.
Danach kannst auf was aktuelles migrieren bzw durch etwas ablösen lassen was noch aktiv entwickelt wird, Möglichkeiten gibt es genug. Icinga2, check_mk oder zabbix fallen mir da auf die Schnelle ein.
Außerdem solltet ihr euch genau überlegen ob man das Monitoring nicht möglichst unabhängig der restlichen Infrastruktur betreiben sollte um unnötige Abhängigkeiten zu vermeiden.

 

[PHuV]

Keine Sorge, ich weiß sehr wohl was Virtualisierung und Docker ist. Und es sollte die Hobby-ITler doch einfach mal schweigen und nicht ihre geistigen Unfähigkeiten so rausposaunen, das hat hier nichts verloren. Es war eine normale Anfrage, ob es Erfahrungen dazu gibt, davon wird keiner arm oder reich hier, und es wird hier auch keine Arbeit abgenommen, die mache ich und andere schon selbst.

Nein, ich suche keine Virtualisierung, da der Server für Icinga 1 bereits eine Citrix VM ist, und wir auf einen bestehenden (!) Server beim Kunden migriren müssen, da es aktuell keine neuen Server mehr dafür gibt. Sonst würde ich auch sagen, exportieren und dann versuchen, beim anderen Hoster mit VMWare importieren (was aber auch in einigen Fällen nicht klappt). Kunde will das aber nicht so.

Aber man kann auf dem neuen Servern eine zusätzliche Docker Instanz starten. Mit einem neuen Jenkins und Nginx habe ich das so mal eben erfolgreich machen können, aber mit Icinga 1 klappt das leider nicht so einfach. Hier war meine Idee, bestehendes Docker-Image mit Icinga 1 laden, dort die bestehende Konfiguration übernehmen, fertig. Da ich aber kein passendes gefunden hatte, und es nur für Icinga 2 entsprechend gute Vorlagen gibt, muß der Kunde eben dann mühsam die Migration selbst irgendwie vornehmen. Es gibt einige Konvertierungsscripte, die einiges von Icinga 1 nach 2 portieren können sollen, aber das muß dann auch erst mal getestet werden (wofür mir die Zeit leider fehlt).

Es hätte ja sein könne, daß jemand schon sowas mal gesehen oder angewendet hat, weil vermutlich mehr Interesse daran haben, bestehende Prozesse auf Servern als kleinere Docker-Images mit laufenden Containern zu migrieren. Gut, bekommt der Kunde Feedback, daß es eben doch nicht so einfach migrierbar ist und mehr Zeit und Aufwand + Geld kosten wird, Icinga 1 abzulösen.

 

[snaxilian]

So ist's ja meist, Kunde will nur billigbillig. Ist trotzdem nicht der beste Weg ein bestehendes System in ein Docker-Image zu gießen. Entweder musst dir das Image komplett selbst bauen inkl. aller Abhängigkeiten und da dann im besten Falle auch gleich jede abhängige Anwendung und Unterkomponente in eigene Container und alles schön in ein docker-compose verpacken. Auch musst eben alle relevanten Pfade und Speicherorte in persistente Volumes packen falls du doch mal migrieren oder eine Version austauschen willst.

Kannst du nicht auf dem bestehenden Docker-Host QEMU/KVM nachrüsten und dann da das Icinga 1 weiterlaufen lassen? Dann musst du "nur" von citrix/xen auf qemu/kvm eine v2v Migration durchführen.

 

[PHuV]

Das wäre auch eine Idee, vielen Dank. Wie gesagt, hängt ja nicht von mir ab, sondern vom Kunden. Da der gedachte Server auch eine VM ist, wäre das eine VM in einer VM, was auch nicht so schick ist.

Ich würde es wie Du machen, und sauber gleich auf Icinga 2 migrieren, auch wenn das Zeit und Aufwand kostet. Es scheint im Netz Scripte zu geben, welche die Icinga1 Notation in die geändere 2er Form bringen könnten, aber wer weiß, wie gut diese auch funktionieren.

 

[snaxilian]

Ich weiß schon, warum ich nicht mehr im Systemhaus arbeite
Du kannst dir aber natürlich auch selbst einen Icinga1 Container bzw. Compose basteln musst dann aber so ziemlich alles selbst und zu Fuß erledigen, Aufwand den der Kunde sicher nicht will. Aber nicht durchgeführte regelmäßige Wartung und Pflege rächt sich früher oder später, die Erfahrung will nur offenbar jeder "Entscheider" persönlich einmal machen^^

 

[PHuV]

Wenn es interessiert, wie es ausging:

Ein Kollege hat es doch noch geschafft, ein Docker mit Debian 9 und Icinga 1 zu bauen. Die Konfiguration wurde auf ein Volume ausgelagert, wohin ich die Konfiguration dann kopierte. Jedoch gab es einige Fehler und Probleme, obwohl es ein Icinga 1.13.3 (alt VM Server Debian 7) zu 1.13.4 (neu Docker Debian 9) ist :, wer hätte das gedacht? Soviel zu "Kompatibilität". Hat mich doch einen ganzen Tag Zeit gekosten, die Fehler in den Konfigurationsdateien zu finden und zu fixen. Aber es läuft jetzt. Trotz allem wäre mir eine saubere neue Installation mit Icinga 2 lieber gewesen. Egal, Kunde wollte es so.

 

[Moe.Joe]

Schön dass es noch geklappt hat.
Allerdings hast du den Docker für etwas missbraucht das er nicht ist.
Du hast jetzt try & error mäsig alle Fehler Schritt für Schritt behoben und es läuft nun. Wenn sich das Ding jedoch mal aufhängt dann wünsche ich viel Spaß bei der Fehlersuche.
Da hätte ich eine Nested VM als bessere Lösung angesehen.
Einen Debian Container zu nehmen und dort irgendwelche Pakete zu installieren mag zwar funktionieren, aber ich als "hobby ITler" muss es nochmal sagen, das ist komplett gegen das Konzept eines Docker-Containers. Leider wird das aber bereits von vielen so vorgelebt - siehe dockerhub.

 

[snaxilian]

Docker ist leider für viele Devs und Unternehmen das, was vor 2-3 Jahren noch eine VMware Template bzw Appliance war. Eine einfach zu verteilende Möglichkeit ohne Beachtung des zugrunde liegenden Systems ihre Anwendungen zu verteilen. Das dabei so Dinge wie persistente Daten in Volumes, ein Container pro (Mikro-)Anwendung und dann lieber docker-compose. Da wird das Prinzip Docker nicht verstanden sondern nur zusammen gefrickelt bis es (einmalig) läuft und dann halt ship and forget it.
Aber ich denke, PHuV weiß wie Docker funktioniert und wenn $Kunde es wider besseren Wissens und Rat trotzdem so fordert: Am Ende macht man das, was die Miete sichert und sichert sich im besten Fall noch schriftlich ab für die Zukunft.