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.
Dit is waar dat docker-compose nie oral gebruik is nie, maar slegs in die plaaslike omgewing van die ontwikkelaars, tydens die toets. bediener en binne die pyplyn wanneer dienste gebou en getoets word. In die produksiemgewing het ons Google Kubernetes Engine (GKE) gebruik. Boonop het ons GKE volledig deur sy webkoppelvlak aan die begin van die projek gekonfigureer, wat redelik vinnig en, soos ons destyds gedink het, gerieflik was. Die enigste outomatiese proses was die bou van Docker-beelde om dienste in GKE te loods.
