In hierdie artikel wil ek praat oor hoe ons die benadering tot orkestrasie op ons beginprojek verander het, hoekom ons dit gedoen het en watter probleme ons langs die pad opgelos het. Hierdie artikel kan beswaarlik daarop aanspraak maak dat dit uniek is, maar ek dink steeds dat dit vir iemand nuttig kan wees, aangesien ons die materiaal met 'n ordentlike hoeveelheid moeite ingesamel het in die proses om die probleem op te los.
Wat het ons gehad en waaroor het ons gepraat? En ons het 'n beginprojek gehad met ongeveer 2 jaar se ontwikkelingsgeskiedenis uit die advertensieveld. Die projek is aanvanklik as 'n mikrodiens gebou, en die bedienergedeelte daarvan is geskryf in Symfony + 'n bietjie Laravel, Django en inheemse NodeJs. Die dienste is hoofsaaklik 'n API vir mobiele kliënte (daar is 3 van hulle in die projek) en ons eie SDK vir IOS (ingebou in ons kliënte se toepassings), sowel as webkoppelvlakke en verskeie kontroleskerms van dieselfde kliënte. Alle dienste is aanvanklik gedokteriseer en onder docker-compose uitgevoer.
True, docker-compose is nie oral gebruik nie, maar slegs in die plaaslike omgewing van ontwikkelaars, op 'n toetsbediener en binne die pyplyn wanneer dienste gebou en getoets word. Maar in die produksie-omgewing is Google Kubernetes Engine (GKE) gebruik. Boonop het ons GKE aan die begin van die projek geheel en al deur sy webkoppelvlak gekonfigureer, wat redelik vinnig was en, soos dit toe vir ons gelyk het, gerieflik was. Slegs die proses om docker-beelde te bou vir die bekendstelling van dienste in GKE is hier geoutomatiseer.