Est-ce une bonne idée de faire fonctionner ensemble Ansible et Rundeck, ou utiliser l'un ou l'autre suffit?
Récemment, je regarde Ansible et je veux l'utiliser dans des projets. Et il existe également un autre outil que Rundeck peut être utilisé pour effectuer toutes sortes de travaux d'exploitation. J'ai de l'expérience avec aucun de ces outils et voici ma compréhension actuelle à leur sujet:
Points similaires
Les deux outils sont sans agent et utilisent SSH pour exécuter des commandes sur des serveurs distants
Le concept principal de Rundeck est Node, le même que l'inventaire d'Ansible, l'idée clé est de définir/gérer/grouper les serveurs cibles
- Rundeck peut exécuter des commandes ad hoc sur les nœuds sélectionnés, Ansible peut également le faire très facilement.
- Rundeck peut définir le flux de travail et effectuer l'exécution sur les nœuds sélectionnés, cela peut être fait avec Ansible en écrivant un playbook
- Rundeck peut être intégré à l'outil CI comme Jenkins pour faire le travail de déploiement, nous pouvons également définir un travail Jenkins pour exécuter ansible-playbook pour faire le travail de déploiement
Différents points
Rundeck a le concept de Job, ce que Ansible ne fait pas
Rundeck a Job Scheduler, qu'Ansible ne peut atteindre que avec d'autres outils comme les tâches Jenkins ou Cron
Rundeck a l'interface utilisateur Web par défaut gratuitement, mais vous devez payer pour Ansible Tower
Il semble qu'Ansible et Rundeck puissent être utilisés pour effectuer des travaux de configuration/gestion/déploiement, peut-être d'une manière différente. Mes questions sont donc:
- Ces deux outils sont-ils complémentaires ou sont-ils conçus pour des finalités différentes? S'il s'agit d'outils complémentaires, pourquoi Ansibl est-il uniquement comparé à des outils comme Chef/Puppet/Slat mais pas avec Rundeck? S'ils ne sont pas pourquoi ils ont autant de fonctionnalités similaires?
- Nous utilisons déjà Jenkins pour CI, pour construire un pipeline de livraison continue, quel outil (Ansible/Rundeck) est une meilleure idée à utiliser pour faire le déploiement?
- S'ils peuvent être utilisés ensemble, quelle est la meilleure pratique?
Toutes les suggestions et le partage d'expérience sont grandement appréciés.
TL; DR - étant donné votre environnement de Jenkins pour CI/CD, je recommanderais d'utiliser simplement Ansible.
Vous avez remarqué qu'il existe un croisement important entre Ansible et Rundeck, il est donc probablement préférable de se concentrer sur où se concentre chaque produit, son style et son utilisation.
Focus
Je crois que l'objectif de Rundeck est de permettre aux administrateurs système de créer un portail en libre-service (basé sur le Web) accessible aux autres administrateurs système et, potentiellement, aux personnes moins "techniques"/administrateurs système. Le site Web de Rundeck indique " Transformez vos procédures d'exploitation en tâches de libre-service. Donnez en toute sécurité aux autres le contrôle et la visibilité dont ils ont besoin. ". Rundeck a également l'impression d'avoir une vision plus "centralisée" du monde: vous chargez les travaux dans une base de données et c'est là qu'ils vivent.
Pour moi, Ansible est pour les devops - donc construire et automatiser des déploiements d'applications (auto-construites) de manière à ce qu'elles soient hautement reproductibles. Je dirais qu'Ansible est plus axé sur les sociétés de développement de logiciels qui construisent leurs propres produits: les `` playbooks '' d'Ansible sont des fichiers texte, donc normalement stockés dans le contrôle de source et normalement à côté de l'application que les playbooks déploieront.
Focus sur la création d'emplois
Avec Rundeck, vous créez généralement des emplois via l'interface utilisateur Web.
Avec Ansible, vous créez des tâches/playbooks dans des fichiers via un éditeur de texte.
Opération/Tâche/Style de travail
Rundeck par défaut est impératif - vous écrivez des scripts qui sont exécutés (via SSH).
Ansible est à la fois impératif (c'est-à-dire exécuter des instructions bash) mais également déclaratif, donc dans certains cas, par exemple, en démarrant Apache, vous pouvez utiliser la tâche service pour vous assurer qu'elle est en cours d'exécution. Ceci est plus proche des autres outils de gestion de configuration comme Puppet et Chef.
tâches/scripts complexes
Rundeck a la capacité d'exécuter un autre travail en définissant une étape dans le flux de travail du travail, mais d'après l'expérience, cela ressemble à un ajout plus qu'une fonctionnalité sérieuse de haut niveau.
Ansible est conçu pour créer des opérations complexes; exécuter/y compris/etc sont des fonctionnalités de haut niveau.
Comment ça marche
Rundeck est une application serveur. Si vous souhaitez exécuter des travaux depuis un autre endroit (comme CI), vous devrez soit appeler la cli, soit effectuer un appel API.
Straight Ansible est en ligne de commande.
Proviso
En raison du cross-over et de la flexibilité globale de Rundeck et Ansible, vous pouvez réaliser tout ce qui précède dans chacun. Vous pouvez obtenir un contrôle de version de vos travaux Rundeck en les exportant vers YAML ou XML et en les archivant dans le contrôle de code source. Vous pouvez obtenir une interface utilisateur Web dans Ansible en utilisant Tower. etc. etc. etc.
Vos questions:
Outils complémentaires?
Je pourrais imaginer une boutique SaaS utilisant les deux: on pourrait utiliser Ansible pour effectuer toutes les actions de déploiement, puis utiliser Rundeck pour effectuer des tâches ponctuelles et ad hoc.
Cependant, même si je pouvais l'imaginer, je ne recommanderais pas cela comme point de départ. Moi, je commencerais par Ansible et je verrais jusqu'où je vais. Je ne ferais que superposer Rundeck plus tard si je découvrais que j'ai vraiment vraiment besoin d'exécuter des opérations ponctuelles.
CI/CD
Ansible: votre environnement ressemble plus à une maison de logiciels où vous déployez votre propre application. Il devrait probablement être reproductible (d'autant plus que vous allez en livraison continue), vous voudrez donc que vos scripts de déploiement soient sous contrôle de code source. Vous aurez envie de simplicité et Ansible est "juste des fichiers texte". J'espère que vous voudrez aussi que vos développeurs puissent exécuter des choses sur leurs machines (non?), Ansible est décentralisé.
Utilisé ensemble (pour CI/CD)
Appeler Rundeck depuis Ansible, non. Bien sûr, ce serait possible mais j'ai du mal à trouver de bonnes raisons. Au moins, des raisons spécifiques à une application ou à un cadre peu spécialisées.
Appeler Ansible depuis Rundeck, oui. Je pourrais imaginer que quelqu'un construise d'abord des commandes adhoc reproductibles dans Ansible. Ensuite, je pouvais voir qu'il y avait une petite demande pour pouvoir appeler cela sans ligne de commande (disons: utilisateurs non techniques). Mais, encore une fois, cela devient spécifique à votre environnement.
Mon point - rundeck et ansible (gratuit, sans tour) font un type de travail différent
Ansible (sans tour) - gestion de la configuration (fourniture serveur/application, mises à jour de configuration de masse)
Rundeck - Planificateur de travaux centralisé avec contrôle d'accès, notification, sortie de travaux, etc. (archiver les anciens journaux, exécuter certains scripts, etc.)
Il est uniquement basé sur vos besoins. J'utilise rundeck pour l'exécution de scripts à distance et les déploiements d'applications. Je l'ai intégré à Foreman pour couvrir l'approvisionnement et la gestion de la configuration.
Si vous avez des contraintes budgétaires, ne cherchez plus, Rundeck est génial. Vous pouvez cependant manquer certaines fonctionnalités d'Ansible. De plus, le groupe Google est à peu près très actif en cas de support.
Si vous avez un budget, investissez dans une tour ansible et vous n'aurez peut-être pas besoin d'autre chose.
Au moment où cette question a été posée, l'auteur a correctement déclaré qu'Ansible ne fournissait une interface utilisateur que moyennant des frais.
L'interface utilisateur est désormais open source: AWX
Les normes de serveur deviennent ansibles.
La tâche ad hoc/opération passe en revue.
C'est ce que j'utilise actuellement.
Si vous allez les utiliser comme portail libre-service pour les développeurs ou l'équipe OPS, je dirais que RBAC est plus simple et intuitivement mis en œuvre dans Tower plutôt que dans Rundeck. Considérez combien d'efforts et de complexité sont nécessaires pour configurer RBAC, car cela peut être crucial pour les équipes qui prennent en charge ces produits.
L'API REST dans Tower est plus simple et plus facile à analyser que dans Rundeck.
Dans Tower, vous pouvez voir les événements individuels par tâche de playbook tandis que dans Rundeck, tout est jeté dans une sortie de console.
Les inventaires dynamiques dans Tower sont très utiles avec les déploiements dans les clouds publics.