Innovationstag bei KLM: Persistenz mit Docker-Containern

Am 3. Juli trafen sich KLM und Cargonauts in der KLM-Zentrale zu einem Innovationstag. Das Ziel war es, Wissen zu teilen und herauszufinden, wie man "Persistenz mit Docker-Containern" richtig umsetzt. Bei der Persistenz handelt es sich um Daten, die auch nach dem Neustart verfügbar sein sollen. Um die Sache noch komplexer zu machen, möchten Sie diese Daten in manchen Fällen auch auf mehreren Knoten gemeinsam nutzen. Beispiele hierfür sind ein Upload-Ordner, der gemeinsam genutzt wird, oder eine Datenbank. Unser Innovation Day Case konzentriert sich auf eine MySQL-Datenbank. Wir wollen herausfinden, wie wir MySQL-Daten zuverlässig und hochverfügbar hosten können.

Die Persistenz mit Docker-Containern stellt Sie vor die gleichen Probleme, wie wenn Sie sie nicht verwenden, aber mit mehr Optionen, aus denen Sie wählen können. Letztendlich lassen sich diese Optionen folgendermaßen zusammenfassen:

1. Lösen Sie das Problem nicht auf der Docker-Plattform. Lösen Sie es auf der Anwendungsebene, indem Sie eine verteilte Datenbank wie Cassandra verwenden.
2. Lösen Sie das Problem nicht auf der Docker-Plattform; verwenden Sie eine SAAS oder eine Technologie, die Ihrem Host einen hochverfügbaren Speicherplatz zur Verfügung stellt.
3. Reparieren Sie es auf der Docker-Plattform, damit Sie nicht an eine bestimmte Lösung gebunden sind. So können Sie überall bereitstellen, solange Docker verfügbar ist.

Da dies ein Innovationstag war und wir Container-Enthusiasten sind, konzentrierten wir uns auf die letzte Option. Um es noch deutlicher zu machen, beschlossen wir, diese beiden möglichen Lösungen für unser Problem zu untersuchen:

1. Versorgen Sie den Host mit einem hochverfügbaren verteilten Dateisystem mit GlusterFS. So können wir einen Container überall starten und ihn frei bewegen, da die Daten überall auf der Plattform verfügbar sind.
2. GlusterFS bietet aufgrund seiner verteilten Natur möglicherweise nicht die beste Leistung. Um also eine bessere Leistung zu erzielen, müssen wir die Daten auf dem Host verfügbar haben. Zu diesem Zweck haben wir Flocker untersucht.

Hinweis: Uns ist klar, dass diese beiden Lösungen nur einen Teil des Problems lösen, denn was passiert, wenn die Daten beschädigt werden? Um das zu lösen, brauchen wir immer noch eine Art Snapshot-/Backup-Lösung. Nachdem wir uns für einen Ansatz entschieden hatten, teilten wir die Gruppe in zwei Teams auf, wobei sich Team 1 auf GlusterFS und Team 2 auf Flocker konzentrierte. Wir werden in den nächsten Tagen über ihre Ergebnisse berichten. Bleiben Sie dran! Der Innovationstag verlief genau so, wie ein Innovationstag verlaufen sollte, mit viel Enthusiasmus, gefolgt von einigen Enttäuschungen, die zu kleinen Siegen und unbeantworteten Fragen führten, aber mit großartigen neuen Erkenntnissen und einer klaren Vision, worauf man seine Energie als nächstes konzentrieren sollte. Wir möchten KLM für die Ausrichtung des Innovationstages danken!