În acest articol aș dori să povestesc despre cum ne-am schimbat abordarea în orchestration pe proiectul nostru de startup, de ce am făcut asta și ce probleme am rezolvat pe parcurs. Această articol nu poate pretinde unicitate, dar cred totuși că ar putea fi util cuiva, deoarece materialul a fost adunat de noi în procesul de soluționare a problemei.
Ce am avut și despre ce este vorba? Am avut un proiect de startup cu o istorie de aproximativ 2 ani în domeniul publicității. Proiectul a fost construit inițial ca un microserviciu, iar partea sa de server este scrisă în Symfony + puțin Laravel, Django și NodeJs nativ. Serviciile constau în principal din API-uri pentru clienții mobili (avem 3 în proiect) și SDK-ul nostru propriu pentru IOS (se integrează în aplicațiile clienților noștri), precum și interfețe web și diverse tablouri de bord pentru acești clienți. Toate serviciile au fost initial dockerizate și au funcționat sub orchestration docker-compose.
Adevărul este că docker-compose nu a fost folosit peste tot, ci doar în mediul local al dezvoltatorilor, în testare server și în interiorul pipeline-ului în timpul construirii și testării serviciilor. În mediul de producție a fost folosit Google Kubernetes Engine (GKE). De asemenea, configurarea GKE la începutul proiectului a fost realizată complet prin intermediul interfeței sale web, ceea ce a fost destul de rapid și, așa cum ni se părea atunci, convenabil. Automatizarea a fost realizată doar pentru procesul de construire a imaginilor docker pentru lansarea serviciilor în GKE.
