Support multiple domains

[jimmykarily]

A user may want to use different domains for different applications. Right now, Epinio only supports one domain (the system-domain) and app routes are subdomains of that. Other PaaS (like Heroku for example), solve this by allowing the user to set a CNAME and point it to the application's subdomain. This may involve some updating of the underlying certs (additional CN values etc).

We need to investigate how multiple domains can be supported. If CNAMEs don't solve this, we probably need to "register" the domains with Epinio (like CloudFoundry does with shared and private domains).

Things to try out:

• Try to set a CNAME and see if Epinio works automagically
• If the above doesn't work, try to see how the CNAME could work (update the app cert?)
• Check other options (like registering domains on Epinio)

Questions to be answered:

• What about the other routes (the Epinio API url for example)
• When can the user specify the application domain? Only when first pushing or can be done on any later push?

[agracey]

@jimmykarily You mentioned that CNAME would be a work around, but I'm not sure it would as the request would still have the same headers when traefik looks at it.

[jimmykarily]

True, and we may need to update/re-create application TLS certificates with additional alternative names. It may not be that simple but we should give it a try first and see what happens.

[agracey]

One question that we will get is how to publish an app at the root of the domain as well. Currently we can only support subdomains

[agracey]

When we do this, it'd be nice if we also take @manno's idea in: #384

[agracey]

This should be configurable on each push command and is a dependency of #594

[manno]

Maybe something like e push --domain a.b.c --ingress-class default

[agracey]

Just to add some conversation that @jimmykarily and I just had around this:

The first take of this can require a new push to change hostname(s). We can leave editing hostnames after deployment for a future ticket closer to GA.

[jimmykarily]

Let do this for now:

The system domain defined during installation is the "default" one. "default" means that's the domain used for the epinio api and the epinio registry.

The user can add more domains with some (new) command (e.g. epinio domain create google.com). This should store that domain somewhere in the cluster (secret?). The user should be able to list the available domains and should be able to pick one when deploying an application.

To change the domain of an app, the user should be able to "add" a domain to the app. This should only create a new Ingress an the related certs. That new ingress should still point to the same app through the same service. Then the user can "remove" the old domain from the app making the whole process zero-downtime.

When pushing an app for the first time, the user should be able to pick which domain should be used.

I would defer the 3 other issues to separate tickets:

1. specific domain pointing to an app (no subdomain)
2. picking a different ingress
3. path based routing (which is Path based routing #594)

[jimmykarily]

In order to have two apps using the same domain but a different path (#594) , the user must be able to set the domain to that of another app. That means set the full final domain, not just the domain on which the app will get a subdomain from (like it happens now).

I think the solution should work like this:

• If the user doesn't specify a domain, the app will get a subdomain on the "default" domain
• If the user specifies a domain, that should be the complete one. Epinio won't will point that to the app, not a subdomain of it.
• When registering domains on Epinio (as described above), those will be used as per the previous item. The only domain that gets subdomains is going to be the "default" one which is the one that was used during epinio install.

@agracey is that plan ok? Do we need to have additional domains that behave like the default one? I mean additional domains which will be used to automatically create subdomain for apps.

[agracey]

That looks good to me. I wouldn’t worry about additional parent domains unless someone specifically asks for it with a good enough reason.

…

Sent from my iPhone

On Oct 21, 2021, at 1:49 AM, Dimitris Karakasilis ***@***.***> wrote:  In order to have two apps using the same domain but a different path (#594) , the user must be able to set the domain to that of another app. That means set the full final domain, not just the domain on which the app will get a subdomain from (like it happens now). I think the solution should work like this: If the user doesn't specify a domain, the app will get a subdomain on the "default" domain If the user specifies a domain, that should be the complete one. Epinio won't will point that to the app, not a subdomain of it. When registering domains on Epinio (as described above), those will be used as per the previous item. The only domain that gets subdomains is going to be the "default" one which is the one that was used during epinio install. @agracey is that plan ok? Do we need to have additional domains that behave like the default one? I mean additional domains which will be used to automatically create subdomain for apps. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jimmykarily]

Let's split this in 2 stories:

1. Allow the user to specify a domain for the application (specify during "push", add/remove domains afterwards). This domain doesn't have to be registered and it's not validated on the server side. The epinio server will just use it.
2. Allow the user to pre-register domains for applications. The epinio-server won't allow the user to use any non-registered domain. [TBD] Should the user register the top level domain or each and every app domain? If it's possible, top-level domain is earier for the user.

Let's keep this story for number 1. We will do number 2 here: #931

[jimmykarily]

Accompanying PR: https://github.com/epinio/application/pull/1/files