jenkins - ¿Es una buena idea hacer que Ansible y Rundeck trabajen juntos, o usar cualquiera de ellos es suficiente?

continuous-delivery devops (6)

Si va a usarlos como portal de autoservicio para desarrolladores o para el equipo de OPS, diría que RBAC es más simple e intuitivamente más claro implementado en Tower que en Rundeck. Considere cuánto esfuerzo y complejidad se requieren para establecer RBAC, ya que puede ser crucial para los equipos que respaldan estos productos.
La API REST en Tower es más simple y fácil de analizar que Rundeck.
En Tower puede ver eventos individuales por tarea de libro de jugadas mientras que en Rundeck todo se lanza en una salida de consola.
Los inventarios dinámicos en Tower son bastante útiles con implementaciones en nubes públicas.

Recientemente estoy buscando a Ansible y quiero usarlo en proyectos. Y también hay otra herramienta Rundeck que se puede usar para hacer todo tipo de operaciones. No tengo experiencia con ninguna herramienta y esta es mi comprensión actual sobre ellas:

Puntos similares

Ambas herramientas son sin agente y usan SSH para ejecutar comandos en servidores remotos
El concepto principal de Rundeck es Node, al igual que el inventario de Ansible, la idea clave es definir / administrar / agrupar los servidores de destino
Rundeck puede ejecutar comandos ad-hoc en nodos seleccionados, Ansible también puede hacer esto de manera muy conveniente.
Rundeck puede definir el flujo de trabajo y realizar la ejecución en los nodos seleccionados, esto se puede hacer con Ansible escribiendo el libro de jugadas
Rundeck se puede integrar con la herramienta de CI como Jenkins para implementar el trabajo, también podemos definir un trabajo de Jenkins para ejecutar un libro de jugadas compatible para realizar el trabajo de implementación.

Diferentes puntos

Rundeck tiene el concepto de Job, que Ansible no
Rundeck tiene Job Scheduler, que Ansible solo puede lograr con otras herramientas como Jenkins o Cron tasks
Rundeck tiene la interfaz de usuario web de forma predeterminada de forma gratuita, pero tiene que pagar por Ansible Tower

Parece que tanto Ansible como Rundeck se pueden usar para realizar trabajos de configuración / gestión / implementación, tal vez de una manera diferente. Entonces mis preguntas son:

¿Son estas dos herramientas complementarias o están diseñadas para diferentes propósitos? Si son herramientas complementarias, ¿por qué solo se compara a Ansibl con herramientas como Chef / Puppet / Slat pero no con Rundeck? Si no es por eso que tienen tantas funcionalidades similares?
Ya usamos Jenkins para CI, para construir una canalización de entrega continua, ¿qué herramienta (Ansible / Rundeck) es una mejor idea para usar para hacer la implementación?
Si se pueden usar juntos, ¿cuál es la mejor práctica?

Cualquier sugerencia y experiencia compartida es muy apreciada.

En el momento en que se hizo esta pregunta, el autor afirmó correctamente que Ansible solo proporcionó una UI por una tarifa.

La interfaz de usuario ahora ha sido de código abierto: AWX

Está basado únicamente en sus requisitos. Utilizo rundeck para la ejecución remota de scripts y las implementaciones de aplicaciones. Lo he integrado con Foreman para cubrir la gestión de configuración y aprovisionamiento.

Si tiene restricciones presupuestarias, no busque más, Rundeck rocks. Sin embargo, puede que omita algunas características en Ansible. Además, el grupo de Google es bastante activo en caso de apoyo.

Si tiene un presupuesto, invierta en una torre ansible y tal vez no necesite nada más.

Los estándares del servidor son ansible.

Adhoc / operation task ir rundeck.

Esto es lo que uso actualmente.

Mi punto - rundeck y ansible (gratis, sin torre) hacen diferentes tipos de trabajo

Ansible (sin torre) - gestión de configuración (provisión de servidor / aplicación, actualizaciones de configuración masiva)
Rundeck: programador de tareas centralizado con control de acceso, notificación, salida de trabajos, etc. (archiva registros antiguos, ejecuta algunos scripts, etc.)

TL; DR: dado su entorno de Jenkins para CI / CD, recomendaría usar solo Ansible.

Ha detectado que hay un considerable cruce entre Ansible y Rundeck, por lo que probablemente sea mejor concentrarse en dónde se enfoca cada producto, su estilo y uso.

Atención

Creo que el objetivo de Rundeck es permitir que los administradores de sistemas construyan un portal de autoservicio (basado en la web) que sea accesible tanto para otros administradores de sistemas como, potencialmente, para personas menos "técnicas" / sysadmin. El sitio web de Rundeck dice: " Convierta sus procedimientos de operaciones en trabajos de autoservicio. De manera segura, brinde a otros el control y la visibilidad que necesitan ". Rundeck también siente que tiene una visión más "centralizada" del mundo: carga los trabajos en una base de datos y es allí donde viven.

Para mí, Ansible es para devops, por lo que desarrolla y automatiza implementaciones de aplicaciones (autoconstruidas) de tal forma que son altamente repetibles. Yo diría que Ansible se enfoca más en las casas de desarrollo de software que construyen sus propios productos: los libros de jugadas de Ansible son archivos de texto, por lo que normalmente se almacenan en control de fuente y normalmente junto con la aplicación que los libros de jugadas implementarán.

Foco de creación de empleo

Con Rundeck, normalmente crea trabajos a través de la interfaz de usuario web.

Con Ansible puede crear tareas / libros de jugadas en archivos a través de un editor de texto.

Operación / Tarea / Estilo de trabajo

Rundeck de forma predeterminada es imprescindible: usted escribe scripts que se ejecutan (a través de SSH).

Ansible es imprescindible (es decir, ejecuta sentencias bash) pero también declarativo, por lo que en algunos casos, por ejemplo, al iniciar Apache puede usar la tarea de service para asegurarse de que se está ejecutando. Esto está más cerca de otras herramientas de administración de configuración como Puppet and Chef.

Trabajos / scripts complejos

Rundeck tiene la capacidad de ejecutar otro trabajo definiendo un paso en el flujo de trabajo del trabajo, pero por experiencia esto parece una adición añadida a una característica seria de alto nivel.

Ansible está diseñado para crear operaciones complejas; ejecutar / incluir / etc son características de nivel superior.

Cómo funciona

Rundeck es una aplicación de servidor. Si desea ejecutar trabajos desde otro lugar (como CI), deberá llamar al cli o hacer una llamada API.

Straight Ansible es línea de comando.

Condición

Debido al cruce y la flexibilidad general de Rundeck y Ansible, puede lograr todo lo anterior en cada uno. Puede lograr el control de versión de sus trabajos Rundeck exportándolos a YAML o XML y verificándolos en el control de fuente. Puede obtener una interfaz de usuario web en Ansible usando Tower. etc. etc. etc.

Tus preguntas:

Herramientas complementarias?

Pude imaginar una tienda SaaS usando ambos: uno podría usar Ansible para realizar todas las acciones de implementación y luego usar Rundeck para realizar trabajos adhoc de una sola vez.

Sin embargo, aunque podría imaginarlo, no lo recomendaría como punto de partida. Yo, comenzaría con solo Ansible y vería qué tan lejos llegaré. Solo me pondría capas en Rundeck más adelante si descubría que realmente, realmente necesito ejecutar one-offs.

CI / CD

Ansible: su entorno suena más como una casa de software en la que está implementando su propia aplicación. Probablemente debería ser repetible (especialmente cuando vayas a Entrega Continua) por lo que querrás que implementes las secuencias de comandos en control de fuente. Querrá simplicidad y Ansible es "solo archivos de texto". Espero que también quieras que tus desarrolladores puedan ejecutar cosas en sus máquinas (¿no?), Ansible está descentralizado.

Usados juntos (para CI / CD)

Llamando a Rundeck desde Ansible, no. Claro, sería posible, pero estoy luchando por encontrar buenas razones. Por lo menos, razones no muy específicas de específico a una aplicación en particular o marco.

Llamando a Ansible desde Rundeck, sí. Podría imaginar a alguien primero construyendo algunos comandos adhoc repetibles en Ansible. Entonces pude ver que hay una pequeña demanda para poder llamar esto sin una línea de comando (digamos: usuarios no técnicos). Pero, de nuevo, esto se está volviendo específico para su entorno.