Consul: Namespaces for service registration
The current behavior with service registration is to return every service that consul is aware of.
There are cases where we want to limit or group services together and only return those results.
For example, we may want to have a group of web applications being proxied via haproxy & consul template, or allow a development group to get responses only about a limited number of servers.
Depending on naming/tagging seems like it would lead to problems. Just thinking of ideas on how to segregate service discovery.
stevendborrelli
All 17 comments
@stevendborrelli The way forward on this is via the ACL system. With 0.5 it was extended to support service registration, to restrict who can register services. With 0.6 it will be extended to discovery as well. So you could create a "dev" ACL policy that only allows registering and discovering a subset of instances, etc. Hope that helps!
armon
on 6 Mar 2015
This is also made infinitely nicer using the shiny new prepared queries. The Consul 0.6 release is just around the corner and this is one of the tentpole features for it. Check it out, and let us know if that satisfies your use case!
ryanuber
on 25 Nov 2015
@ryanuber how do prepared query improve this? Can you elaborate please?
raphink
on 12 Jan 2016
@armon so you're saying instead of namespace, make it so that consumers can only see some nodes? What if I want to configure an haproxy for multiple services that share the same name with a different namespace?
raphink
on 12 Jan 2016
@raphink Basically the ACL system can be used to provide users with a partial view of the system. Instead of seeing all the services, you can restrict what is visible. Its not the same as a namespace, but can be used to segregate teams and services.
armon
on 15 Jan 2016
@armon I get the idea, but it doesn't allow to have multiple services with the same name on a given proxy.
raphink
on 18 Jan 2016
++ for the feature.
Zogg
on 4 Feb 2016
+1 as well
jshaw86
on 9 May 2016
This is quite similar to #290
Basically, I have a similar problem. I have a simple datacenter with different environment within. We want each environment to register services with no naming restrictions between environments, but a given environment should only be able to access the services it registered.
We want also at a global scope to be able to access all the services from all environments to monitor them.
Basically, we need some kind of namespace before the service name. The service name uniqueness would only be guaranteed across the same namespace, and the default value for the namespace when registering a service for example would be provided by the nomad agent. And we need to have ACL to be able to filter services based on this namespace. A default namespace should be able to be specified in the agent configuration for the DNS interface.
Until then, I suppose the only option to have separate environments that doesn't share services is to run multiple different clusters.
mildred
on 29 May 2017
any updates on it?
freeseacher
on 26 Oct 2018
Can service tags help you with this?
pysysops
on 14 Nov 2018
+1 for a feature
dunkelbunt1
on 5 Sep 2019
This is needed for Kubernetes and how services are synchronnize from kuberntes to consul, right now services with the same name gets flattened to a single service name in consul with no way to differentiate it.
filintod
on 11 Nov 2019
@filintod are you using consul in kubernetes or trying to bridge to external services as say part of a migration to k8s?
jshaw86
on 11 Nov 2019
we are migrating services to kubernetes and installing it on kubernetes, but we will have a mix environment VM/k8s for a while. We need to expose services that are on multiple namespaces, the workaround is to put the namespace as part of the name, but this is not a very clean multi-tenancy solution. The consul-k8s sync agent cannot do much other than the workaround mentioned as consul does not support multiple-namespaces.
filintod
on 11 Nov 2019
makes sense, we ended up just using headless services to point to external services but it's not a complete solution especially if your VM's are very elastic. If you are using AWS AS groups you could just throw a NLB between K8s and your VM's and just point the headless services at the NLB.
jshaw86
on 11 Nov 2019
I am happy to let you know this issue is solved, now that namespaces arrived in Consul 1.7.0 Enterprise: https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#170-february-11-2020.
i0rek
on 18 Feb 2020
Related issues
eshujiushiwo
路
3Comments
nschoe
路
4Comments
atomantic
路
4Comments
satheeshCharles
路
3Comments
nicholasjackson
路
3Comments
Most helpful comment
This is quite similar to #290
Basically, I have a similar problem. I have a simple datacenter with different environment within. We want each environment to register services with no naming restrictions between environments, but a given environment should only be able to access the services it registered.
We want also at a global scope to be able to access all the services from all environments to monitor them.
Basically, we need some kind of namespace before the service name. The service name uniqueness would only be guaranteed across the same namespace, and the default value for the namespace when registering a service for example would be provided by the nomad agent. And we need to have ACL to be able to filter services based on this namespace. A default namespace should be able to be specified in the agent configuration for the DNS interface.
Until then, I suppose the only option to have separate environments that doesn't share services is to run multiple different clusters.