I don't care about Galaxies, you guys are in another class (and I don't have a way to test that use case anymore.)
If somebody wanted to donate a galaxy to the Moonlander project, then I would consider it!
But frankly I've already had one, and it was honestly too much maintenance overhead for me. I still self-host a planet though, I'd like to cover these three use cases:
- planet running on your Mac laptop or Mac Mini, fronted by MetalLB, TLS cert in the pier via
%acme
- planet running on a Linux machine, also fronted by MetalLB, TLS cert in the pier
- planet running on a Kubernetes pod, still fronted by LoadBalancer, again, TLS in the pier
The big idea that I haven't seen anybody else cover in detail is to get the front-end LoadBalancer running a Host-Based router, where port 80 on the front-end goes to port 80 (or port 8080) on the backend, and port 443 on the front-end goes to port 443 (or port 8443) on the backend. Typically Ingress controllers will redirect port 80 to 443, and terminate TLS, so this is an extraordinary use case of Kubernetes Ingress. It can be done with NGINX Ingress though. (That's what I'm doing.)
TLS in the Ingress controller is probably a lot easier as an alternative, might be worth covering that too, or as a stepping stone/foot in the door. Planet behind your NAT gateway/SOHO router is also pretty easy, but not interesting for me because I want to take my single IPv4 address and share it between many backend services, including having multiple HTTP services all listening on the same IP port 80/443. I'm using Cozystack; it supports this use case with Ingress-NGINX and MetalLB.
Native Planet has their own solution AFAIK - I'd be happy to consider mentioning it in the docs as well, but I am leery of increasing the scope any more than this ticket already does.
(Moonlander is supposed to get you Kubernetes events out of Managed Cluster B into Management Cluster A, and get you admin access from in Cluster A out to Cluster B, copying a static Kubeconfig with a bearer token from the managed cluster into the manager. OIDC is out of scope, but may be considered in the future after that stuff works - since we already have it.)
Ref:
I don't care about Galaxies, you guys are in another class (and I don't have a way to test that use case anymore.)
If somebody wanted to donate a galaxy to the Moonlander project, then I would consider it!
But frankly I've already had one, and it was honestly too much maintenance overhead for me. I still self-host a planet though, I'd like to cover these three use cases:
%acmeThe big idea that I haven't seen anybody else cover in detail is to get the front-end LoadBalancer running a Host-Based router, where port 80 on the front-end goes to port 80 (or port 8080) on the backend, and port 443 on the front-end goes to port 443 (or port 8443) on the backend. Typically Ingress controllers will redirect port 80 to 443, and terminate TLS, so this is an extraordinary use case of Kubernetes Ingress. It can be done with NGINX Ingress though. (That's what I'm doing.)
TLS in the Ingress controller is probably a lot easier as an alternative, might be worth covering that too, or as a stepping stone/foot in the door. Planet behind your NAT gateway/SOHO router is also pretty easy, but not interesting for me because I want to take my single IPv4 address and share it between many backend services, including having multiple HTTP services all listening on the same IP port 80/443. I'm using Cozystack; it supports this use case with Ingress-NGINX and MetalLB.
Native Planet has their own solution AFAIK - I'd be happy to consider mentioning it in the docs as well, but I am leery of increasing the scope any more than this ticket already does.
(Moonlander is supposed to get you Kubernetes events out of Managed Cluster B into Management Cluster A, and get you admin access from in Cluster A out to Cluster B, copying a static Kubeconfig with a bearer token from the managed cluster into the manager. OIDC is out of scope, but may be considered in the future after that stuff works - since we already have it.)
Ref:
%acme- unify issues urbit/urbit#7184