Icon Rufen Sie uns an
+49 441.309197-69 +49 441.309197-69
 
DE

Infrastrukturdatenbank Meilensteinplan 2017

Posted by Daniel Rauer / Felix Kronlage on Tuesday, May 09, 2017

Je mehr Kunden wir die Infrastrukturdatenbank vorstellen und je öfter wir die IDB auf Konferenzen zeigen desto mehr Ideen entstehen welches die nächsten Schritte sein könnten und welche Funktionen von uns und unseren Kunden gewünscht werden. Mit der Veröffentlichung der IDB Kernanwendung sowie ihrer Adapter auf GitHub, unter einer von der OSI anerkannten Lizenz, haben wir letztes Jahr einen grossen Schritt getan: Ein internes Werkzeug zu einer Open Source Lösung zu entwickeln.

Aktuell bewegen wir uns innerhalb der Version 1.6. Die Versionierung und der Entwicklungsablauf der IDB sind einfach: Die Entwicklung passiert auf dem development Branch, aus welchem neue Versionen in einen release Branch herausgelöst werden. Für den 1.6er Zweig werden nunmehr lediglich kritische Fehler behoben; daraus werden bei Bedarf entsprechende Versionen 1.6.4, 1.6.5 usw. gebaut.

Funktionen der IDB Kernanwendung sind an die Version der IDB gebunden; Funktionen die lediglich Adapter betreffen dagegen nicht. Daher haben wir sowohl einen versionsbasierten Meilensteinplan für die Kernwanwendung wie auch für die Adapter. Diese Pläne enthalten alle wichtigen Erweiterungen um einen Eindruck zu vermitteln wohin sich die IDB entwickeln wird; all die kleinen Verbesserungen und Korrekturen sind jedoch nicht enthalten. Die vollständige Liste mit offenen Fehlern und ToDos findet sich auf GitHub.

Meilensteine der Kernanwendung

Version 1.7 - geplante Veröffentlichung Ende Q2 2017

Zwei wesentliche Neuerungen werden in dieser Version enthalten sein:

  • Mandantenfähigkeit
  • Version 3 der API

Mandantenfähigkeit

In der IDB gibt es das Konzept der "Owner", inhaltlich übersetzbar mit "Kunde" oder "Besitzer". Diese sind mit Ressourcen wie Maschinen (physisch wie virtuell), Inventarobjekten etc. verbunden. Die Mandantenfähigkeit schränkt die Sichtbarkeit dieser Objekte auf mit dem Anwender assoziierte "Owner" und deren Objekten ein. Wir werden zeitnah über die technische Umsetzung dessen hier auf unserem Blog berichten.

APIv3

Mit der dritten Version der API werden wir alle Ressourcen sichtbar machen, im Gegensatz zur aktuellen Version 2 die dies nur für Maschinen und Software Pakete ermöglicht. Die kommende Mandantenfähigkeit ist hier sinnvollerweise bereits berücksichtigt um unbefugte Zugriffe auch via API sicher zu verhindern. Das die APIv3 ein wirklich grosser Schritt ist, sieht man an der Liste der Neuerungen die uns mit der Fertigstellung ermöglicht werden:

Durch die Möglichkeit auf das gesamte Datenmodell der IDB zuzugreifen können wir nun sowohl NeDI als auch oxidized integrieren: Dann werden nicht nur Netzwerke und Switche über die API verwaltet, sondern auch Dateien können über die API an Objekte gehängt werden. Dadurch wird ermoeglicht automatisiert Router- und Firewallkonfigurationen in der IDB versioniert zu verwalten.

Ebenfalls wird der Ansible Adapter, von dem im Verlauf des Textes noch die Rede sein wird, auf die APIv3 aufbauen und Teil der Arbeit an der Version 1.7 sein.

Weiterhin werden wir uns dem Thema Reporting annehmen - allerdings wird dies nicht direkt in der Kernanwendung umgesetzt sondern mittels eines Reportingwerkzeugs. Durch die APIv3 sollte es künftig möglich sein Anwendungen wie JasperReports anzukoppeln.

Version 1.8 - geplante Veröffentlichung Ende Q3 2017

Wesentliche Neuerungen dieser Version werden sein:

  • Passwort- bzw. Zugangsdatenverwaltung via Vault
  • neue, anpassbare Übersichtsseite
  • Erwartungsmanagement

Passwort- bzw. Zugangsdatenverwaltung via Vault

Ein integrierter Passwortmanager basierend auf Hashicorp's Vault wird eine der grossen Neuerungen in Version 1.8. Da die IDB Adapter viele verschiedene Informationsquellen durchsuchen, und Zugangsdaten zu u.a. diesen Systemen sicher abgelegt werden sollten, bietet sich der Einsatz von Vault an; ein Passwortverwaltungssystem ist aber in jedem Fall eine Bereicherung für den Anwender.

Übersichtsseite

Aktuell ist die Oberfläche der IDB sehr technisch und wenig ansprechend. Die tabellarischen Ansichten sind für viele Anwendungsfälle hilfreich und ausreichend, aber für eine schnelle Übersicht könnte ein "Dashboard"-ähnliche Ansicht besser geeignet sein. Im Raum steht die Überlegung das Anwender sich eigene Berichtselemente auf einer Startseite einrichten, um wiederkehrende Abfragen und Filter schnell im Zugriff zu haben, beispielsweise die zehn am längsten nicht gewarteten Maschinen.

Erwartungsmanagement

Erwartungsmanagement ist eine Funktion mit der wir Unterschiede zwischen dem Ist- und dem Soll-Zustand einer Ressourcen deutlicher herausstellen wollen. Über die Funktion Netzwerkscans mittels der API in die IDB zu speisen wird es dann möglich sein zu erkennen ob zum Beispiel Netzwerkports geöffnet sind die laut Soll-Definition in der IDB nicht offen sein sollten. Diese Informationen werden ebenfalls über die API abrufbar sein, so dass man hier an ein Monitoringsystem anbinden könnte um bei Soll/Ist Abweichungen alarmieren zu können. Wichtig: Die IDB sammelt Informationen und bereitet sie auf, Alarmierungen wie in diesen Fällen müssen daher über ein Monitoringsystem abgewickelt werden.

Version 2.0 - geplante Veröffentlichung Ende Q4 2017

Auf der Agenda für die Version 2.0 steht "Compliance" als grosses Thema. Wir haben bewusst Entwicklungskapazität zurückgehalten um den Funktionen aus 1.7 und 1.8 den letzten Feinschliff zu verpassen, oder an diesen Veränderungen basierend auf der Erprobung unserer Nutzer im Feld vorzunehmen.

Compliance

Die Kernanwendung speichert bereits aufgrund ihrer Architektur und eingesetzten Werkzeuge Änderungen an Objekten. Wie grossartig wäre es durch den Einsatz von WORM verhindern zu können das ein Objekt nachträglich manipuliert wird. Die Darstellung eines Zustand eines Systems zu einem bestimmten Zeitpunkt sollte in der IDB verlässlich sein in der Hinsicht das sie definitiv und unveränderbar ist.

Planung für die Adapter

Auf diese Adapter werden wir uns in 2017 konzentrieren:

idbiaas

Der idbiaas Adapter sammelt Informationen von diversen Infrastructure-as-a-Service Providern. Begonnen haben wir mit DigitalOcean sowie libvirt-basierenden Umgebungen. Diese werden als nächstes implementiert:

  • OpenStack
  • Amazon AWS
  • CloudStack

Ansible Adapter

Nachdem Ansible durchaus verbreitet im Einsatz ist, und einige unserer Kunden und Partner Interesse an einer Ansible-Unterstützung durch die IDB bekundet haben, kommen wir dem gerne nach und implementieren einen Ansible Adapter. Ein Teil der Arbeit daran wird sein die IDB zu erweitern damit sie als "external node classifier" / "inventory provider" für Ansible dienen kann.

OPSI Adapter

OPSI ist eine Lösung zur Verwaltung von Arbeitsplätzen und hat (als serverseitig Linux-basierte Software) einen starken Fokus auf Windows Desktops. Diese werden zur Zeit nicht optimal von der IDB unterstützt. Der idbad Adapter ist ein Versuch aus Windowsumgebungen mehr Informationen zu gewinnen. OPSI implementiert eine gute REST-API und hält nicht nur Informationen über die Maschinen vor, denn als Softwareverteilungssystem kann auch auf detaillierte Informationen zur eingesetzten Software zugegriffen werden.

PuppetDB Adapter

Die IDB entstand mit einem klaren Blick auf Puppet als primäre Informationsquelle. Daher ist die Informationsgewinnung aus einer PuppetDB aktuell nicht über einen Adapter umgesetzt, sondern als Teil der Kernanwendung. Um sicher zu gehen das alle Informationen über einen zentralen Punkt - die API - eingespielt werden wird die PuppetDB Anbindung künftig ebenfalls über einen eigenen Adapter umgesetzt.