Les outils de gestion de la configuration sont-ils appropriés pour être utilisés comme outils de déploiement?

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?

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;)

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:

• Déterminez l'état actuel du système.
• Transférez les fichiers vers le système.
• Ajouter ou modifier des données persistantes (par exemple, fichiers de configuration, données de base de données, paramètres de registre)
• Démarrez ou redémarrez des programmes.

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.

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:

1. Les fichiers ou packages corrects doivent être déplacés vers le serveur.
2. Les états de configuration et de service doivent changer.

Maintenant, pour (1), vous pouvez utiliser plusieurs stratégies:

• Référentiels d'artefacts / synchronisation
• Référentiels de packages / gestionnaires de packages
• Système de contrôle de version / mise à jour + compilation (en option)
• Protocoles de transfert de fichiers (scp, rsync, ftp)
• Outils de déploiement

Pour le (2), vous pouvez utiliser:

• Outils de gestion de la configuration
• Outils de déploiement

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.

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.

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.