V tem članku bi rad govoril o tem, kako smo spremenili pristop k orkestraciji pri našem zagonskem projektu, zakaj smo to storili in katere težave smo rešili na tej poti. Ta članek težko trdi, da je edinstven, vendar vseeno menim, da je lahko nekomu koristen, saj smo v procesu reševanja problema gradivo zbrali z dostojno količino truda.
Kaj smo imeli in o čem smo se pogovarjali? In imeli smo startup projekt s približno 2 leti zgodovine razvoja na področju oglaševanja. Projekt je bil sprva zgrajen kot mikrostoritev, njegov strežniški del pa je bil napisan v Symfony + malo Laravel, Django in izvorni NodeJs. Storitve so v glavnem API za mobilne odjemalce (v projektu so 3) in lasten SDK za IOS (vgrajen v aplikacije naših strank), pa tudi spletne vmesnike in različne nadzorne plošče teh istih strank. Vse storitve so bile sprva dockerizirane in so delovale pod docker-compose.
Res je, da docker-compose ni bil uporabljen povsod, ampak le v lokalnem okolju razvijalcev, na testnem strežniku in znotraj cevovoda pri gradnji in testiranju storitev. Toda v proizvodnem okolju je bil uporabljen Google Kubernetes Engine (GKE). Poleg tega smo na začetku projekta GKE v celoti konfigurirali prek njegovega spletnega vmesnika, kar je bilo precej hitro in, kot se nam je takrat zdelo, priročno. Tu je bil avtomatiziran samo postopek gradnje slik dockerja za zagon storitev v GKE.