Deploying Docker images to a server without using a Docker Registry

; Date: Wed Aug 30 2017

Tags: Docker

We formerly deployed server applications to a Linux server using manual processes. An advanced team might use shell scripts to automate deployment. Over time tools like Chef or Ansible and more grew to handle ever-more-complex server application deployment scenarios. A few years ago, Docker came onto the scene with a whole new approach involving building a "Container" housing a complete operating system image that runs your application. Having built the Container, it's easy to ship that container to a server or run it on your laptop. The compelling gain is having the exact same development environment on your laptop as is deployed to your servers. Using the EXACT same environment streamlines your work by removing a ton of potentially destabilizing variables.

The preferred method is to build a Docker container image on your laptop, or on a build server, and upload the image to a Docker Registry. The image can then be downloaded from the Registry onto any number of systems.

What if you don't want to, or cannot, use a Registry? You could instead deploy the source code to the server, and build the container image on the server. That's a very unwise move, and it's better to ship the container image to the server. Turns out that is easy to do.

The typical workflow is to build the image, as said above, on your laptop or a build server. The image is then copied to a Docker Registry such as Docker Hub, or a self-hosted Registry. The outline is something like:

$ docker build -t group-name/image-name .
$ docker push group-name/image-name

The latter command pushes the container image to a registry. By default it pushes to Docker Hub, but it can also push to a self-hosted registry.

But there are many reasons to not use Docker Hub, and it might be too burdensome to self-host a Docker Registry.

The Docker CLI tool has a docker image command that let's you export a container image to a tarball. That tarball can be copied elsewhere, such as your deployment server. That tarball can then be imported into the Docker environment on that server.

The first step is:

$ docker build -t group-name/image-name .
$ docker image save -o image-name.tar group-name/image-name

The second command exports the container into a tarball. You're free to compress the tarball if you prefer, of course.

Then you upload the tarball to the server, and execute:

$ docker image import image-name.tar image-name

This imports the container image so it can be used on the server. Once imported you can run the container image as normal.

Um... a CORRECTION on the incorrect advice above

I tried replicating the above advice a day later and got this problem upon running the container:

$ docker run -d --name image-name --expose 8080 -p 8080:8080 --restart always -t  group-name/image-name
docker: Error response from daemon: No command specified.

Some DuckDuckGo searching turned up a Github issue thread where it's said that docker export and docker import loses "metadata" including the command in the Dockerfile. The Dockerfile I used in this case does use an ENTRYPOINT and therefore had a command. But since using docker import causes that to be stripped, the container indeed did not have a Command.

The solution is to use docker load on the target machine as so:

$ docker load < image-name.tar
decd896c7365: Loading layer [==================================================>]  41.37MB/41.37MB
Loaded image: group-name/image-name:latest

And that results in:

$ docker run -d --name mage-name --expose 8080 -p 8080:8080 --restart always -t  group-name/image-name
$ docker ps -a
CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS              PORTS                    NAMES
929c279e95fe        group-name/image-name   "sh -c 'java $JAVA..."   4 seconds ago       Up 3 seconds>8080/tcp   mage-name

About the Author(s)

( David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.