Ebben a cikkben arról szeretnék beszélni, hogy hogyan változtattuk meg az orkestrációs megközelítést a startup projektünkben, miért tettük ezt, és milyen problémákat oldottunk meg az út során. Ez a cikk valószínűleg nem igényel egyediségre való igényt, de mégis úgy gondolom, hogy hasznos lehet valakinek, mivel a feladat megoldása közben anyagokat gyűjtöttünk össze, meglehetősen komoly szorgalommal.
Mit is volt nektek, és miről van egyáltalán szó? Egy körülbelül 2 éves fejlesztéstörténettel rendelkező startup projektünk volt a hirdetési területen. A projekt kezdetben mikroszerviz alapúra készült, a szerveroldala Symfony + egy kis Laravel, Django és natív NodeJs használatával készült. A szolgáltatások főként API-kat jelentenek mobil ügyfelek számára (három a projektben) és a saját IOS SDK-nkhoz (beépül a vásárlóink alkalmazásaiba), valamint webes felületeket és különböző irányítópultokat a vásárlóink számára. Minden szolgáltatás kezdetben konténerizálva volt és a docker-compose irányítása alatt működött.
Igaz, hogy a docker-compose nem volt mindenhol használva, csak a fejlesztők helyi környezetében, a tesztelés alatt szerveren és a szolgáltatások építése és tesztelése közben a pipeline-ban. A produkciós környezetben viszont a Google Kubernetes Engine-t (GKE) használtuk. Ráadásul a projekt elején a GKE beállításait teljes mértékben a webes felületen végeztük el, ami viszonylag gyors volt és, ahogy akkoriban gondoltuk, kényelmes. Csak a docker képek építési folyamata volt automatizálva, hogy a szolgáltatásokat elindítsuk a GKE-ben.
