Compilation of Dockerfiles with automated builds enabled on the Docker Hub. Not suitable for production environments. These images are under continuous development, so breaking changes may be introduced.

Nearly all images are based on Ubuntu Core 14.04 LTS, built with minimising size/layers and best practices in mind. Dependencies are indicated left to right e.g. cuda-vnc is VNC built on top of CUDA. Explicit dependencies are excluded.

Some builds based on certain software have builds that are triggered on schedule via a cron script to stay up to date on a weekly basis. These are:

• Brainstorm
• Caffe
• DIGITS
• FGLab/FGMachine
• Keras
• Lasagne
• MXNet
• neon
• Pylearn2
• Theano
• Torch

Most containers run as a foreground process. To daemonise (in Docker terminology, detach) such a container it is possible to use:

docker run -d <image> sh -c "while true; do :; done"

It is now possible to access the daemonised container, for example using bash:

docker exec -it <id> bash

To start containers on the host from within a docker container, the following options should be used when running the container:

-v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):$(which docker)

The container also needs to have lxc installed.

Many images rely on CUDA. All images that rely on CUDA have a CUDA 7.5 version, unless specified otherwise, with the "latest" tag on the Docker Hub (an additional "7.5" tag will be available once issue #341 is sorted). Some images also have CUDA 7.0 and 6.5 versions, with the "7.0" and "6.5" tags on the Docker Hub.

These images need to be run on an Ubuntu host OS with NVIDIA Docker installed. The driver requirements can be found on the NVIDIA Docker wiki.

kaixhin/cuda and kaixhin/cudnn have now been deprecated in favour of the official solution.

The scripts in this folder can provide extra functionality, e.g. SSH, to daemonised containers. Further details are available in the folder's readme.

In the future it will hopefully be possible to checkpoint and restore Docker containers easily using CRIU. This would alleviate some issues, such as the inability to restart a VNC image successfully.

Automated Builds on the Docker Hub have several advantages, including reproducibility and security. However the build cluster has the following limits for Automated Builds:

• 2 hours
• 1 CPU
• 2 GB RAM
• 512 MB swap
• 30 GB disk space

The main tip for keeping within the CPU and memory limits is to reduce parallelism/forking processes. Due to their logging system, redirecting stdout/stderr to /dev/null can potentially save a reasonable amount of memory.

Some Dockerfiles have been modified from the work of others. The source for these are:

• CUDA
• Samba
• VNC

If you find this useful in research please consider citing this work.