Est-ce une bonne idée de faire fonctionner Ansible et Rundeck ensemble, ou utiliser l'un ou l'autre est suffisant?
récemment je suis en train de regarder Ansible et je veux l'utiliser dans des projets. Et il ya aussi un autre outil Rundeck peut être utilisé pour faire toutes sortes de travaux D'opérations. J'ai de l'expérience avec ni l'outil, et c'est 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 celui d'Ansible l'inventaire, l'idée clé est de définir/gérer/groupe de serveurs cible
- Rundeck peut exécuter des commandes ad-hoc sur des noeuds sélectionnés, Ansible peut aussi le faire très commodément.
- Rundeck peut définir le workflow et exécuter sur les noeuds sélectionnés, cela peut être fait avec Ansible en écrivant playbook
- Rundeck peut être intégré avec un outil de CI comme Jenkins pour faire le travail de déploiement, nous pouvons également définir un travail Jenkins pour exécuter un possible-playbook pour faire le déploiement
les Différents points
Rundeck a le concept de Job, qui Ansible ne fait pas
Rundeck a un Job Scheduler, ce Qu'Ansible ne peut faire qu'avec D'autres outils comme Jenkins ou cron tasks
Rundeck a L'interface Web par défaut pour free, mais vous devez payer pour une tour possible
semble à la fois Ansible et Rundeck peut être utilisé pour faire configuration/gestion/déploiement travail, peut-être d'une manière différente. Donc mes questions sont:
- ces deux outils complémentaires sont-ils conçus à des fins différentes? S'il s'agit d'outils complémentaires, pourquoi Ansibl n'est-il comparé qu'à des outils comme Chef/Puppet/Slat mais pas à Rundeck? Si ce n'est pas le cas, pourquoi ont-ils autant de fonctionnalités similaires?
- nous utilisons déjà Jenkins pour CI, pour construire un pipeline de livraison continue, quel outil (Ansible / Rundeck) est un meilleure idée à utiliser pour faire le déploiement?
- si elles peuvent être utilisées ensemble, Quelle est la meilleure pratique?
toute suggestion et tout partage d'expérience sont grandement appréciés.
6 réponses
TL;DR - Etant donné votre environnement de Jenkins pour le CI / CD, je recommande l'utilisation de just Ansible.
Vous avez remarqué qu'il y a un croisement important entre Ansible et Rundeck, donc il est probablement préférable de se concentrer sur l'endroit où chaque produit se concentre, c'est le style et l'utilisation.
Focus
je crois que L'objectif de Rundeck est de permettre aux administrateurs système de construire un portail libre-service (basé sur le web) qui est accessible à la fois aux autres administrateurs système et, potentiellement, moins "technique"/sysadmin personnes. Le site Web de Rundeck dit " transformez vos procédures d'exploitation en emplois libre-service. Donner aux autres le contrôle et la visibilité dont ils ont besoin.". Rundeck a aussi 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) d'une manière telle qu'ils sont hautement reproductibles. Je dirais que Ansible vient plus ciblé pour les maisons de développement de logiciels qui construisent leurs propres produits: Ansible 'playbooks' sont des fichiers texte, donc normalement stockés dans le contrôle source et normalement à côté de l'application que les playbooks vont déployer.
priorité à 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/Emploi De Style
Rundeck par défaut est impératif - vous écrivez des scripts qui sont exécutés (via SSH).
Ansible est à la fois impératif (i.e. execute bash statements) mais aussi déclaratif, donc dans certains cas, par exemple, en démarrant Apache vous pouvez utiliser le service tâche de s'assurer qu'il fonctionne. C'est plus proche d'autres outils de gestion de configuration comme Puppet et Chef.
Jobs Complexes / scripts
Rundeck a la capacité d'exécuter un autre travail en définissant une étape dans le workflow du travail, mais de l'expérience cela ressemble à un tacked-on en plus d'une fonctionnalité de haut niveau sérieuse.
Ansible est conçu pour créer des opérations complexes; l'exécution/y compris/etc sont des fonctionnalités de haut niveau.
Comment ça fonctionne
Rundeck est une application serveur. Si vous voulez exécuter des travaux à partir d'un autre endroit (comme CI), vous devrez soit appeler le cli, soit faire un appel API.
droit Ansible est en ligne de commande.
Condition
en Raison du cross-over et la flexibilité globale de Rundeck et possible vous pourriez réaliser tout ce qui précède dans chacun. Vous pouvez réaliser le contrôle de version de vos tâches Rundeck en les exportant vers YAML ou XML et en les vérifiant dans le contrôle source. Vous pouvez obtenir une interface utilisateur web dans la possibilité en utilisant la Tour. etc. etc. etc.
vos questions:
des outils complémentaires?
je on pourrait envisager un atelier SaaS en utilisant les deux: on pourrait utiliser un possible pour effectuer toutes les actions de déploiement et ensuite utiliser Rundeck pour effectuer des travaux ponctuels, ad hoc.
cependant, bien que je puisse l'imaginer, Je ne le recommande pas comme point de départ. Moi, je commencerais par Ansible et je verrais jusqu'où j'irais. Je ne me coucherais dans Rundeck que plus tard si je découvrais que j'ai vraiment,vraiment besoin d'exécuter un compromis.
CI / CD
possible: votre environnement ressemble plus à un logiciel maison où vous déployez votre propre application. Il devrait probablement être reproductible (surtout si vous allez à la livraison continue) donc vous voudrez vos scripts de déploiement dans le contrôle source. Vous aurez besoin de simplicité et Ansible est "just text files". J'espère que vous voudrez aussi que vos devs soient capables de faire tourner des choses sur leurs machines (pas vrai?), La possibilité est décentralisée.
Utilisés de concert (CI/CD)
appel de Rundeck à partir D'Ansible, aucun. Bien sûr, ce serait possible, mais j'ai du mal à trouver de bonnes raisons. Au moins, pas très spécialisées spécifiques-pour-un-particulier-app-ou-cadre raisons.
appel Ansible depuis Rundeck, Oui. Je pourrais imaginer que quelqu'un construise d'abord des commandes ad hoc reproductibles dans Ansible. Alors je pouvais voir qu'il y avait une petite demande pour pouvoir appeler ceci sans ligne de commande (par exemple: utilisateurs non techniques). Mais, encore une fois, cela devient spécifique à votre environnement.
C'est uniquement en fonction de vos besoins. J'utilise rundeck pour l'exécution de script à distance et les déploiements d'applications. J'ai intégré avec Contremaître pour couvrir l'approvisionnement et la gestion de la configuration.
si vous avez des contraintes budgétaires, ne cherchez pas plus loin, Rundeck rocks. Vous pouvez cependant manquer certaines fonctionnalités dans la version Ansible. En outre, le groupe Google est assez très actif en cas de soutien.
si vous avez un budget investir dans une tour possible et vous pouvez ne pas avoir besoin de quoi que ce soit autre.
Mon point de rundeck et ansible (gratuit, sans tour) ne différent type de travail
Ansible (sans tour) - gestion de la configuration ( serveur / app disposition, la masse config mises à jour)
Rundeck-planificateur de tâches centralisé avec contrôle d'accès, notification, production de tâches, etc. (archive de vieux journaux, exécutez quelques scripts, etc.)
les standards des serveurs sont réalisables.
Adhoc / opération tâche go rundeck.
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 alors que RBAC est plus simple et intuitivement plus clair implémenté dans Tower plutôt que dans Rundeck. Il faut tenir compte de l'effort et de la complexité nécessaires pour établir le RBAC, car cela peut être crucial pour les équipes qui appuient ces produits.
L'API REST dans la tour est plus simple et plus facile à analyser que dans Rundeck.
dans la tour vous pouvez voir les événements individuels par tâche playbook tandis que dans Rundeck tout est lancé dans une sortie de console.
les inventaires dynamiques dans les tours sont très utiles avec des déploiements dans les nuages publics.