Publish Epinio to the DigitalOcean marketplace

[jimmykarily]

https://github.com/digitalocean/marketplace-kubernetes/blob/master/CONTRIBUTING.md

[jimmykarily]

Epinio installation requires at least a domain to be specified. The applications in DigitalOcean marketplace seem to take no input from the user so the domain can't be specified.

We could make the domain optional in Epinio this way:

• Epinio creates a path based ingress for the Epinio API. Anything that lands on /api/v1 goes to the Epinio server.
  This ingress can't have TLS.
• There is a command to set a system domain. E.g. epinio set-system-domain. After this happens, Epinio changes the Ingress for the Epinio API to use that domain.
• No applications can be pushed for as long as there is no system domain. That's because we have no way to route to the apps. We could use path based ingresses but those would need rewrite rules to be transparent to the application. Rewrite rules may not be supported by all ingress controllers (nginx supports it, not sure about traefik, maybe with the traefik.ingress.kubernetes.io/rewrite-target annotation: example).

Maybe this ties to the general "multiple domains" story: epinio/epinio#496

Not needing a domain simplifies the installation and usage of Epinio even more. It allows a zero-input installation and we allow the user to set the domain at any point in the future. On the other hand, it creates the need for a more complex handling of domains post-install.

[jimmykarily]

We can skip the creation of an ingress when a system domain is not set. The user can always use epinio app update --route to set a domain. In that case, the application will even have TLS.

In other words, if there is a system domain, the applications will get a subdomain of that domain by default. If there isn't one, they won't get a route unless explicitly specified by the user (with epinio push or epinio app update).

[jimmykarily]

This is how others (jitsi) work around the issue: https://marketplace.digitalocean.com/apps/jitsi-server (look at the steps).

[jimmykarily]

Others are also asking for hostname parameters: digitalocean/marketplace-kubernetes#230

[manno]

I'm looking at digitalocean/marketplace-kubernetes#34 which was linked from the others.

Do we have access to kubectl in our deploy.sh script? So, the user could:

0. register a domain, or make up a magic DNS entry
1. put their domain in a configmap in the cluster
2. do the Epinio one click install
3. deploy script extracts domain from cluster

This would mean, we don't have to change any code. If we're fine with changing the helm templates, we could use the lookup template function to retrieve the domain config from the cluster, like we do with the s3 credentials: https://github.com/epinio/helm-charts/blob/main/chart/epinio-installer/templates/manifest.yaml#L10

[agracey]

I wonder if curling out to a "what's my IP" service from deply.sh would allow you to get the external IP and set up a magic DNS. Then the user could finish up by changing that domain to one they control.

[jimmykarily]

@manno I don't think they user has access to the cluster before (or maybe even after) the creation of the droplet. The droplet is created after you start the installation of the one-click installed app.

@agracey I'm imagining digitalocean is running the deploy.sh script on a machine outside the cluster itself. Even if we knew the IP address of that machine, it doesn't mean it's going to be the address of the cluster itself (and thus epinio).

[jimmykarily]

I wonder if this is a different process: https://github.com/digitalocean/droplet-1-clicks
dokku seems to have some access to the droplet's IP address: https://github.com/digitalocean/droplet-1-clicks/blob/master/dokku-20-04/files/etc/update-motd.d/99-one-click#L5

It looks so: https://github.com/digitalocean/marketplace-partners (as compared to: https://github.com/digitalocean/marketplace-kubernetes/)

[jimmykarily]

This is blocked because Epinio need a wildcard system domain to automatically create routes for applications.

One way to solve this from our side would be to switch to manual routes when a system domain is not specified. This would mean applications wouldn't be accessible unless the user manually defined a route for them.

Another possibility would be to have path based routing for apps when a domain is not specified. This may not work for some apps though because I think there are applications the discover the hostname in the request headers and use it to construct links to the various endpoints of the app itself. In those cases, if we used rewrite rules to point 1.2.3.4/myapp to 1.2.3.4/ then the app would think its hostname is 1.2.3.4 which is not true. That IP address won't take the user to the app unless the path is /myapp.

I don't know if supporting manual-only routing is at the top of our priority list. cc @agracey

[jimmykarily]

@manno suggested that we just provide instructions on how to change the system domain after installation. This way, we can install with no system domain (or a dummy one) and then point the user to docs that read something like this:

• get access to the kube cluster (like others are doing: https://marketplace.digitalocean.com/apps/netdata)
• get the original helm values with helm get values ... > values.yaml
• upgrade epinio with the correct system domain: helm upgrade -f values.yaml --set domain=mycorrectdomain.org

This should unblock this story with not additional features needed.

[jimmykarily]

Following the docs, I forked the DO repo and created a branch for Epinio:

digitalocean/marketplace-kubernetes@master...epinio:epinio-first-pr

I tested the scripts and they seem to work fine.

[jimmykarily]

Upstream PR created: https://github.com/digitalocean/marketplace-kubernetes/pull/334/files

[jimmykarily]

Done: https://marketplace.digitalocean.com/apps/epinio. We need to bump the version to the latest now.

[jimmykarily]

New issue: epinio/epinio#1388