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:
- Including SSH keys within container images poses a security risk, as images are often hosted publicly, or privately using a third-party Docker Registry
- 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
- Containers should be as small as possible, avoiding the installation of any unnecessary tools
Option 2: 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: ADD command
You can use the ADD 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 ADD . /app
ADD also has the advantage of fetching remote URLs and extracting tarballs.
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.
In summary, use Docker ADD for production and shared volumes for development, while avoiding the use of Git within containers for security reasons.