Running the Pod after mounting hostPath

Creating and testing the pod#

Let’s create the Pod and check whether, this time, we can execute Docker commands from inside the container it’ll create.

Since the image is already pulled, starting the Pod should be almost instant.

Let’s see whether we can retrieve the list of Docker images.

We executed docker image ls command and shortened the output by limiting its formatting only to Repository. The output is as follows. The output of the file may vary because of addons enabled on the cluster.

Even though we executed the docker command inside a container, the output clearly shows the images from the host. We proved that mounting the Docker socket (/var/run/docker.sock) as a Volume allows communication between Docker client inside the container, and Docker server running on the host.

Playing around with docker#

Let’s enter the container and see whether we can build a Docker image.

To build an image, we need a Dockerfile as well as an application’s source code. We’ll continue using go-demo-2 as the example, so our first action will be to clone the repository.

We used apk add to install git.On the other hand, docker and many other images use alpine as the base. If you’re not familiar with alpine, it is a very slim and efficient base image, and we strongly recommend that you use it when building your own.

Images like debian, centos, ubuntu, redhat, and similar base images are often a terrible choice made because of a misunderstanding of how containers work.

alpine uses apk package management, so we invoked it to install git. Next, we cloned the vfarcic/go-demo-2 repository, and, finally, we entered into the go-demo-2 directory.

Let’s take a quick look at the Dockerfile.

Since this course is dedicated to Kubernetes, we won’t go into details behind this Dockerfile, but only comment that it uses Docker’s multi-stage builds. The first stage downloads the dependencies, it runs unit tests, and it builds the binary. The second stage starts over. It builds a fresh image with the go-demo binary copied from the previous stage.

ℹ️ We hope you’re proficient with Docker and there’s no need to explain image building further.

Let’s test whether building an image indeed works.

We executed the docker image build command, followed by docker image ls. The output of the latter command is as follows. As mentioned earlier it may vary from system to system.

If we compare this with the previous docker image ls output, we’ll notice that, this time, a few new images are listed. The golang and alpine images are used as a basis for each of the build stages. The vfarcic/go-demo-2 is the result of our build. Finally, <none> is only a left-over of the process and it can be safely removed.

The docker system prune command removes all unused resources. At least, all those created and unused by Docker. We confirmed that by executing docker image ls again. This time, we can see the <none> image is gone.

Destroying the Pod#

We’ll destroy the docker Pod and explore other usages of the hostPath Volume type.

hostPath is a great solution for accessing host resources like /var/run/docker.sock, /dev/cgroups, and others. That is, as long as the resource we’re trying to reach is on the same node as the Pod.

Let’s see whether we can find other use-cases for hostPath.

Try it yourself#

A list of all the commands used in the lesson is given below.