<p>There is a good practice called multistage build, in which you have one Dockerfile containing various image definitions that depend from one another, this helps you keep all your images updated with the latest changes and copy artifacts from one to another; this also helps reducing the image size if done right.
A simple example is like the following:</p>

<pre><code>FROM golang:1.9.2 as builder
ENV CGO_ENABLED=0 GOOS=linux
RUN go build -a \
             -installsuffix cgo \
             -o app .

FROM alpine:3.6
WORKDIR /root/
COPY --from=builder app .
CMD ["./app"]
</code></pre>

<p>In this example, in the first image you compile a go example application using the golang official image and then, using alpine to keep the size of the image small, you copy the executable to a new image and execute it.
This way you can keep your containers in one file and build all at the same time or you can build just a target stage:</p>

<pre><code>docker build --target builder -t somehub/sometag:latest .
</code></pre>

<p>You can even use remote images as stages:</p>

<pre><code>COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
</code></pre>

<p>If you need anymore information regarding Docker multi-stage builds you can find it in the following <a href="https://docs.docker.com/develop/develop-images/multistage-build/" rel="nofollow noreferrer">link</a>.</p>

CC BY-SA 4.0
2019-05-03T15:33:20.930Z
2019-05-03T15:33:20.930Z
Daniel Cortés
<p>It's not good idea to store multiple Dockerfiles inside one repository.
The best way is 1 repo 1 Dockerfile.</p>

CC BY-SA 4.0
2018-10-04T04:48:26.743Z
2018-10-04T04:48:26.743Z
Meiram Chuzhenbayev
<p>I have various Jenkins agents images and I am trying to add automation to it.</p>

<p>I have a base java image called <code>agent-base</code> and those who inherit from that one e.g. <code>agent-ansible</code>, <code>agent-terraform</code> and so on. In some case, I even have a 3rd level.</p>

<p>My questions:</p>

<ul>
<li>What would be the best way to update the child images when a parent is updated? Downstream pipelines perhaps?</li>
<li>Or should I keep all the Dockerfiles in a single repository and have a script that know the images hierarchy?</li>
<li>More importantly, how should I tag (version) my child images? Should it contain my parents version too? In the tag itself or as labels.</li>
</ul>

<docker><jenkins><jenkins-pipeline>
How to manage Docker images and their child images in a pipeline?
Cybrix
# How to manage Docker images and their child images in a pipeline?

(Asked by: username_0 on 2018-10-03)

I have various Jenkins agents images and I am trying to add automation to it.

I have a base java image called `agent-base` and those who inherit from that one e.g. `agent-ansible`, `agent-terraform` and so on. In some case, I even have a 3rd level.

My questions:

* What would be the best way to update the child images when a parent is updated? Downstream pipelines perhaps?
* Or should I keep all the Dockerfiles in a single repository and have a script that know the images hierarchy?
* More importantly, how should I tag (version) my child images? Should it contain my parents version too? In the tag itself or as labels.

**Tags:** docker, jenkins, jenkins-pipeline


---

## 2 answers

### Answer by username_1 on 2019-05-03. Score: 1

There is a good practice called multistage build, in which you have one Dockerfile containing various image definitions that depend from one another, this helps you keep all your images updated with the latest changes and copy artifacts from one to another; this also helps reducing the image size if done right.
A simple example is like the following:
FROM golang:1.9.2 as builder
ENV CGO_ENABLED=0 GOOS=linux
RUN go build -a \
             -installsuffix cgo \
             -o app .

FROM alpine:3.6
WORKDIR /root/
COPY --from=builder app .
CMD ["./app"]

In this example, in the first image you compile a go example application using the golang official image and then, using alpine to keep the size of the image small, you copy the executable to a new image and execute it.
This way you can keep your containers in one file and build all at the same time or you can build just a target stage:
docker build --target builder -t somehub/sometag:latest .

You can even use remote images as stages:
COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf

If you need anymore information regarding Docker multi-stage builds you can find it in the following link.


---

### Answer by username_2 on 2018-10-04. Score: 0

It's not good idea to store multiple Dockerfiles inside one repository.
The best way is 1 repo 1 Dockerfile.


---

