In words and pictures, how to create a simple throwaway server, on a cheap, commercial web host, that automatically runs a personal Jupyter notebook server, with a light covering of OU branding., via a prebuilt Docker container image… (More significant customisations are, of course, possible…)
Step 1 (you only need to do this once)
Get a Digital Ocean account.
A downside of this is that you probably have to give you credit card details to get an account. The upside is that this link should get you $100 free credit that you won’t ever get round to spending anyway.
At this point, I realise many people won’t get past this step… If you’re in HE, your institution should really be able to give you access to online servers that can spin up as required. If they don’t, hassle the Library, because they should be providing you access to this sort of environment if your department can’t or won’t.
[I speak in terms of ideals, of course, which is why I am using a personal Digital Ocean account…]
There are alternative routes, exemplified in posts throughout this blog, but naysayers will just pick grief with those too… At the end of the day, things like Digital Ocean offer commodity compute, and folk in computing education at least should be aware of them, what sorts of thing they offer, and how to work with them in general…
Select your own Docker server environment type. Digital Ocean calls servers droplets and the Docker server can be found in the marketplace:
Pedants I work with would probably claim that’s four steps and that it’s already too hard.
Select the server size. Some applications require grunt, but for now let’s be a cheapskate with something that approximates an OU min spec machine. (This sort of discipline is also good for academics with fast/whizzy machines so they can see how the rest of the world has to get by…)
Select where in the world you want your server to start up.
We’re going to get our server to automatically download and run a very lightly customised Jupyter notebook server:
Copy and paste both the following lines into the user data area.
The first one tells the start-up-er-er what sort of script it is. If you have trouble remembering the order of symbols at the start, it reads hash (
#) bang (
/bin/bash says it’s a bash script.
docker run -p 80:8888 -e JUPYTER_TOKEN=MyP45SwerD ousefulcoursecontainers/oubrandednotebook
The second line is a Docker run command. What it does is download a minimally branded, basic Jupyter notebook server Docker image (
ousefulcoursecontainers/oubrandednotebook) and launch a container from it, exposing it to the default http port 80.
If you have Docker installed on your own computer, you should be able to run something like:
docker run -p HOSTPORT:8888 -e JUPYTER_TOKEN=MyP45SwerD ousefulcoursecontainers/oubrandednotebook , where
HOSTPORT is the port number on host you want to visit the notebook server on in your browser at
As part of the command, we specify a default plain text password like token that will add a small level of security. In this case, I’m setting the token to
Optionally set a server name and then create your server:
Wait for the server to boot…
When the server is launched, you should see a public IP address for it that you can copy if you hover your mouse cursor over it…
It’s probably not quite ready to use yet, though… It will need a minute or two to download the Docker container we told it to start up with…
In your browser, paste in the server IP address. If you don’t get a response, it’s still sorting its bits out. Refresh the browser page every so often if the page load appears to stop.
After a minute or two, you should see your notebook login page:
Log in to the server using the password you set in the user data area (for example,
MyP45SwerD). You can either use the token to set a browser cookie on the notebook to let you in, or use it set a new password on the notebook.
Play with your notebook…
When you’re done playing, you can delete the kill the server / droplet so you don’t keep paying for it (it’s metered by the hour or part thereof).
You’ll lose everything inside the server, so the confirmation prompt is in your own best interest…
And that’s it…
If we want to create custom notebook environments, seeded with notebooks and with a more complex environment installed (specific Python packages, for examples, or other servers we want running, we can create another container on top of our minimal container and launch that. (You can see the repo that adds the basic OU branding to the official Jupyter base notebook image here.)
We can also version containers (for example, for specific modules, modules presentations, tutorials, etc).
And as I demonstrated in the previous blogpost, we can also use a similar technique to provide a view of a desktop application via a browser or remote desktop connection.