consul VS harbormaster

The JHipster scaffolded sample application has a gateway application and two microservices. It uses Consul for service discovery and centralized configuration.

Service Discovery: Microservices need to discover and communicate with each other dynamically. Service discovery tools like etcd, Consul, or Kubernetes built-in service discovery mechanisms help locate and connect to microservices running on different nodes within the infrastructure.

After some research and testing, I landed on using Consul and Fabio as the demo infrastructure. Of course, there is a myriad of other options to accomplish this task, but because of the low configuration and ease of use, I was impressed with this pairing. Both projects are mature and well-supported, and very flexible--just because you can run them with low configuration, doesn't mean you have to. I wanted to keep this demo constrained, but the exercise did get me excited about exploring things further: circuit breakers, traffic splitting, and more complex service meshes.

The goal is to be able to use Consul SD configurations to allow for retrieving scrape targets from consul. Is this possible? Can anyone provide an example? Thank you!!

https://github.com/hashicorp/consul/pull/12080 - this should be the Consul issue that brought down Roblox

The Consul collector is production ready! Consul by HashiCorp is a powerful and complex identity-based networking solution, which is not trivial to monitor. We were lucky to have the assistance of HashiCorp itself in this endeavor, which resulted in a monitoring solution of exceptional quality. Look for common blog posts and announcements in the coming weeks!

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

I use an HP ProLiant Microserver with four drives in a ZFS RAIDZ array and an SSD for the OS. For software, I mostly run it in Docker using a very small container orchestration program I wrote:

https://gitlab.com/stavros/harbormaster

I needed something that would restart containers automatically when I pushed to a branch, so I wrote a few lines of code to do it:

https://gitlab.com/stavros/harbormaster

As far as PaaSes go, it's probably the simplest, and works really well.

I was in the same boat as you and built something simple that I really like:

https://gitlab.com/stavros/harbormaster

It'll just pull some repos, make sure the containers are up, and make your configuration simple and discoverable. It really works great at that.

I do this for our services, it works great and we can easily put SSO in front of them with CF Access. I publish a Docker container that you can use as a sidecar for your Compose deployments:

https://gitlab.com/stavros/docker-cloudflared

I use this with Harbormaster (https://gitlab.com/stavros/harbormaster) so I can expose containerized stuff without ever forwarding any ports outside of Docker.

I use Dokku for that (I can share my Bitwarden repo if you want, the entire thing is four lines or something). I also made https://gitlab.com/stavros/harbormaster for things that weren't so "web server -> app -> database" and love it.

I had the same problem and didn't want to manage things by hand, so I wrote Harbormaster:

https://gitlab.com/stavros/harbormaster

It basically pulls Compose apps from the git repositories you specify, builds the containers and makes sure they're running. Pretty simple and works really well for me.

(This post should read "Argo tunnel" instead of just "Argo")

I did the same to enable secure access to services via SSO at work. I used Harbormaster[1] to deploy Compose files, but it's otherwise the same setup.

One of the big advantages this has is that the services can't be accessed any other way (not even from the same host, as they only listen inside the Docker network). That makes it hard to forget some port exposed because you listened to 0.0.0.0 instead of localhost.

Cloudflare access is very easy to set up SSO with, as well. I'd recommend this setup if you need it, though for home usage I usually just set up Caddy as a reverse proxy with basic auth, as I'll be the only person using this and I don't want Cloudflare MITMing my personal stuff.

[1]: https://gitlab.com/stavros/harbormaster

Something like harbormaster? https://gitlab.com/stavros/harbormaster