Ansible est-il un remplacement pour un outil de CI comme Hudson / Jenkins?
Récemment, dans notre société, nous avons décidé d'utiliser Ansible pour le déploiement et l'intégration continue. Mais lorsque j'ai commencé à utiliser Ansible, je ne trouvais pas de modules pour la construction de projets Java avec Maven, ni de modules pour l'exécution de tests JUnit ou de tests JMeter.
Donc, je suis dans un état douteux: il est possible que j'utilise Ansible de manière erronée.
Quand je regarde Jenkins, il peut faire des choses comme construire, exécuter des tests, déployer. La chose manquante dans Hudson est la création/suppression d'une instance dans des environnements cloud tels qu'AWS.
Donc, en général, à quelles fins devons-nous utiliser Ansible/Jenkins? Pour CI, dois-je utiliser une combinaison de Ansible et de Jenkins?
S'il vous plaît jeter un peu de lumière sur l'utilisation correcte de Ansible.
Premièrement, Jenkins et Hudson sont essentiellement le même projet. Je l'appellerai Jenkins ci-dessous. Voir Comment choisir entre Hudson et Jenkins? , Hudson vs Jenkins en 2012 , et Quelle est la différence la plus notable entre Jenkins et Hudson d'un point de vue utilisateur? pour plus.
Deuxièmement, Ansible n'est pas censé être un moteur d'intégration continue. Il (généralement) n’interroge pas les dépôts git et n’exécute que des constructions qui échouent de manière rationnelle.
Quand puis-je simplement utiliser Jenkins?
Si l'environnement de votre machine et le processus de déploiement sont très simples (tels que Heroku ou Iron configurés en dehors de votre équipe), Jenkins peut suffire. Vous pouvez écrire un script personnalisé qui effectue un déploiement en tant qu'étape de construction finale (ou en une étape chaînée).
Quand puis-je simplement utiliser Ansible?
Si vous avez seulement besoin de "déployer" sans avoir besoin de construire/tester, Ansible peut suffire. Par exemple, vous pouvez exécuter un déploiement à partir de la ligne de commande ou en utilisant Ansible Tower. C'est parfait pour les petits projets, les sites statiques, etc.
Comment travaillent-ils ensemble?
Une bonne combinaison consiste à utiliser Jenkins pour créer, tester et enregistrer des artefacts. Ajoutez une étape pour appeler Ansible ou Ansible Tower afin de gérer le processus de déploiement actuel. Cela permet à Ansible de gérer la configuration de la machine et permet à Jenkins de gérer le processus de CI.
Quelles sont les alternatives à Jenkins?
Je recommande fortement Thoughtworks Go (à ne pas confondre avec Go la langue) au lieu de Jenkins. Parmi les autres, citons CruiseControl, TravisCI et Integrity.
Ansible est juste une "boucle SSH glorifiée". CI ne concerne pas seulement le logiciel en cours d’exécution, mais également l’ensemble du processus de traitement des succès et des échecs, des destinataires des notifications et de la fusion des modifications dans le contrôle de version cible.
Si nous nous concentrons uniquement sur le logiciel, CI est un ordonnanceur réactif déclenché par des modifications de code et déclenchant une séquence typique d '"étapes" build-validate-release-deploy.
Donc, en ce qui concerne les logiciels, Ansible sans "sucre" supplémentaire est simplement une boîte à outils permettant d’exécuter des tâches, ce qui peut être ces étapes mêmes, mais ce n’est pas un CI. Le Ansible (sans tour) manque totalement de cette nature réactive.
Si vous voulez épouser Ansible avec CI, vous le pouvez.
La tour Ansible est un ordonnanceur très orienté Ansible, mais si vous avez besoin d'un logiciel CI, je pense que vous n'en avez pas nécessairement besoin. Toute application CI capable d'exécuter un script Shell serait capable de lancer des listes de lecture Ansible.
Cependant, contrairement à la tour Ansible, les outils de CI savent afficher des rapports de test sur tous les environnements de test, les notifications de déclencheurs, etc.
La tour Ansible peut avoir un sens dans un environnement complexe avec de nombreux groupes touchant le code Ansible ... La vérité est que je n'ai jamais vu une seule raison de payer pour cela. Mais si un gestionnaire a aimé l’interface Web, rien ne peut résister à la logique "mais d’autres l’utilisent".
Je soupçonne que le concept de tour Ansible était une réponse à une entreprise fantoche.
:)