<p>Each command in the <a href="https://docs.docker.com/engine/reference/builder/" rel="nofollow noreferrer">Dockerfile</a> 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?</p>

<p>So, yes - building a docker image requires the docker daemon to be running.</p>

CC BY-SA 4.0
2018-06-18T13:12:13.717Z
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
CC BY-SA 4.0
2018-06-18T13:14:38.110Z
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
CC BY-SA 4.0
2018-06-18T13:16:43.420Z
`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
CC BY-SA 4.0
2018-06-18T13:19:19.763Z
@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
CC BY-SA 4.0
2018-06-18T13:30:21.663Z
Tensibat: Yes I understand - but this isn't obvious until you know. ;-)
Morty
CC BY-SA 4.0
2018-06-18T13:31:52.940Z
@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
CC BY-SA 4.0
2018-06-19T07:39:59.397Z
@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
CC BY-SA 4.0
2018-06-18T12:40:46.893Z
2018-07-22T07:53:20.093Z
2018-07-22T07:53:20.093Z
13dimitar
<p>The Docker client is a CLI interface to the <a href="https://docs.docker.com/engine/reference/commandline/dockerd/" rel="nofollow noreferrer">dockerd</a> 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 <code>RUN</code> 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.</p>

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

CC BY-SA 4.0
2018-06-18T14:26:54.493Z
2018-07-22T07:53:44.670Z
2018-07-22T07:53:44.670Z
BMitch
<p>With Kaniko, you can build Docker images without Docker daemon.</p>

<p>Not all possible Dockerfile options might be supported.</p>

<p><a href="https://github.com/GoogleContainerTools/kaniko" rel="nofollow noreferrer">https://github.com/GoogleContainerTools/kaniko</a></p>

CC BY-SA 4.0
2020-02-04T07:52:34.847Z
2020-02-04T07:52:34.847Z
Ta Mu
<p>Rootless container builds without using a docker daemon are possible using the <a href="https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/" rel="nofollow noreferrer">Buildah and Podman</a> utilities.</p>

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

CC BY-SA 4.0
2020-01-31T14:43:58.177Z
2020-01-31T14:43:58.177Z
Rob Wells
<p>I am trying to get my feet wet with Docker/containers. I started with this tutorial:</p>

<p><em><a href="https://spring.io/guides/gs/spring-boot-docker/" rel="nofollow noreferrer">Getting Started · Spring Boot with Docker</a></em></p>

<p>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).</p>

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

<p>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?</p>

<p>The command the tutorial uses for running Maven is:</p>

<pre><code>./mvnw install dockerfile:build
</code></pre>

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

CC BY-SA 4.0
2018-06-18T12:19:00.193Z
How do you think you may run a container without the daemon ?
Tensibai
CC BY-SA 4.0
2018-06-18T13:09:23.497Z
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
CC BY-SA 4.0
2019-03-24T22:58:07.360Z
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
<docker><maven>
Does building a Docker image require the Docker daemon to be running?
Morty
# Does building a Docker image require the Docker daemon to be running?

(Asked by: username_0 on 2018-06-18)

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.

**Tags:** docker, maven

> **Comments:**
> **username_1**: How do you think you may run a container without the daemon ?  
> **username_0**: 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.  
> **username_2**: 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  

---

## 4 answers

### Answer by username_3 on 2018-06-18. Score: 7

Each command in the [Dockerfile](https://docs.docker.com/engine/reference/builder/) 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 username_1 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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: 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.  
> **username_3**: `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.  
> **username_1**: @username_0 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.  
> **username_0**: Tensibat: Yes I understand - but this isn't obvious until you know. ;-)  
> **username_0**: @username_3: 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?  
> **username_1**: @username_0 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  

---

### Answer by username_4 on 2018-06-18. Score: 3

The Docker client is a CLI interface to the [dockerd](https://docs.docker.com/engine/reference/commandline/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.


---

### Answer by username_5 on 2020-02-04. Score: 0

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

Not all possible Dockerfile options might be supported.

<https://github.com/GoogleContainerTools/kaniko>


---

### Answer by username_6 on 2020-01-31. Score: 0

Rootless container builds without using a docker daemon are possible using the [Buildah and Podman](https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/) utilities.

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


---

