Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use nginx-ingress as entrypoint for all hubs #594

Closed
1 of 4 tasks
yuvipanda opened this issue Aug 9, 2021 · 5 comments
Closed
1 of 4 tasks

Use nginx-ingress as entrypoint for all hubs #594

yuvipanda opened this issue Aug 9, 2021 · 5 comments
Assignees

Comments

@yuvipanda
Copy link
Member

yuvipanda commented Aug 9, 2021

For some hubs that don't have the support chart deployed (#388), we use individual LoadBalancer IPs to expose the hubs. This prevents easily exposing something like grafana, and also adds complexity - some hubs use LoadBalancer, and some use nginx-ingress.

We should move everything to nginx-ingress, and new hubs should all use the nginx-ingress entrypoint.

We need to move the following hubs:

  • Farallon
  • Openscapes
  • Meom-IGE
  • Pangeo-181919 (COESSING hub I think)

We can do so by:

  1. Changing TTL of current DNS entry for a hub to 1minute, so changes can propagate faster. This will take some time to take effect - as long as the current TTL (often 5 minutes) of the record.
  2. Change the record, pointing it to the IP / CNAME of the nginx-ingress load balancer service in the support/ namespace
  3. Set proxy.https.enabled to false for the hub, and unset proxy.service.type. Do a deploy immediately. The autohttps deployment should go away, and proxy-public should change type. You might have to delete the proxy-public service before doing a deploy, or the deploy might fail, since it'll try to change the service from a LoadBalancer to a ClusterIP (and this is often not fully supported)
  4. Make this change in a PR and merge it

This might lead to a minute or two of downtime, so has to be done at a time that'll hopefully affect nobody.

@yuvipanda yuvipanda added this to Ready to prioritize in Deliverables Backlog Aug 9, 2021
@damianavila
Copy link
Contributor

We should move everything to nginx-ingress, and new hubs should all use the nginx-ingress entrypoint.

So this means we are deploying support in all our clusters, right? I would agree with that.

@choldgraf choldgraf moved this from Ready to prioritize ➡️ to Managed JupyterHub Service in Deliverables Backlog Aug 15, 2021
@choldgraf
Copy link
Member

I'm setting this as medium priority and adding to our backlog now...these kinds of "standardize and simplify our infrastructure" issues seem particularly important to make sure that we can iterate quickly and without confusing ourselves in the future

@yuvipanda yuvipanda removed this from Managed JupyterHubs Infrastructure in Deliverables Backlog Aug 23, 2021
@damianavila
Copy link
Contributor

AFAIK, we have support deployed in all of our clusters.
In fact, recently #1091 was merged... which is using nginx-ingress to expose Prometheus with basic auth.
@yuvipanda, can you confirm somehow this was already done for openscapes (I guess when it was transitioned to use eksctl) and the only remaining ones are meom-ige and farallon? (Pangeo-181919 does not exist anymore, IIRC).

@yuvipanda
Copy link
Member Author

This is done now, thanks to @GeorgianaElena!

@damianavila
Copy link
Contributor

For future readers, Farallon is being decommissioned here: #1454.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants