Introduction

What is Docker?

Docker is an application that allows you to isolate the resources (libraries, packages, binaries, runtimes...) that an application needs through a process called Containerization. This helps in developing and deploying applications in a predictable and portable way. This is done by packaging all the dependencies along with the application in a standardized way called a Docker Image. A Docker Container is the isolated environment you get when you run a Docker Image.

This brief introduction is enough for now and I shall introduce other concepts as we encounter them. Refer here and here if you need more information.

Scenarios of usage

We shall assume that you have one of the following scenarios where containing (isolating, compartmentalizing) the environment is useful.

Scenario 1 - Only local development

• You have a local machine on which you want to develop some code with admin privileges on it and the required hardware capabilities.
• Due to these admin privileges you can install any library/package you want on which your planned code depends and also Docker.
• However, there are multiple versions of a library/package and you want to build/test your code with each of these versions separately.
• In this case, a suitable option is to have separate coding environments, i.e. Docker containers with each environment containing only one version of the library.

Scenario 2 - Develop on shared remote machine where your do not have admin privileges

• You have access to a shared remote machine but you do not have admin privileges to install anything on it.
• Docker is installed on the remote machine and you are part of the docker user group. If you are not part of the docker group please ask the administrator of the remote machine to add you to the group.
• In this case, the libraries/packages you install using Docker are contained by design.
• We shall further assume that your local machine is only there for providing you access to the remote machine. Nothing else can be done on the local machine.

This document will help you for both of these cases.

Workflows

Workflow 1 - Local followed by remote

• This workflow is as follows:
  • Develop your code on your local machine.
  • Test it within a Docker container in your local machine, that mimics the Docker container of your remote machine.
  • If the test is successful, then build a Docker image and transfer it to the remote machine.
  • Run the image on your remote machine.
• If you look at guides on the internet, most of them follow this workflow. This is because Docker was built primarily to ease deployment during production.
• However, in order to use this workflow, your local machine should be capable of building the code in the first place. This may not always be true, e.g. your local system may not have the hardware capabilities (e.g. GPUs), or you are not allowed to install anything on the local machine.

Workflow 2 - Development inside a Docker Container

• This workflow is as follows:
  • You run a Docker image and go into the contained environment.
  • Make changes to your code, build it, install additional libraries/packages as necessary and do whatever else you need.
  • Save these changes to the Docker image so that the next time to visit it, the changes remain.
• This workflow is suitable for both the scenarios described above.
  • In Scenario 1, the Docker image is on your local machine. In fact, you have one docker image for each version of the library/package.
  • In Scenario 2, the Docker image is on the remote machine and all the work is done only on the remote machine.

These workflows are described in detail towards the end of this document here. If you already have Docker installed and know how it works, skip over to that section directly.