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

Document automatic HTTPS #1001

Merged
merged 5 commits into from
Nov 16, 2019
Merged

Document automatic HTTPS #1001

merged 5 commits into from
Nov 16, 2019

Conversation

xhochy
Copy link
Contributor

@xhochy xhochy commented Nov 14, 2019

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.

@betatim
Copy link
Member

betatim commented Nov 14, 2019

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).

doc/https.rst Outdated Show resolved Hide resolved
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
Copy link
Member

@betatim betatim Nov 14, 2019

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 Show resolved Hide resolved
doc/https.rst Outdated Show resolved Hide resolved
doc/https.rst Outdated Show resolved Hide resolved
doc/https.rst Outdated
enabled: true
type: nginx
tls:
- secretName: <jupyterhub-URL>-tls
Copy link
Member

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?

Copy link
Contributor Author

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?

Suggested change
- secretName: <jupyterhub-URL>-tls
- secretName: <jupyterhub-URL-with-dashes-instead-of-dots>-tls

Copy link
Member

@betatim betatim Nov 15, 2019

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

xhochy and others added 3 commits November 15, 2019 17:28
Co-Authored-By: Tim Head <betatim@gmail.com>
Co-Authored-By: Tim Head <betatim@gmail.com>
Co-Authored-By: Tim Head <betatim@gmail.com>
@xhochy
Copy link
Contributor Author

xhochy commented Nov 15, 2019

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.

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.

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

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.

@betatim
Copy link
Member

betatim commented Nov 15, 2019

Sounds good.

Do you want to work on the two non-resolved comments or should we merge now?

@xhochy
Copy link
Contributor Author

xhochy commented Nov 15, 2019

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.

@betatim betatim merged commit c80b26c into jupyterhub:master Nov 16, 2019
@betatim
Copy link
Member

betatim commented Nov 16, 2019

Thanks a lot for writing down how you did it and the nice PR!

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

Successfully merging this pull request may close these issues.

2 participants