Nous rencontrons un argument intéressant et tombons dans deux camps. Je suis intéressé par des problèmes particuliers avec une idée ou des problèmes que nous pourrions manquer. Vraiment, tout ce qui peut nous aider à prendre une décision ou à souligner des choses que nous ne tenons pas compte. Je sais que cela contourne un peu la règle du "sans opinion" mais j'espère que c'est toujours une question acceptable. Désolé pour la longueur aussi, il y a pas mal de nuances.
1) Un côté (le mien - je ne suis pas sans parti pris) trouve le modèle de serveur immuable très intéressant pour les systèmes cloud. À cette fin, nous avons prototypé le déplacement de tous les composants de notre infrastructure dans Docker. Nos applications personnalisées se construisent via Jenkins directement dans des images Docker qui se déploient dans un registre Docker local. Ensuite, nous avons créé un grand ensemble de rôles Ansible et un playbook capable d'atteindre un serveur vide, installons Docker, puis demandons à Docker d'installer tous les conteneurs selon les besoins. Au bout de quelques minutes, l'application entière et toute son infrastructure de support sont câblées et fonctionnent - journalisation, surveillance, création / population de base de données, etc. application. Notre plan pour étendre cela serait de créer de nouveaux Playbooks pour construire de nouveaux serveurs AWS à partir d'une AMI de base de confiance (probablement une image très nue), de déployer des déploiements de l'application de production pour gérer la gestion de la configuration et les versions et, généralement, ne jamais modifier à nouveau les serveurs - faites-les à nouveau. Je ne souhaite pas que ce que je décris fonctionne dans la pratique - juste si c'est un modèle raisonnable.
2) L'autre camp veut utiliser Puppet pour gérer la gestion de la configuration, Ansible pour déployer nos applications personnalisées qui sont des tarballs générés à partir de notre processus de construction, Foreman pour gérer le déclenchement et la gestion du processus dans son ensemble et Katello pour faire une certaine quantité de base gestion des images. Les versions impliqueraient la modification de la configuration de Puppet selon les besoins et le déploiement par Ansible de composants mis à jour avec une certaine coordination de Foreman. Les serveurs seraient construits assez rapidement si nous en avions besoin de nouveaux, mais l'intention n'est pas de les rendre jetables dans le cadre du processus standard. C'est plus proche du modèle de serveur phoenix mais avec une longue durée de vie.
Donc ma question se résume vraiment à ceci: le modèle de serveur immuable avec les outils tels que je les ai décrits ci-dessus est-il aussi réaliste qu'il y paraît? J'adore l'idée que notre processus de transfert peut littéralement créer un clone entier des applications en direct, laissez QA le marteler, puis retournez simplement le stockage de la base de données et certains paramètres DNS pour le faire vivre.
Ou le modèle de serveur immuable échoue-t-il dans la pratique? Nous avons beaucoup d'expérience avec les environnements AWS et cloud, donc ce n'est pas vraiment le problème - plus une question de comment obtenir une application raisonnablement sophistiquée déployée de manière fiable à l'avenir. Ceci est particulièrement intéressant car nous publions assez fréquemment.
Nous avons Ansible qui fait la plupart des choses nécessaires, sauf la création de serveurs EC2 pour nous et ce n'est pas difficile. J'ai du mal à comprendre pourquoi vous avez réellement besoin de marionnettes / contremaître / Katello dans ce modèle. Docker est beaucoup plus propre et plus simple que les scripts de déploiement personnalisés dans n'importe quel outil que je peux dire. Ansible semble beaucoup plus simple à utiliser que Puppet lorsque vous cessez de vous inquiéter de devoir les configurer in situ et de les reconstruire simplement avec la nouvelle configuration. Je suis un fan du principal KISS - en particulier dans l'automatisation où Murphy's Law est endémique. Moins il y a de machines, mieux c'est l'OMI.
Toute réflexion / commentaire ou suggestion sur l'approche serait grandement apprécié!