Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-03T15:33:20.930Z
Answers: 2019-05-03T15:33:20.930Z
Answers: Daniel Cortés
Answers: <p>It's not good idea to store multiple Dockerfiles inside one repository.
  The best way is 1 repo 1 Dockerfile.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-04T04:48:26.743Z
Answers: 2018-10-04T04:48:26.743Z
Answers: Meiram Chuzhenbayev
Body: <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>
  
Tags: <docker><jenkins><jenkins-pipeline>
Title: How to manage Docker images and their child images in a pipeline?
UserDisplayName: Cybrix
ThreadText: # 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](https://docs.docker.com/develop/develop-images/multistage-build/).
  
  
  ---
  
  ### 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.
  
  
  ---
  
  