Dans cet article, je voudrais parler de la façon dont nous avons changé l'approche de l'orchestration sur notre projet de démarrage, pourquoi nous l'avons fait et quels problèmes nous avons résolus en cours de route. Cet article peut difficilement prétendre être unique, mais je pense quand même qu'il peut être utile à quelqu'un, car dans le processus de résolution du problème, nous avons collecté le matériel avec un grincement décent.
Qu'avions-nous et de quoi parlons-nous ? Et nous avions un projet de start-up avec une histoire de développement d'environ 2 ans dans le domaine de la publicité. Le projet a été construit à l'origine comme un microservice, et sa partie serveur a été écrite en Symfony + un peu de Laravel, Django et des NodeJs natifs. Les services sont essentiellement une API pour les clients mobiles (il y en a 3 dans le projet) et notre propre SDK pour IOS (intégré aux applications de nos clients), ainsi que des interfaces web et divers tableaux de bord de ces mêmes clients. Tous les services ont été initialement dockerisés et gérés par docker-compose.
Certes, docker-compose n'était pas utilisé partout, mais uniquement dans l'environnement local des développeurs, sur le serveur de test et à l'intérieur du pipeline lors de la construction et du test des services. Mais dans l'environnement de production, Google Kubernetes Engine (GKE) a été utilisé. De plus, nous avons fait la configuration de GKE au début du projet entièrement via son interface Web, qui était assez rapide et, comme cela nous semblait alors, pratique. Seul le processus de création d'images Docker pour exécuter des services dans GKE a été automatisé ici.