I would set the leave_on_terminate option to true. As per the documentation
leave_on_terminate If enabled, when the agent receives a TERM signal,
it will send a Leave message to the rest of the cluster and gracefully
leave. The default behavior for this feature varies based on whether
or not the agent is running as a client or a server (prior to ...
As a best practice, you should gracefully deregister the node gracefully. In this case, consul will know the the node has left and will be removed from the cluster. Otherwise, the consul cannot distinguish between a temporary failure, agent crash, network partition, etc.
There is a github issue as well related to this.
Quoting few important points from ...
I recommend that you take a look at the NetworkX library for Python. With a script you could query Consul and build a graph of linked nodes which could be rendered to an image file and served with a web server. A Flask microservice for this would be fairly simple to set up and provide a very useful visualization of your microservices spiderweb.
It looks like that the official Consul documentation is more up to date than the link that was posted in the question.
If one starts with the Getting Started guide, then one could start a consul agent in no time and the documentation also explains how to proceed.
user@localhost /tmp $ ./consul agent -dev
==> Starting Consul agent...
==> Consul agent ...
I have done this in the past using https://github.com/hashicorp/consul-template.
What consul-template does it generate a configuration file (for nginx) based on a certain template you provide. And the values that it fills into this template are coming from the configuration stored in consul.
Each time your micro-services register themselves in consul and ...
Based on my understanding of the topology you have described you essential have:
3 Nodes - 2 Servers and 1 Client
This layout is immediately a problem because the clustering protocol that consul uses relys on being able to easily elect a leader, which requires an odd number of servers.
If you consider the failure scenario of a 2 node consul cluster - as ...
I would say that Istio is the de facto standard for Service Mesh. It is launched by both Google and IBM.
Welcome to the service mesh era: Introducing a new Istio blog post series
IBM, Google Cloud and the open community launch Istio 1.0 to bring microservices to the enterprise
The usual way to do that is to use a service manager (systemd or supervisord) to handle the service lifecycle (keeping the consul program running and restarting it if it fails for exemple) there's cookbooks existing to help creating those service units.
The cheap alternative if you count on chef running periodically and handling that is to use nohup which ...