In dit artikel wil ik het hebben over hoe we de benadering van orkestratie bij ons startup-project hebben veranderd, waarom we het hebben gedaan en welke problemen we onderweg hebben opgelost. Dit artikel kan nauwelijks beweren uniek te zijn, maar toch denk ik dat het voor iemand nuttig kan zijn, aangezien het materiaal tijdens het oplossen van het probleem door ons met een behoorlijk gekraak is verzameld.
Wat hadden we en waar hebben we het over? En we hadden een opstartproject met een ontwikkelingsgeschiedenis van ongeveer 2 jaar op het gebied van reclame. Het project is oorspronkelijk gebouwd als een microservice en het servergedeelte is geschreven in Symfony + een beetje Laravel, Django en native NodeJs. De services zijn in feite een API voor mobiele clients (er zijn er 3 in het project) en onze eigen SDK voor IOS (ingebouwd in de applicaties van onze klanten), evenals webinterfaces en verschillende dashboards van dezelfde klanten. Alle services waren aanvankelijk gedockeriseerd en werden beheerd door docker-compose.
Toegegeven, docker-compose werd niet overal gebruikt, maar alleen in de lokale omgeving van ontwikkelaars, op de testserver en in de pijplijn bij het bouwen en testen van services. Maar in de productieomgeving werd de Google Kubernetes Engine (GKE) gebruikt. Bovendien hebben we de GKE-configuratie aan het begin van het project volledig via de webinterface gedaan, wat vrij snel was en, zoals het ons toen leek, handig. Alleen het proces van het bouwen van docker-images om services in GKE uit te voeren, is hier geautomatiseerd.