V tomto článku bych chtěl hovořit o tom, jak jsme změnili přístup k orchestraci v našem startupovém projektu, proč jsme to dělali a jaké problémy jsme na cestě řešili. Tato článková pozice na unikátnost rozhodně nemůže, ale myslím si, že by mohla být někomu užitečná, protože materiál jsme během řešení úkolu shromažďovali s ohledem na naše zkušenosti.
Co jsme měli a o čem je vůbec řeč? Měli jsme startupový projekt s přibližně dvouletou historií vývoje v oblasti reklamy. Projekt byl původně navržen jako mikroservisní, a jeho serverová část byla napsána na Symfony + trochu Laravel, Django a nativním NodeJs. Služby představují především API pro mobilní klienty (je jich v projektu 3) a naše vlastní SDK pro IOS (integrované do aplikací našich zákazníků), stejně jako webové rozhraní a různé panely pro naše zákazníky. Všechny služby byly původně dockerizovány a pracovaly pod správou docker-compose.
Pravda, docker-compose se používaly pouze v místním prostředí vývojářů, na testovacím serveru a v rámci pipeline při sestavování a testování služeb. V produkčním prostředí se však používal Google Kubernetes Engine (GKE). Přičemž nastavení GKE na začátku projektu jsme prováděli výhradně prostřednictvím jeho webového rozhraní, což bylo poměrně rychlé a, jak se nám tehdy zdálo, pohodlné. Automatizován byl pouze proces vytváření dockerových obrazů pro spuštění služeb v GKE.
