Initial version. #1
Conversation
(c) Copyright IBM Corp. 2016
(c) Copyright IBM Corp. 2016
| ## Prerequisites | ||
|
|
||
| * This deployment uses Docker for all the things. It assumes that you wiil be using [Docker Machine](https://docs.docker.com/machine/overview/) and [Docker Compose](https://docs.docker.com/compose/overview/) on a local workstation or laptop to create, build, and run Docker images on a remote host. It requires [Docker Toolbox](https://www.docker.com/products/docker-toolbox) 1.11.0 or higher. See the [installation instructions](https://docs.docker.com/engine/installation/) for your environment. | ||
| * This example configures JupyterHub for HTTPS connections (the default). As such, you must provide TLS certificate chain and key files to the JupyterHub server. If you do not have your own certificate chain and key, you can either create self-signed versions, or obtain real ones from [Let's Encrypt](https://letsencrypt.org) (see the [letsencrypt example](examples/letsencrypt/README.md) for instructions). |
There was a problem hiding this comment.
@jtyberg This is great content :D We have instructions on creating a self signed cert/key in the Notebook docs if you wish to link to it [https://jupyter-notebook.readthedocs.org/en/latest/public_server.html#using-ssl-for-encrypted-communication]
|
Thanks for putting this together, @jtyberg ! This is really awesome 🍰 |
|
Wow! That was quick @jtyberg. Thank you! I'll give it a proper review in the morning. 🌆 |
(c) Copyright IBM Corp. 2016
In Docker 1.10, including protocol in DOCKER_HOST caused failure to connect to daemon on host machine. Must have fixed in 1.11. (c) Copyright IBM Corp. 2016
|
FWIW, I just used these instructions to deploy JupyterHub to an AWS EC2 instance...from a Windows machine. Took me about 30 minutes, including the wait time for pulling images from Docker hub, and conquering the AWS EC2 learning curve (it was my first time). It took me longer to find and upgrade the Windows machine. |
|
@jtyberg That's great. Impressive since AWS learning curve and UI leave much to be desired. I got halfway through the tutorial on Digital Ocean Ubuntu server last night and on an IBM Softview instance. |
|
@jtyberg Do you have any thoughts on how the JHub admin might upgrade the docker image(s) used over time? For example, when the all-spark-notebook image goes through a few revs, I'll want to deploy that as the basis for my notebook. Or, for example, when JHub itself gets improved, I might want to upgrade. I'm hoping (fingers crossed) that the former is as easy as rebuilding the notebook image on the Docker host and letting the next spawn pick it up. If so, that might be worth documenting. I image the latter is harder and can be figured out in follow-on PRs. |
|
@parente Good question. I've actually changed the spawn image extensively during this exercise. In the best case scenario, where the notebook Docker image is tagged with the same tag, it simply requires rebuilding the notebook image. However, if you tag the notebook image differently, then you need to let JHub know about the change. Unfortunately, this requires a restart of JHub. But even in this situation, that's not so bad. In this deployment, cookies are persisted to a Docker volume, so there would be a blip in service as JHub restarts, but users would not have to login again. Updating the JHub image is another matter. The outage would depend on what's changed in JHub, and what effect those changes have on the spawned image, if any. For example, if there is little change to the command line args that startup a single-user notebook, then the notebook image would not need to change, and you would just need to rebuild the JHub image, and once again, restart JHub. |
|
Great start, thanks @jtyberg! |
Add postgres envars
An initial version.
A few points:
dockeroperations. That said, I'm open to removing the Machine dependency, but it would force users to 1) install Docker daemon and Compose manually on host (as opposed to Machine doing it for them), 2) git clone this repo on the host, 3) login to the host to perform all operations. Like I said, this is not my preferred mode of operation.