Rundeck VS consul

Compare to rundeck after they were acquired by Pagerduty

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

Hi! That's reported here, please add your use case.

Strangely enough, when putting 0d in the conguration file, the WebUI field is pre-filled with 0.

Anyway, you can suggest that here :-)

Hello, currently that's not configurable, you can suggest it here. Regards.

Hi! If you decide to call the API from the inline-script step, consider creating a specific plugin for that. Take a look at this and this basic example.

Reproduced here. Thanks for your feedback!

You can use regex expressions on -match: name: blocks, for example, project.*, check this another example (focused on jobs) I think that is what you're looking for.

For discovery outside of Kubernetes, you can use whatever your configuration management database is to generate the discovery configs. But you might want to look at Consul. The down side to using discovery scripts is the monolithic update lag. I used to have a medium sized setup with Chef and Nagios. It took something like 5 minutes just to run one config cycle. As we transitioned to Prometheus we cut the cycle down to a couple minutes, because we had smaller targeted configs.

So, my tech lead has once more had the sweet whispers of HashiCorp blaring in his ear, and to my irritation has decreed that we will be prioritizing bringing Consul into our environment despite pretty much everything else we have being in various states of rotting popsicle sticks and scotch tape.

> There is gap in the market between VM oriented simple deployments and kubernetes based setup.

In my experience, there are actually two platforms that do this pretty well.

First, there's Docker Swarm ( https://docs.docker.com/engine/swarm/ ) - it comes preinstalled with Docker, can handle either single machine deployments or clusters, even multi-master deployments. Furthermore, it just adds a few values to Docker Compose YAML format ( https://docs.docker.com/compose/compose-file/compose-file-v3... ) , so it's incredibly easy to launch containers with it. And there are lovely web interfaces, such as Portainer ( https://www.portainer.io/ ) or Swarmpit ( https://swarmpit.io/ ) for simpler management.

Secondly, there's also Hashicorp Nomad ( https://www.nomadproject.io/ ) - it's a single executable package, which allows similar setups to Docker Swarm, integrates nicely with service meshes like Consul ( https://www.consul.io/ ), and also allows non-containerized deployments to be managed, such as Java applications and others ( https://www.nomadproject.io/docs/drivers ). The only serious downsides is having to use the HCL DSL ( https://github.com/hashicorp/hcl ) and their web UI being read only in the last versions that i checked.

There are also some other tools, like CapRover ( https://caprover.com/ ) available, but many of those use Docker Swarm under the hood and i personally haven't used them. Of course, if you still want Kubernetes but implemented in a slightly simpler way, then there's also the Rancher K3s project ( https://k3s.io/ ) which packages the core of Kubernetes into a smaller executable and uses SQLite by default for storage, if i recall correctly. I've used it briefly and the resource usage was indeed far more reasonable than that of full Kubernetes clusters (like RKE).

With multiple services running, it’s hard to discover where they’re located. The dependencies between multiple services are not always easily found, and new services may be deployed with a new dependency on an older service. Those services can be deployed anywhere in the infrastructure, so what you need is a Service Discovery service. There are plenty available, such as Netflix Eureka or HashiCorp Consul.

The myriad of request processing middlewares does not end here - there is also the very trendy topic of service meshes that we could cover, but I choose to leave that as an exercise to interested readers, as it is a rapidly evolving and complex space (see: Istio, linkerd, Consul, Tanzu, etc).

An SWE would likely guide the development and maintenance of any kind of SOA-based architecture, including writing and configuring the software to make it work. For example, a data scientist would not worry about using Polly for resiliency, or Consul for service discovery, and creating the libraries to use these systems.

Hashi also offers Consul https://www.consul.io/ which has a KV store with ACL

If you need your configuration changes to be rolled out more immediate, there are other options as well. Rather than reading from a properties file, you could use a key-value store such as Consul, etcd, or AWS Systems Manager Parameter Store. While this gives you more direct control of configuration changes, it introduces new challenges. First, managing your configuration as code might require additional tooling, such as defining them as Terraform resources. Additionally, your application will have to know how to speak to the configuration services, including a proper authentication mechanism.