In diesem Artikel möchte ich darĂŒber berichten, wie wir unseren Ansatz zur Orchestrierung in unserem Startup-Projekt geĂ€ndert haben, warum wir das getan haben und welche Probleme wir dabei gelöst haben. Diese Artikel kann kaum den Anspruch auf Einzigartigkeit erheben, aber ich denke doch, dass er fĂŒr einige nĂŒtzlich sein könnte, da wĂ€hrend wir an der Lösung der Aufgabe gearbeitet haben, das Material mit erheblichem Aufwand von uns gesammelt wurde. Â
Was hatten wir und worum geht es ĂŒberhaupt? Wir hatten ein Startup-Projekt mit einer etwa 2-jĂ€hrigen Entwicklungsgeschichte im Bereich Werbung. Das Projekt wurde ursprĂŒnglich als Mikrodienst aufgebaut, und der Serverteil ist in Symfony + etwas Laravel, Django und nativem NodeJs geschrieben. Die Dienste dienen hauptsĂ€chlich als API fĂŒr mobile Clients (es gibt 3 in dem Projekt) und unser eigenes SDK fĂŒr iOS (wird in die Anwendungen unserer Kunden integriert), sowie Web-OberflĂ€chen und verschiedene Dashboards dieser Kunden. Alle Dienste wurden ursprĂŒnglich dockerisiert und liefen unter der Verwaltung von docker-compose.
Allerdings wurde docker-compose nicht ĂŒberall verwendet, sondern nur in der lokalen Umgebung der Entwickler, in der Test- Server und innerhalb der Pipeline bei der Erstellung und dem Testen der Dienste. In der Produktionsumgebung hingegen wurde Google Kubernetes Engine (GKE) verwendet. AuĂerdem haben wir die GKE-Konfiguration zu Beginn des Projekts vollstĂ€ndig ĂŒber seine Web-OberflĂ€che vorgenommen, was ziemlich schnell und, wie es uns damals schien, bequem war. Automatisiert war hier nur der Prozess der Erstellung von Docker-Images fĂŒr den Betrieb der Dienste in GKE.
