Man kann von einem Director auf andere verschiedene getrennte Icinga-Umgebungen zugreifen und dorthin deployen, die auch mit Director gepflegt werden. In diesem Szenario haben wir unterschiedliche getrennte Masters. Allerdings ist dies fehleranfällig, da das falsche Director-Backend ausgewählt werden könnte und damit nicht in die gewünschte Umgebung konfiguriert wird. Deshalb stellt sich die Frage ” ist es nicht vernünftiger sich bei dem gewünschten Master einzuloggen und den lokalen Director zu benutzen? “. Meiner Meinung nach ist das richtig, aber ich will die Aufmerksamkeit an dieser Stelle auf die Vorzüge des Directors lenken. Vielleicht wird es in der Zukunft nützlich sein.
Was braucht man, um dieses Szenario umsetzen zu können?
Zuerst müssen wir dem lokalen Director Zugriff auf die entfernte Director-Datenbank erlauben. Zusätzlich brauchen wir einen Api-User, der den entfernten Icinga-Core ansprechen kann und uns remote deployment ermöglicht.
Unter /etc/icingaweb2/resources.ini tragen wir die entfernte Director-Datenbank ein:
[director_customer1]
type = "db"
db = "mysql"
host = "ip"
dbname = "director"
username = "username"
password = "password"
charset = "utf8"
use_ssl = "0"
Unter /etc/icingaweb2/modules/director/config.ini machen wir die neue Resource dem Director bekannt:
[db]
resource = "director_db" // unsere lokale Director-Datenbenk
resources = director_customer1, director_customer2 // Remote Director-Datenbank
So bekommen wir ein drop down menu oben rechts im Director-Interface. Wir können z.B director_customer1 auswählen und unter Icinga Infrastruktur => Endpoints überprüfen, ob der Api-User eingetragen ist. Ab diesem Moment können wir Konfigurationen auf dem entfernten Master verwalten, die Director spezifisch sind.
0 Comments