Dans cet article, je voudrais vous parler de la manière dont nous avons modifié notre approche de l'orchestration dans notre projet startup, pourquoi nous l'avons fait et quels problèmes nous avons résolus en cours de route. Cette article ne prétend probablement pas à l'unicité, mais je pense qu'il peut être utile à certains, car nous avons rassemblé du matériel avec un effort considérable pour résoudre ce problème.
Qu'avions-nous et de quoi s'agit-il exactement ? Nous avions un projet startup avec environ 2 ans d'historique de développement dans le domaine de la publicité. Le projet était initialement conçu comme un système de microservices, et sa partie serveur était écrite en Symfony, avec un peu de Laravel, Django et NodeJs natif. Les services représentent essentiellement des API pour nos clients mobiles (il y en a 3 dans le projet) et notre propre SDK pour iOS (intégré dans les applications de nos clients), ainsi que des interfaces web et divers tableaux de bord pour ces mêmes clients. Tous les services étaient initialement conteneurisés avec Docker et fonctionnaient sous la gestion de docker-compose.
Cependant, docker-compose n'était pas utilisé partout, mais seulement dans l'environnement local des développeurs, sur les serveurs de test le serveur et à l'intérieur du pipeline lors de la construction et des tests des services. En production, nous utilisions Google Kubernetes Engine (GKE). D'ailleurs, la configuration de GKE au début du projet a été faite entièrement via son interface web, ce qui était assez rapide et, à l'époque, nous semblait pratique. Seul le processus de construction des images Docker pour le lancement des services dans GKE était automatisé.
