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.
Il est vrai que docker-compose n'était pas utilisé partout, mais seulement dans l'environnement local des développeurs, sur le serveur de test. serveur et au sein du pipeline lors de la construction et du test des services. En production, nous avons utilisé Google Kubernetes Engine (GKE). De plus, nous avons configuré GKE entiÚrement via son interface web au début du projet, ce qui s'est avéré rapide et, à l'époque, pratique. Le seul processus automatisé a été la création d'images Docker pour le déploiement des services sur GKE.
