Rundeck VS consul

Have a look at rundeck.org

Firstly, I tried Rundeck and Apache Airflow. They are complete overkill for what I want to do. Then I found Cronicle which is light enough, besides it can pull double duty as a general purpose scheduler.

Yesterday we posted a Security Advisory to Github for a critical vulnerability in Rundeck Community and Rundeck Enterprise Docker images, versions 4.0 and earlier. Those Docker images contained a pre-generated SSH key pair in the default file path. If that key was used to configure SSH access to hosts, they would allow access to anyone with the exposed private key.

Never used it myself (we're currently working on deploying Tower) but I've heard that Rundeck is the goto for your exact use case: "Tower, but less heavy". I looked at it when evaluating for my current job and it looks like a good middle of the road solution and looks way easier to deploy than AWX. The tradeoff is that since it's not custom built for Ansible you can automate lots of other things with it (like just bash scripts and the like) but you get less of the Ansible-specific integrations and tooling that Tower offers.

Hi! This fix solves the bug, is ready to be included in the next release. Regards.

There is already an open GitHub issue on this, but I wanted to mention it here as it can cause some nasty surprises for those unaware.

Compare to rundeck after they were acquired by Pagerduty

https://github.com/rundeck/rundeck/graphs/contributors

Changed the service discovery to Consul, since this is the default in JHipster 8.

In another effort to standardize development and operations, Lob has just wrapped up our container orchestration migration from Convox to HashiCorp’s Nomad, led by Senior Platform Engineer Elijah Voigt. In this new ecosystem, one feature available to us is Consul Service Mesh (a feature of Consul, which is part of our Lob Nomad stack).

Service registry and discovery etcd, consul, nacos

The underlying tool Consul is very powerful, and Consul Connect service mesh on top of this tool is quite robust and extremely flexible where you can swap out the default CA for other solutions, like Vault CA, and swap out the Envoy proxy for another solution, like NGINX or HAProxy. For ingress into the cluster, you can use Consul API Gateway, or another API Gateway or an ingress controller.

I'd like to also mention hashicorp nomad + consul. They're worth evaluating.

Out of the number of service mesh solutions that exist, the most popular open source ones are: Linkerd, Istio, and Consul. Here at Koyeb, we are using Kuma.

Consul

A service mesh provides features to help with common distributed microservice challenges. Like service discovery, routing, load balancing, and so on. Today we will be using Istio, one of the most popular service mesh solutions available. Istio is tailored for distributed application architectures, especially those you might run in Kubernetes. Istio plays nicely with Kubernetes, so nicely that you might think that it's part of the Kubernetes platform itself. Istio isn't the only service mesh around; we also have platforms like Linkerd and Consul, which are also quite popular.

We knew that we needed a way, at runtime, to start and stop these queue consumers. Although we could have reached for other configuration management tools like Hashicorp Consul or AWS AppConfig, we already use LaunchDarkly at Knock to control the runtime behavior of our frontend and backend applications. LaunchDarkly feature flags seemed like a great way to control this starting and stopping process without adding new dependencies or complexity to our stack.

Since all of your apps are in the same environment, one possibility is to use a service registry like Consul or etcd. As a container comes up it registers itself by making a REST call to declare “I’m the Rabbit server!”. Then other apps call out to etcd with a REST query to ask “Where’s the Rabbit server?” and get the name of the Rabbit container. If you decide to start playing with HA or clustering, this can be extended so the service registry returns the name of the current primary node, or spreads traffic across multiple nodes by returning different responses based on rules you set up.