As we start to scale and handle things like certificates, we have necessities regarding the domain names services utilize to get to one another. Our specific use-case involves the creation of LetsEncrypt certificates for internal services and the logistics that entails. The just of the need is that all services making incoming connections to our internal applications must utilize the domain for which a certificate has been created for.
For this to work, we presently use the rancher-letsencrypt service to grab us a cert for mongo.example.com, an external domain meant to always point to our internal mongo instances. However, creating a CNAME to mongo-cluster.mongo.rancher.internal and then expecting internal services to resolve that to an A record doesn’t work (won’t get into the details, see here).
There is a quick way around this by using linked service aliases or even possibly running our own dns server (not sure if dnsmasq or powerdns may handle this differently). However, what I’d like of Rancher is the ability to utilize the domain name field for services as a record Rancher’s internal dns should resolve for. So if I were to start a service cooldb in a stack database with a domain of db.company.com, I could expect it to be served by internal dns as a CNAME/A to cooldb.database.rancher.internal henceforth getting my service where it needs to go.
I’m definitely not a dns expert and there may be other more optimal ways of handling this need, but as more teams start using Rancher, I feel like a solution to this problem should be implemented in as simple a way as possible. Really interested in hearing others` thoughts on this!
This is basically what Service Aliases are for, as you seem to know already. They create CNAME records available to the services of the stack.
The domain name field goes along with hostname and becomes the the resolv.conf configuration for the container, so that can’t just be hijacked to mean something different. That would also provide no way to have multiple cnames for the same service.
I was thinking more something that might scale a little better than requiring manual setup via external service on each and every stack. In that aspect, this doesn’t scale well, especially if you want a service to represent a specific domain name for your entire environment.
I guess I’ll roll with external services for now. I may open an issue with more details of what I’m asking and how it could be implemented. I really feel like administrators should have a bit more control over the DNS layer and how it acts in their environment.
You could write something that looks at metadata for services and reads the FQDN out of a label and creates service aliases for them, or similar as an external-dns provider.
The container DNS is not really designed to provide answers for random zones it’s not authoritative for… this does work, e.g. if you specifically put in an “as name” that is a random FQDN. But what you’re asking for would add a name that resolves anywhere in the environment. That would be very easy to accidentally misconfigure or intentionally abuse… and hard to figure out because that name is only a property of a random service, not a top level resource you can immediately see.
Yeah exactly. I suppose most people will probably run their own DNS if they actually wanted to start being authoritative for certain zones. In this case, I was trying to adopt the already existent Rancher DNS for my authoritative needs
Since it looks like I can pretty easily define external services with rancher-compose syntax, I’ll just set this up in my catalog entries.
For anyone reading this, the problem is solved via making an external service pointing to the internal address i.e. mongo-cluster.mongodb.rancher.interal and then creating a service link on the service you want to use this setting the alias/name to mongo.development.example.com
