3

I am trying to get my feet wet with Docker/containers. I started with this tutorial:

Getting Started · Spring Boot with Docker

It works fine, but I was surprised it is necessary to have the "dockerd" daemon running to build an image. It connects to it using localhost and a port number as part of executing the Maven build. Why is this required (and can it be avoided)? I mean, in many cases the image will have to be run on a separate platform anyway. It is particularly annoying, because I am building on Windows where Docker requires you to have Hyper-V enabled, which causes other issues (for instance that you can't use VMware on the same machine).

Due to the problems, I resorted to building it all inside a Linux VM (which then ran the Docker daemon).

Another thing which might be related to the above: It seems the build process doesn't leave the image on disk; it is installed directly into the repository managed by the Docker daemon. I can then export the image from the command line, and I suppose (haven't tried) this image could be moved to another machine and run from there. But how do I build "just" the image without having it deployed anywhere, etc.? It just needs to produce the artifacts in the local file system and leave it at that. Maybe that would also remove the requirement for having Docker running?

The command the tutorial uses for running Maven is:

./mvnw install dockerfile:build

However, trying alternatives to "install" (such as "package", etc.) seemingly doesn't change the behavior.

3
  • How do you think you may run a container without the daemon ?
    – Tensibai
    Jun 18, 2018 at 12:19
  • 1
    I don't wish to run the container - I only wish to build the image that I can then take to another system and run from there.
    – Morty
    Jun 18, 2018 at 13:09
  • You need Hyper-V on Windows machine when you work with Linux Containers, because Hyper-V manages MobyLinux virtual machine. You don't need Hyper-V if you work with Windows Containers in process isolation mode and have the newest Docker and Windows 10 Pro updated to ver. 1809 (or just use even earlier Windows Server). Spring Boot tutorial assumes Linux is needed, so you must run Docker in Linux VM. Btw. dockerd is the main daemon; here you have architecture explained visually: docs.docker.com/engine/images/architecture.svg Mar 24, 2019 at 22:58

4 Answers 4

7

Each command in the Dockerfile is processed as a separate step. Every step from the build process gets executed in a dedicated container. It starts from Step 1 (the first command in the Dockerfile). That step is run in a container and if it is successful, a commit to a temporary image (let's call it image A) takes place. Then, Step 2 is executed in a container which is run from image A ... and so on until the final step is executed successfully. And as Tensibai commented - how do you think to run a container without the daemon?

So, yes - building a docker image requires the docker daemon to be running.

7
  • Normally, in other execution frameworks/platforms, compiling/building an application does not require you to have an instance of said platform running on the machine where you build. I.e. you can compile a WAR file for a Tomcat-server without having a Tomcat running on the server where you run the compilation etc. After all, the compilation process is just a matter of reading and processing some files and writing a typically deterministic result, and this doesn't usually involve calling services etc. There's no obvious reason why the same thing couldn't be done for Docker.
    – Morty
    Jun 18, 2018 at 13:12
  • So if I understand you correctly - it is because the designers of the Docker build system decided to execute the building steps inside Docker container? This might have merits but it has the somewhat unusual implication that you need to be running the target platform itself on the platform from where you build.
    – Morty
    Jun 18, 2018 at 13:14
  • it is because the designers of the Docker build system decided to execute the building steps inside Docker container - yes, exactly. It starts from Step 1 (the first command in the Dockerifle). It is run in a container and If it is successful, a commit to an image (let's call it image A) happens. Then, Step 2 is executed in a container which is run from image A .. and so on until the final step is executed successfully.
    – 13dimitar
    Jun 18, 2018 at 13:16
  • @Morty re "There's no obvious reason why the same thing couldn't be done for Docker." => you run OS commands in a dockerfile (maybe cp/move/launch maven which is a program), you need an OS to run them, a container is an isolated OS, so you need to start it.
    – Tensibai
    Jun 18, 2018 at 13:19
  • Tensibat: Yes I understand - but this isn't obvious until you know. ;-)
    – Morty
    Jun 18, 2018 at 13:30
3

The Docker client is a CLI interface to the dockerd REST API. Very little happens in the client itself. Docker performs build steps on the dockerd engine and changing this would be a non-trivial task. Each RUN step creates a temporary container to execute the command and gather the resulting container filesystem as a new layer. The build cache is maintained as images on the server. And each layer of the image is managed by the storage driver within the Docker engine.

There are various attempts to try to remove this dependency, but the biggest stumbling block for each will be the temporary containers used by RUN which require a container runtime and root access on the server to set up.

0

Rootless container builds without using a docker daemon are possible using the Buildah and Podman utilities.

N.B. Podman has vendored in the Buildah library so it's all Buildah under the covers.

0

With Kaniko, you can build Docker images without Docker daemon.

Not all possible Dockerfile options might be supported.

https://github.com/GoogleContainerTools/kaniko

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.