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.
