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.

Peter Mortensen
  • 147
  • 5
Morty
  • 131
  • 3
  • How do you think you may run a container without the daemon ? – Tensibai Jun 18 '18 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 '18 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: https://docs.docker.com/engine/images/architecture.svg

     – Kajsa Gauza Mar 24 '19 at 22:58

4 Answers4

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.

Peter Mortensen
  • 147
  • 5
13dimitar
  • 757
  • 4
  • 12
  • 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 '18 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 '18 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 '18 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 '18 at 13:19
  • Tensibat: Yes I understand - but this isn't obvious until you know. ;-) – Morty Jun 18 '18 at 13:30
  • @13dimitar: OK thanks that makes sense. So there is really no way around it when it works like that. But how about my second part of the question - surely it must be possible to write the Dockerfile (or associated command line parameter and/or Maven parameters passed to Docker) so that the end-result is an Image on the file system that I can then decide to import on another server? – Morty Jun 18 '18 at 13:31
  • @Morty not that I know, you do a docker image build then a docker image save if you want a tarball or docker image push to a registry – Tensibai Jun 19 '18 at 07:39
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.

Peter Mortensen
  • 147
  • 5
BMitch
  • 3,290
  • 9
  • 18
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.

Rob Wells
  • 123
  • 5
0

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

Not all possible Dockerfile options might be supported.

https://github.com/GoogleContainerTools/kaniko

Ta Mu
  • 6,772
  • 5
  • 39
  • 82