How to Get Code into a Docker Container

How to Get Code into a Docker Container

18 MAY 2016

When transitioning to a container-based deployment, the question of how to get code into containers often comes up. This article will look at the options we can use to push code into our containers and the factors you should consider with each approach. 

Option 1: Using Git Clone

When deploying directly to a server without using Docker containers, it's common to use Git to clone the code locally from a remote repository. This requires installing an SSH key for private repositories. 

While this technique may work for managed cloud servers, it isn't recommended for container-based deployments for a few reasons:

1. Including SSH keys within container images poses a security risk, as images are often hosted publicly, or privately using a third-party Docker Registry 
2. Containers are designed to be ephemeral, with new versions of code built into a new container image, rather than updating the code of an existing container using Git 
3. Containers should be as small as possible, avoiding the installation of any unnecessary tools

Option 2: Using Shared Volumes

Docker allows for mounting local directories into containers using the shared volumes feature. Just use the -v switch to specify the local directory path that you wish to mount, along with the location where it should be mounted within the running container:

docker run -d -P --name <name of your container> -v /path/to/local/directory:/path/to/container/directory <image name> ...  

Using this command, the host's directory becomes accessible to the container under the path you specify. This is particularly useful when developing locally, as you can use your favorite editor to work locally, commit code to Git, and pull the latest code from remote branches. 

Your application will run inside a container, isolating it away from any processes you have running on your development laptop. The container instance will also have access to other instances, such as those running to provide databases, message brokers and other services. You can read more about how volumes work from the Docker user guide.

In this scenario, all containers on the same host would share the same shared codebase and binaries at the same time. Versioning of code should occur within the Docker image, not at the host volume. Therefore, it's not recommended to use shared volumes in production. 

Option 3: Using the ADD or COPY command

You can use the COPY command within a Dockerfile to copy files from the local filesystem into a specific directory within the container. The following Dockerfile example would recursively add the current working directory into the /app directory of the container image:

# Dockerfile for a Ruby 2.2 container

FROM ruby:2.2

RUN mkdir /app  
COPY . /app  

The ADD command is similar to the COPY command, but has the added advantage of fetching remote URLs and extracting tarballs. 

Note: Some articles may tell you to use the COPY command. As of v0.9.1, COPY has been deprecated in favor of ADD

Correction: The COPY command has not been deprecated as previous mentioned above. The COPY command operates similar to the ADD command, but does not fetch remote URLs or extract tarballs. According to Docker's best practices guide, COPY is recommended for most cases.

This technique is recommended for building production-ready Docker images. We used this technique in our recent posts about deploying Ruby Sinatra and Node Express APIs.

In summary, use Docker ADD COPY for production and shared volumes for development, while avoiding the use of Git within containers for security reasons. If you need more assistance, don't forget to refer to our help pages and community site.