-
Notifications
You must be signed in to change notification settings - Fork 391
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
Document automatic HTTPS #1001
Document automatic HTTPS #1001
Conversation
Thanks a lot for doing this! It has been a neglected area of the docs. I like that the steps build on the existing docs. For mybinder.org we've created a chart that depends on the binderhub, kubelego and nginx-ingress charts. This means everything there is slightly different from what is described in the guide here. Should we add a note about using helm or not to install certmanager? I don't know which way is better but if we have some information on how to choose it would be useful for readers. My naive assumption when starting to read was that the instructions would be following https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html#installing-with-helm and that guess turned out to be wrong :D Other than this question there are a few nits but I think this can be merged (restarted the CI builds and will check why they are unhappy if they fail again). |
and retrieve the assigned IP using ``gcloud compute addresses list``. | ||
2. Buy a domain name from a registrar. Pick whichever one you want. | ||
3. Set A records to your above retrieved external IP, one for Binder and | ||
one for JupyterHub. We need two distinct subdomains for the routing to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about adding something like: "We suggest you use hub.binder.<domain>
for JupyterHub and binder.<domain>
for your BinderHub. Once you are done your BinderHub will be available at https://binder.<domain>
"? To give people an idea what to name stuff and which of these URLs users will end up having to type.
doc/https.rst
Outdated
enabled: true | ||
type: nginx | ||
tls: | ||
- secretName: <jupyterhub-URL>-tls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use dots .
in secret names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can but I think it is not seen as a good practice. Would the following, longer version work better?
- secretName: <jupyterhub-URL>-tls | |
- secretName: <jupyterhub-URL-with-dashes-instead-of-dots>-tls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Can't commit the suggestion so you have to do it unfortunately
Co-Authored-By: Tim Head <betatim@gmail.com>
Co-Authored-By: Tim Head <betatim@gmail.com>
Co-Authored-By: Tim Head <betatim@gmail.com>
It would probably make sense to have this as a public helm chart; maybe exchange kube-lego with cert-manager as the latter is considered the successor of the first.
I documented the way I got it working, we can work on improving that. I will have a look at using the helm chart also for cert-manager. |
Sounds good. Do you want to work on the two non-resolved comments or should we merge now? |
I worked on the comments and this should be ready for merge once CI passes. |
Thanks a lot for writing down how you did it and the nice PR! |
There is a lot of unofficial, mostly outdated information in Github issues on how to setup HTTPS for a binderhub. This is the way I got it working and would love to have it included in the documentation for clarity.