How to Build and Shipping Images in Docker

Building & Shipping Images

Docker can build images automatically by reading the instructions from a Dockerfile, a text file that contains all the commands, in order, needed to build a given image. Dockerfiles adhere to a specific format and use a specific set of instructions. Dockerfile will define what goes on in the environment inside your container. Access to resources like networking interfaces and disk drives is virtualized inside this environment, which is isolated from the rest of your system, so you have to map ports to the outside world, and be specific about what files you want to “copy in” to that environment. However, after doing that, you can expect that the build of your app defined in thisDockerfile will behave exactly the same wherever it runs.

Dockerfile

Create an empty directory and put this file in it, with the name Dockerfile. Take note of the comments that explain each statement

This Dockerfile refers to a couple of things we haven’t created yet, namely app.py and requirements.txt. Let’s get those in place next.

The app itself Grab these two files and place them in the same folder as Dockerfile. This completes our app, which as you can see is quite simple. When the above Dockerfile is built into an image, app.py, and requirements.txtwill be present because of that Dockerfile’s ADD command, and the output from app.py will be accessible over HTTP thanks to the EXPOSE command. 

Now we see that pip install -r requirements.txt installs the Flask and Redis libraries for Python, and the app prints the environment variable NAME, as well as the output of a call to socket.gethostname(). Finally, because Redis isn’t running (as we’ve only installed the Python library, and not Redis itself), we should expect that the attempt to use it here will fail and produce the error message.

Note: Accessing the name of the host when inside a container retrieves the container ID, which is like the process ID for a running executable. 

Build the app

That’s it! You don’t need Python or anything in requirements.txt on your system, nor will building or running this image install them on your system. It doesn’t seem like you’ve really set up an environment with Python and Flask, but you have. 

Run the app

Run the app, mapping your machine’s port 4000 to the container’s EXPOSEd port 80 using -p: 

docker run -p 4000:80 friendlyhello  

You should see a notice that Python is serving your app at http://0.0.0.0:80. But that message is coming from inside the container, which doesn’t know you mapped to port 80 of that container to 4000, making the correct URL http://localhost:4000. Go to that URL in a web browser to see the display content served up on a web page, including “Hello World” text, the container ID, and the Redis error message. 

You can also use the curl command in a shell to view the same content

Note: This port remapping of 4000:80 is to demonstrate the difference between what you EXPOSEwithin the Dockerfile, and what you publish using docker run -p. In later steps, we’ll just map port 80 on the host to port 80 in the container and use http://localhost.

Hit CTRL+C in your terminal to quit. 

Now let’s run the app in the background, in detached mode:

You get the long container ID for your app and they are kicked back to your terminal. Your container is running in the background. You can also see the abbreviated container ID with docker ps (and both work interchangeably when running commands):

You’ll see that CONTAINER ID matches what’s on http://localhost:4000.

Now use docker stop to end the process, using the CONTAINER ID, like so: 

Share your image

To demonstrate the portability of what we just created, let’s upload our built image and run it somewhere else. After all, you’ll need to learn how to push to registries when you want to deploy containers to production.

A registry is a collection of repositories, and a repository is a collection of images—sort of like a GitHub repository, except the code is already built. An account on a registry can create many repositories. The dockerCLI uses Docker’s public registry by default. 

Note: We’ll be using Docker’s public registry here just because it’s free and pre-configured, but there are many public ones to choose from, and you can even set up your own private registry using Docker Trusted Registry. 

Log in with your Docker ID

If you don’t have a Docker account, sign up for one at cloud.docker.com. Make note of your username.

Log in to the Docker public registry on your local machine. 

docker login 

Tag the image

The notation for associating a local image with a repository on a registry is username/repository: tag. The tag is optional, but recommended, since it is the mechanism that registries use to give Docker images a version. Give the repository and tag meaningful names for the context, such as get-started:part1. This will put the image in the get-started repository and tag it as part1. Now, put it all together to tag the image. Run docker tag image with your username, repository, and tag names so that the image will upload to your desired destination. 

The syntax of the command is: 

docker tag image username/repository:tag

For example:

docker tag friendlyhello john/get-started:part1

For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.