Այս հոդվածում ես կցանկանայի խոսել այն մասին, թե ինչպես ենք մենք փոխել մեր մոտեցումը օրկեստրացիային մեր ստարտափ նախագծում, ինչու ենք այս որոշումը կայացրել և quais խնդիրներ ենք լուծել ճանապարհին։ Այս հոդվածը, հավանաբար, չի կարող दावा անել բացառիկության վրա, բայց ես դեռ կարծում եմ, որ այն կարող է օգտակար լինել, քանի որ խնդիրները լուծելիս մենք նյութերն հավաքել ենք բավականին նորարարությամբ։
Ի՞նչ ունեինք և ի՞նչ է խոսքը։ Մենք ունեինք ստարտափ նախագիծ, որը մոտավորապես 2 տարվա զարգացման պատմություն ունի գովազդային ոլորտում։ Նախագիծը սկզբում կառուցվել է որպես միկրոհ hizmeto ազդակ, իսկ նրա սերվերային մասը գրվել է Symfony + մի փոքր Laravel, Django և բնօրինակ NodeJs։ Խ serviciերը հիմնականում ներկայացնում են API մեր (3) շարժական հաճախորդների համար և մեր սեփական SDK-ի համար IOS-ի համար (ընթանում է մեր հաճախորդների հավելվածներում), ինչպես նաև վեբ ինտերֆեյսներ և տարբեր վահանակներ։ Բոլոր ծառայությունները սկզբում եղել են Docker-ացված և աշխատել են docker-compose-ի ղեկավարությամբ։
Իրականում, docker-compose-ը օգտագործվել է ոչ Everywhere, այլ միայն տեղական միջավայրում ծրագրավորողների, թեստավորման սերվերի և ներսում pipeline-ի ընթացքում ծառայությունների հավաքման և թեստավորման։ Իսկ production միջավայրում օգտագործվել է Google Kubernetes Engine (GKE): Յուրաքանչյուր GKE-ի կարգադրում նախագծի սկզբում կատարեցինք ամբողջությամբ նրա վեբ-համակարգի միջոցով, ինչը շատ արագ և, ինչպես մեզ թվաց, հարմար էր։ Այստեղ ավտոմատացված էր միայն ծառայությունների GKE-ում գործարկման համար docker պատկերների հավաքման գործընթացը։
