Au dos de ma réponse à la question: Comment DevOps peut-il aider à améliorer les procédures d'engagement de logiciels? Tensibai avait la question:
Qu'est-ce qui nécessiterait Capistrano sur une marionnette ou un chef?
Ma réponse a été de publier un lien vers l'article de Noah Gibbs "Avons-nous besoin à la fois de Capistrano et de Chef?" . Personnellement, je partage toujours l'opinion de Noah selon laquelle il est le plus approprié de:
- utiliser un outil de déploiement spécialisé tel que Capistrano pour les déploiements.
- utilisez un outil de gestion de configuration spécialisé tel que Chef pour la gestion de la configuration.
L'approche fondamentale que chaque type d'outil utilise pour accomplir sa tâche est très différente:
Les outils de gestion de la configuration - concernent la création et le maintien de l'état souhaité d'un système, ils sont intrinsèquement idempotents par nature. Des exemples d'outils de gestion de configuration sont Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .
Les outils de déploiement - concernent la livraison de versions de logiciel dans un environnement d'hébergement, ils fournissent des fonctionnalités pour maintenir plusieurs versions du logiciel sur plusieurs machines et gérer la version "actuelle", ils sont par nature impératifs. Des exemples d'outils de déploiement sont Capistrano , Octopus Deploy , Deployer et Command.io .
Je crois que les outils de gestion de la configuration peuvent faire le travail des outils de déploiement et dans le cas de l' infrastructure immuable, ils sont l'outil le plus approprié pour le travail, car les versions logicielles sur la cible n'ont pas besoin d'être maintenues.
Question: Les outils de gestion de la configuration tels que Chef, Ansible et Puppet sont-ils arrivés à maturité au point de pouvoir remplir à la fois les modèles idempotents et impératifs?
la source
Réponses:
Dans un tel contexte, les conseils typiques devraient être immédiatement applicables: utilisez le bon outil pour le travail.
Mais vous ne pouvez pas non plus ignorer de nos jours la tendance presque virulente des outils logiciels à étendre les fonctionnalités à des domaines plus ou moins liés et à devenir des ensembles d' outils pour diverses raisons: fonctionnalité (s) intéressante (s), extension de la clientèle, augmentation des revenus, etc.
Par exemple, de nombreux outils de gestion de fichiers incluent des fonctionnalités de visualisation d'images et de nombreux outils de traitement d'images incluent des fonctionnalités de gestion de fichiers. Vous pouvez déplacer des fichiers et visualiser des images avec l'un ou l'autre des outils, souvent aussi bien.
Pour cette raison, il est tout à fait possible d'avoir des parties entières du processus de développement logiciel couvertes / chevauchées par plusieurs outils (ensembles) même si leur caractéristique / capacité principale diffère.
Donc, cela se résume vraiment à la fonctionnalité exacte que vous souhaitez atteindre dans votre processus particulier et à la façon dont un outil ou l'autre fait le travail dans votre contexte . Subjectivité / préférences / commodité incluses.
Rendre cette question principalement basée sur l'opinion;)
la source
Les outils de gestion de la configuration sont utilisés pour mettre un système dans un état connu. Les outils de déploiement déploient de nouveaux fichiers de programme et données de programme sur un système. À la fin de la journée, les deux types d'outils font une combinaison de:
Les outils de gestion de la configuration ont des langages déclaratifs qui spécifient l'état du système. Les outils de déploiement ont des langages impératifs qui indiquent au système de faire les choses. Une personne DevOps doit faire les deux.
En utilisant l'outil de déploiement Capistrano, il est maladroit d'utiliser sa langue pour dire au système de s'assurer que le serveur Web est actif. Vous devez émettre une commande pour redémarrer le serveur Web et une autre pour vérifier si le serveur Web est en marche. Il est difficile de mettre le serveur Web dans un état connu.
À l'aide de l'outil de gestion de configuration Ansible, il est maladroit de redémarrer un serveur Web. La langue vous permet de dire au serveur Web d'être "opérationnel", mais si vous souhaitez spécifiquement qu'il soit redémarré, vous devez définir son état sur "redémarré". Mais il n'y a aucun moyen facile de vérifier si le serveur Web a été redémarré. C'est un coup de pouce dans Ansible pour permettre des opérations ponctuelles.
Certaines personnes préfèrent effectuer les deux types de travaux avec un seul outil et travailler autour des bords rugueux. D'autres préfèrent avoir deux outils pour faire presque la même chose, mais sans bords rugueux. Pour répondre à la question, la «pertinence» est une question de goût. Cette réponse explique pourquoi.
la source
no easy way to check if the web server has been restarteddans laquelle elle pourrait être vérifiée en enregistrant une variable?TL; DR : Utilisez simplement Ansbile, c'est à la fois un outil de configuration et de déploiement :)
Il existe plusieurs types de déploiement:
Basé sur l' application (fichiers, packages d'archives)
Basé sur des conteneurs (inclut les VM, Habitat, LXC, Docker)
Basé sur les fonctions (Micro services / Lambdas / Fonctions)
Je suppose que dans ce cas, nous ne parlons que des mises à jour d'application sur le (s) serveur (s).
Pour le déploiement, vous devez avoir deux choses:
Maintenant, pour (1), vous pouvez utiliser plusieurs stratégies:
Pour le (2), vous pouvez utiliser:
Ainsi, bien que les outils de déploiement soient un moyen de faire le déploiement tout en un, ils ne sont pas toujours la meilleure stratégie. Parfois, vous souhaitez utiliser une combinaison de ces méthodes pour le déploiement. Vous utilisez probablement déjà des gestionnaires de packages au moins sur vos serveurs. Vous exécutez très probablement des outils de configuration de toute façon. Le problème avec certains des outils de configuration était une bonne orchestration entre plusieurs serveurs, mais maintenant même Chef et Puppet peuvent très bien le faire. Ansible a toujours été bon dans ce domaine.
Par expérience personnelle , j'ai utilisé toutes les combinaisons, mais actuellement nous utilisons Capistrano pour le déploiement et la synchronisation Ansible pour la gestion de la configuration, et VCS et les référentiels de packages pour les transferts de fichiers, mais il y a des problèmes avec Capistrano et nous prévoyons de nous en éloigner pour unifiez sur Ansible pour le déploiement, la maintenance et la gestion de la configuration.
la source
Le déploiement d'applications est difficile à cerner car il comporte de nombreux sous-problèmes. Les systèmes de gestion de configuration sont excellents pour modéliser des tâches qui sont convergentes et fonctionnent avec "quel est l'état souhaité du système". Dans le contexte du déploiement d'applications, cela est idéal pour des choses comme le déploiement de bits sur une machine, la gestion des fichiers de configuration et la configuration des services système. Ce qui est extrêmement mauvais pour les choses qui sont intrinsèquement procédurales, notamment les migrations de bases de données et les redémarrages de services. J'essaie généralement de mettre la logique convergente dans Chef et de laisser un outil procédural externe (généralement Fabric dans mon cas) gérer les quelques bits restants ainsi que séquencer les convergences réelles.
Donc, fondamentalement, vous devriez utiliser les deux pour les pièces pour lesquelles ils sont les meilleurs.
la source
Pour les logiciels et le déploiement de code sur un serveur existant ou à l'intérieur d'un conteneur Docker, la réponse est relativement simple - Non, vous n'avez pas besoin des deux, mais vous voudrez peut-être les deux si un autre outil ou utilitaire ajoute de la valeur et est le bon outil pour le travail , cependant, les choses se compliquent lorsque vous déployez des serveurs et des systèmes d'exploitation.
Une valeur ajoutée d'une mentalité DevOps consiste à traiter l'infrastructure comme du code et à déployer ou détruire fréquemment des machines virtuelles ou même du métal nu dans un environnement hautement élastique. Votre système de gestion de la configuration ne peut pas facilement démarrer et redémarrer votre serveur pour vous et ne peut pas gérer les référentiels, les packages et les mises à jour / correctifs pour vous pendant et après les déploiements ou, dans certains cas, les licences et les droits.
Pour Amazon Web Services, cela est plutôt facile à gérer par les API, mais pour ceux d'entre nous qui doivent gérer nos propres centres de données, ce n'est pas une option. Pour cette raison, le projet Foreman (et Red Hat qui le rebaptise ) a jugé nécessaire de regrouper Katello , Candlepin et un gestionnaire de configuration tel qu'Ansible, Foreman ou Puppet ensemble lors du déploiement du scénario Katello .
Ainsi, bien que vous puissiez vous en sortir avec les outils de gestion de la configuration pour les déploiements de code logiciel du côté Dev de la maison, du côté Ops, il existe plusieurs cas où la réponse est un «non» retentissant, les outils de gestion de la configuration ne sont pas approprié à utiliser comme outils de déploiement "Cela nécessiterait une réinvention sérieuse de la roue et n'est pas pratique. Vous devez à la place utiliser vos outils de gestion de configuration pour lancer des déploiements dans un autre outil.
la source