We have a bunch of external nodes and services that should be integrated into consul.
As I understand I can add them with the consul api /catalog/service/ with "external-node": "true" and check them with consul-esm.
Is there a way to setup all the external nodes/services on startup of consul agent (server/client?) as with internal services with config files in config.d directory?
Should there be used an extra server or the consul-servers that starts some scripts to add them with curl to the catalog?
Or adding them with ExecStartPre= or ExecStartPost= command in systemd.service for consul-server or consul-esm or …?
Not sure if you have found these on your own, but we do have documentation that talks about deploying external services which could be useful in your endeavor:
Some more details in addition to the documentation: currently there is no way to set-up external nodes on consul start up via config files. This is however something we are working on as part of https://github.com/hashicorp/consul-esm/issues/42 so that script checks can be supported and loaded via config files.
In the meantime, we recommend that the external nodes/services register themselves with the consul agent. If that’s not possible, a script on a separate server or from a systemd command works fine so long as the consul agent is already started up. Another option could be to use terraform which would allow you to set up external nodes/services in a codified way.
I just stumbled over the same fact that it currently seems to be impossible to register, update and de-register external services via configuration files (HCL or JSON) to consul or consul-esm via config-dir.
The Consul-ESM issue 42 has been mentioned but the config file topic is only a part of it.
Is this topic on any roadmap or handled in a dedicated issue?
How do you guys manage your set of external services?
In our landscape every internal service is manged via files.
We have no central or automated system which could update external services in the same way via the API. We won’t and can’t relay on any human doing that, an automated solution is required here.
As far as I can remember, I created some scripts that gets called on startup/restart/reload that removes the configuration and adds it again via the api with some curl/consul calls.
But in the end we removed consul-esm completely as it did not propper work with the ACL configuration or I did not get it to work the way I would like to have it…
We don’t manage the external services that we connect to, so I created a normal consul service without a check that run on the consul servers. The external service exist than multiple times (number of consul servers) and would get checked multiple times but as we don’t have checks this is not a problem.
I hope I could help.
The Consul-ESM issue 42 has been mentioned but the config file topic is only a part of it.
Is this topic on any roadmap or handled in a dedicated issue?
Currently there is no dedicated issue to specifically capture a feature to load external services via config files on Consul/Consul-ESM start up. For your use-case, do you see this feature being more helpful in Consul or ESM?
As far as Consul-ESM issue 42, we’ve recently considered taking it in a new direction that may not require Consul loading config files on start up. Regardless, I think you raise a good point that this feature should have its own dedicated issue. If you feel comfortable, please feel free to create the issue in Consul or ESM depending on where you see this feature. Or, you can create the issue in ESM for now and we can migrate the issue to Consul later if needed.
Hi @reini-1, thanks for sharing information on your use-case! I’m not sure what specific issues you encountered with ACLs, but we’ve since updated new information on ACLs in our documentation. Regardless, it sounds like your experience with ESM was difficult, and it would have been beneficial to have this upload config feature. Thank you for your feedback on this!
To both, as a heads up, I won’t be available until early January. Apologies in advance and thanks for your patience.
thanks for this valuable insight. I’m currently evaluation external services in Consul, and thus consul-esm. We have some Windows systems not being under configuration management providing HTTP services I’d like to have in Consul. As they are not managed I can’t/won’t maintain Consul on them.
Currently we have to hard code their FQDN’s in every place which has to access them. Welcome to a pre service discovery age :(.
I also thought about the option to register such services on the nearest Consul server but with a health check. I always “sold” Consul inhouse with the statement that it would always provide only “healthy” service instances. So I don’t want to omit the health checks as I see it as a core feature and benefit of Consul.
But having these external services registered with health checks does not scale well. Health checks are performed unnecessary often this way.
@lornasong, thanks for your reply as well.
I’m happy that Hashicorp has an eye on this.
I will create a feature request in consul-esm and relate to this topic and issue 42 as extension. As I’m no developer I can only kindly ask for it and maybe to tests on new functions later.
For now I think I have to discard the use of external services in Consul as they do not make my world better without drawbacks. I will keep an eye on these topic and may use the function later if it’s easier to implement.
Thanks for creating the issue and linking it here! It looks great, and I appreciate all the additional context you shared. I will make a note internally that this missing feature is causing you as well as reini-1 and perhaps others to have to drop consul-esm.
Thanks for your feedback on this issue! Please let us know if anything else comes up.