V tem članku bi rad delil, kako smo spremenili pristop k orkestraciji v našem zagonskem projektu, zakaj smo to storili in katere težave smo reševali po poti. Ta članek verjetno ne more trditi, da je edinstven, vendar mislim, da je lahko komu koristno, saj smo med reševanjem naloge zbrali gradivo z dovolj truda.
Kaj smo imeli in o čem sploh govorimo? Imeli smo zagonski projekt s približno 2-letno zgodovino razvoja na področju oglaševanja. Projekt je bil sprva zasnovan kot mikroservisni, in njegova strežniška komponenta je bila napisana v Symfony + malo Laravel, Django in nativnega NodeJs. Storitve predstavljajo predvsem API-je za mobilne stranke (v projektu so 3) in naš lastni SDK za IOS (vgradi se v aplikacije naših strank), pa tudi spletne vmesnike in različne nadzorne plošče teh strank. Vse storitve so bile sprva dockerizirane in obratovale pod upravljanjem docker-compose.
Res je, da se docker-compose ni uporabljal povsod, temveč samo v lokalnem okolju razvijalcev, v testnem strežnikom in znotraj pipeline-a pri gradnji in testiranju storitev. V produkcijskem okolju pa smo uporabljali Google Kubernetes Engine (GKE). Pri čemer smo nastavitev GKE ob pričetku projekta izvedli popolnoma preko njegovega spletnega vmesnika, kar je bilo precej hitro in, kot se nam je takrat zdelo, priročno. Samo proces gradnje docker slik za zagon storitev v GKE je bil avtomatiziran.
