У гэтым артыкуле я хацеў бы расказаць пра тое, як мы мянялі падыход да аркестрацыі на нашым стартап-праекце, навошта мы гэта рабілі і якія праблемы па дарозе вырашалі. Прэтэндаваць на ўнікальнасць гэты артыкул ці наўрад можа, але ўсё ж думаю, што ён можа быць камусьці карысная, бо падчас рашэнні задачы матэрыял збіраўся намі з прыстойным скрыпам.
Што мы мелі і пра што ўвогуле гаворка? А мелі мы стартап-праект з прыкладна 2-гадовай гісторыяй распрацоўкі з advertisement вобласці. Праект першапачаткова будаваўся як мікрасэрвісны, і серверная яго частка напісана на Symfony + крыху Laravel, Django і натыўнага NodeJs. Сэрвісы ўяўляюць з сябе ў асноўным API для мабільных кліентаў (іх у праекце 3) і нашага ўласнага SDK для IOS (убудоўваецца ў прыкладанні нашых кастамер), а таксама вэб-інтэрфейсы і розныя дашборды гэтых самых кастамер. Усе сэрвісы былі першапачаткова дакерызаваны і працавалі пад кіраваннем docker-compose.
Праўда, docker-compose выкарыстоўваўся не ўсюды, а толькі ў лакальным асяроддзі ў распрацоўнікаў, на тэставым серверы і ўсярэдзіне pipeline пры зборцы і тэставанні сэрвісаў. А вось у production асяроддзі выкарыстоўваўся Google Kubernetes Engine (GKE). Прычым наладу GKE на старце праекту мы рабілі цалкам праз яго web-інтэрфейс, што было даволі хутка і, як нам тады здавалася, зручна. Аўтаматызаваны тут быў толькі працэс зборкі docker images для запуску сэрвісаў у GKE.