Comment garantir la cohérence entre les nouveaux microservices?

10

Mon organisation connaît une explosion de microservices. Nous n'avons actuellement aucun moyen formalisé d'amorcer de nouveaux projets. Je constate qu'une équipe viendra à moi avec un bogue dans son processus de déploiement ou de construction, et j'y consacrerai du temps seulement pour réaliser que je l'ai déjà résolu dans un autre projet. Il y a aussi beaucoup d'incohérence entre les projets que j'aimerais voir standardisés.

Les changements impliquent souvent un seul fichier (par exemple serverless.yml ou un Makefile), donc une solution impliquant des bibliothèques partagées, par exemple les sous-modules git, ne semble pas viable. Chaque projet aura son propre ensemble de configuration qui doit être maintenu, par exemple Dockerfiles ou serverless.yml, donc les solutions de gestion de configuration centralisée pour les machines virtuelles ne sont pas vraiment applicables.

Comment puis-je m'assurer que les nouveaux microservices sont conformes aux normes de l'organisation et incluent les corrections de bogues / fonctionnalités des projets existants d'une manière simple et intuitive pour les développeurs qui souhaitent démarrer de nouveaux projets? Quelles sont les meilleures pratiques pour résoudre ces problèmes?

Le flux de travail actuel que nous avons consiste à demander à la personne à côté de vous "de quel projet dois-je cloner pour l'utiliser comme modèle?" puis supprimez tous les éléments qui ne sont pas nécessaires pour ce projet.

user2640621
la source

Réponses:

5

J'ajouterai une réponse de ma solution jusqu'à présent, mais je suis toujours très intéressé à savoir comment d'autres organisations résolvent ce problème et les meilleures pratiques dont elles disposent.

Pour résoudre le problème de ne pas avoir de base cohérente pour créer des projets, mon idée est de créer un référentiel (référentiels?) De passe-partout / modèles et d'utiliser Cookiecutter comme outil pour échafauder de nouveaux microservices. De cette façon, chaque projet est créé à partir d'une base standard avec toutes les leçons que nous avons apprises en tant qu'organisation intégrée. Toutes les modifications que nous apportons peuvent être intégrées en amont dans le référentiel passe-partout. J'imagine que nous aurons des modèles pour les images Docker de Nodejs, les SPA sans serveur, les lambdas Python, etc.

Pour résoudre le problème des modifications apportées aux modèles propagés en aval de chaque projet, ma solution consiste à implémenter un processus où les propriétaires de microservices sont informés des modifications apportées au modèle et sont ensuite responsables de la propagation de ces modifications dans leur microservice.

user2640621
la source
C'est ce que nous faisons, en combinaison avec une simple application hello world qui illustre les meilleures pratiques à titre d'exemple concret.
Boycott SE pour Monica Cellio
4

Utilisez un système de gestion de configuration / déploiement automatisé. C'est pour cela qu'ils ont été conçus. Des choses comme Kubernetes, Puppet, Chef, Ansible et Salt Stack sont conçues à cet effet et peuvent être utilisées avec des modèles Golden Master, des scripts kickstart, des AMI Amazon ou simplement un conteneur Docker. Cela vous permet d'utiliser des modèles de base par défaut, puis de superposer des rôles supplémentaires. Cela garantira que les builds sont documentés complètement (sous forme de code) et qu'il sera rapide et facile à déployer en production, et sera déployé exactement de la même manière que ce qui a été conçu ou déployer des instances supplémentaires lorsque le besoin d'évolutivité ou de redondance se pose ou que quelque chose se casse. Les modifications / mises à jour peuvent également être intégrées de cette façon. Tout comme vous publiez des mises à jour logicielles, vous pouvez publier des mises à jour de votre configuration et le code de configuration peut être géré exactement comme votre code logiciel est géré - dans le même référentiel et avec les mêmes workflows. Et quand le moment de la mise à niveau arrive, il n'y a pas de mystère sur la façon dont la chose est construite, il suffit de regarder le script.

Une façon dont les systèmes de gestion de la configuration le font consiste à utiliser intensivement les modèles pour vos fichiers de configuration. Par exemple, il existe généralement de nombreuses lignes qui seront identiques ou similaires dans votre environnement. SaltStack utilise des modèles jinja et marionnette utilise des modèles Embedded Ruby . En utilisant AWS comme exemple, vous devrez peut-être définir une clé api, un rôle IAM, une région (ou sélectionner au hasard une région dans une liste de régions), un VPC, etc., qui sont tous identiques dans toutes les instances. Mais alors vous devez avoir vos fonctions et sorties uniques. Ou mieux encore, vous pouvez écrire un module marionnette ou une formule de sel qui définit les «contrats» et utiliser ces contrats (définitions api) pour les entrées et les sorties, vous évitant d'avoir à configurer vos microservices à deux ou trois endroits.

SaltStack, par exemple, a récemment organisé une réunion pour discuter de ce scénario particulier . De plus, SaltStack est également capable de gérer et de déployer des conteneurs Docker de manière native . (Puppet a également un module pour Docker ) De même, Ansible a des playbooks et des documents pour travailler avec des déploiements sans serveur et des conteneurs Docker .

De plus, si vous souhaitez continuer avec votre thème / paradigme sans serveur, Puppet , Ansible et saltstack sont tous sans maître ou prennent en charge un mode sans maître, si vous souhaitez continuer ce thème.

James Shewey
la source
J'ai ajouté quelques exemples et des éclaircissements à ma question. La gestion de la configuration n'aide pas vraiment car chaque projet est autonome dans sa configuration. Il n'y a aucun problème avec la migration vers la configuration en tant que code, il s'agit de maintenir la configuration en tant que code et l'étalement de la configuration avec lesquels vous pourriez vous retrouver si vous aviez 100 microservices chacun avec une configuration différente. Nous utilisons actuellement CI / CD avec des versions cohérentes, ce n'est donc pas un problème non plus.
user2640621
1
@ user2640621 - avez-vous déjà utilisé un système de gestion de configuration? La centralisation de «l'étalement de la configuration» vous aide à le gérer plus facilement et à partir d'un seul endroit (au lieu de 100 endroits différents). Bien que chaque projet puisse être autonome, il y a clairement un certain chevauchement lorsque vous posez des questions sur les modèles de déploiement. Il vaut peut-être la peine d'essayer quelques-uns dans une sanbox pour avoir une idée de leur fonctionnement avant de les radier ... Cela n'automatise pas seulement la gestion de vos fichiers de configuration - il fait beaucoup plus que cela.
James Shewey
1
J'ai utilisé SaltStack, Chef et Puppet, mais seulement pour gérer des machines virtuelles. Merci pour votre réponse, je vois certainement comment la gestion de la configuration peut être utilisée en dehors de la gestion des machines virtuelles maintenant.
user2640621
2
@ user2640621: S'ils sont tous différents: "Vous le codez, vous l'exécutez". Laissez les équipes gérer les opérations de leurs services. Laissez-les ressentir votre douleur.
Rétablir Monica - M. Schröder
3

Cette question est large, donc si ma réponse est un peu décalée, n'hésitez pas à ajouter du contexte et des exemples spécifiques afin d'avoir une meilleure compréhension.

L'utilisation d'une image de machine telle que l'AMI d'AWS vous permettrait de créer une image de base ou dorée, que vous pourriez ensuite maintenir et distribuer ou implémenter dans votre livraison continue. En utilisant cette architecture, vous vous assurez que chaque microservice est déployé sur un matériel cohérent avec une configuration identique afin que tous les problèmes que vous rencontrez soient liés à la configuration du microservice / application.

Vous pouvez renforcer cette immuabilité avec l'ajout d'outils de configuration tels qu'Ansible et Packer. En utilisant la gestion de la configuration, vous pouvez provisionner l'image de la machine avec tout ce que vous voulez (y compris l'application). Packer vous permettrait alors de prendre un instantané de cette image de machine et chaque déploiement serait identique.

En utilisant cet exemple, vous pouvez «créer» une AMI de base avec les packages, mises à jour et configurations corrects installés à l'aide d'Ansible et Packer. En outre, vous pouvez consulter «Ansible-Pull» pour terminer le déploiement en extrayant le code d'application, en apportant des modifications et en déployant le microservice au-dessus de cette image de base.

Cependant, le conseil le plus important que je puisse donner est de trouver une solution que toute l'organisation peut soutenir et maintenir. Cela vaut la peine d'essayer d'établir un SDLC qui résout votre ensemble particulier de problèmes, correspond à la culture et à l'attitude du leadership et embrasse les pratiques d'architecture moderne.

J'ai travaillé pour trois organisations et nous avons adopté trois approches très différentes.

Bonne chance!

Tchad
la source
Nous n'utilisons aucune solution basée sur une machine virtuelle (principalement sans serveur et un peu de Docker), mais je vais essayer d'appliquer mon problème à votre exemple. Quand quelqu'un veut créer une nouvelle image packer, par où commencer? Si chaque projet est autonome et qu'il n'y a pas de référentiel central pour la configuration du packer, qu'est-ce qu'ils utilisent comme base pour créer des images? L'une des différences est peut-être que les projets avec lesquels je travaille essaient d'être aussi autonomes que possible, sans aucune dépendance sur des services centralisés tels qu'Ansible où vous pouvez mettre à jour votre configuration pour tous les projets à la fois.
user2640621
Avec une architecture sans serveur et basée sur Docker, vous pouvez toujours appliquer ces principes fondamentaux. Une stratégie consiste à maintenir un fichier docker de base. Vous pouvez créer un fichier Docker basé sur centOS qui inclut une partie de la configuration que vous attendez de chaque microservice, puis chaque équipe peut extraire ce fichier Docker et créer son propre fichier Docker spécifique au microservice en plus de cela. Pour aider à la gestion des conteneurs et au déploiement continu, vous pouvez utiliser un outil comme Kubernetes.
Chad