In dit artikel wil ik vertellen over hoe we onze benadering van orkestratie in ons startup-project hebben veranderd, waarom we dit deden en welke problemen we onderweg hebben opgelost. Deze artikel kan waarschijnlijk niet pretenderen uniek te zijn, maar ik denk wel dat het nuttig kan zijn voor iemand, aangezien we tijdens het oplossen van de taak materiaal hebben verzameld met behoorlijke inspanning.
Wat hadden we en waar hebben we het eigenlijk over? We hadden een startup-project met een geschatte ontwikkelingsgeschiedenis van ongeveer 2 jaar in de advertentiebranche. Het project was aanvankelijk gebouwd als een microservices-architectuur, met de serverkant geschreven in Symfony, plus een beetje Laravel, Django en native NodeJs. De services zijn voornamelijk API's voor mobiele klanten (die we in het project hebben met 3) en onze eigen SDK voor iOS (geïntegreerd in de apps van onze klanten), evenals webinterfaces en verschillende dashboards voor deze klanten. Alle services waren aanvankelijk gedockeriseerd en werkten onder docker-compose.
Echter, docker-compose werd niet overal gebruikt, maar alleen in de lokale omgeving van de ontwikkelaars, in de test- de server en binnen de pijplijn tijdens het bouwen en testen van de services. In de productieomgeving gebruikten we Google Kubernetes Engine (GKE). We hebben de GKE-configuratie aan het begin van het project helemaal via de webinterface gedaan, wat vrij snel ging en, zoals we toen dachten, handig was. Alleen het bouwen van docker-images voor het starten van de services in GKE was geautomatiseerd.
