cloud66-oss/habitus

Cleaning Intermediate images & Flag "noprune-rmi" having no effect

dduportal opened this issue · 2 comments

Hello!

I am using habitus to build a collection of docker images co-located on a single repository.
Some depends on others (as "dind-base" -> "devbox"), and we may have 2 nested levels ("java-base" -> "jenkins-base" -> "jenkins-custom").

I discovered that all the intermediate "parent" images are cleaned up at the end of the habitus build.,
even if they are specified by the build.yml file.
=> As a User, I don't understand this behavior by default.

However, reading the documentation on the page "habitus.io", I saw the following:

noprune-rmi: Doesn't prune unwanted images after the build

So I tried it, but my images are still deleted.

Am I missing something, or is it a bug?

  • A simplified build.yml file for reproduction:
# Habitus build file
build:
  version: 2016-03-14 # version of the build schema.
  steps:
    dind-base:
      name: dind-base
      context: ./dind-base
      dockerfile: Dockerfile
    devbox:
      name: devbox
      context: ./devbox
      dockerfile: Dockerfile
      depends_on:
        - dind-base

Dockerfiles:

# dind-base/Dockerfile
FROM alpine:3.7
RUN echo FOO > /foo.txt
# devbox/Dockerfile
FROM dind-base
RUN cat /foo.txt > /bar.txt

Here is the execution command (and log):

habitus -noprune-rmi
2018/05/29 09:48:31 ▶ Using '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/build.yml' as build file 
2018/05/29 09:48:31 ▶ Collecting artifact information 
2018/05/29 09:48:31 ▶ Building 2 steps 
2018/05/29 09:48:31 ▶ Step 1 - dind-base, image-name = 'dind-base' 
2018/05/29 09:48:31 ▶ Step 2 - devbox, image-name = 'devbox' 
2018/05/29 09:48:31 ▶ Step 1 - Build for dind-base 
2018/05/29 09:48:31 ▶ Step 1 - Building dind-base from context '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base' 
2018/05/29 09:48:31 ▶ Step 1 - Parsing and converting 'Dockerfile' 
2018/05/29 09:48:31 ▶ Step 1 - Writing the new Dockerfile into '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base/Dockerfile.generated' 
2018/05/29 09:48:31 ▶ Step 1 - Building the dind-base image from /Users/dadou/workspace/cloudbees/training-docker-library/tmp/dind-base/Dockerfile.generated 
Step 1/2 : FROM alpine:3.7
3.7: Pulling from library/alpine
ff3a5c916c92: Already exists
Digest: sha256:7df6db5aa61ae9480f52f0b3a06a140ab98d427f86d8d5de0bedab9b8df6b1c0
Status: Downloaded newer image for alpine:3.7
 ---> 3fd9065eaf02
Step 2/2 : RUN echo FOO > /foo.txt
 ---> Running in a44978de8534
Removing intermediate container a44978de8534
 ---> d4647da426aa
Successfully built d4647da426aa
Successfully tagged dind-base:latest
2018/05/29 09:48:35 ▶ Step 2 - Build for devbox 
2018/05/29 09:48:35 ▶ Step 2 - Building devbox from context '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox' 
2018/05/29 09:48:35 ▶ Step 2 - Parsing and converting 'Dockerfile' 
2018/05/29 09:48:35 ▶ Step 2 - Writing the new Dockerfile into '/Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox/Dockerfile.generated' 
2018/05/29 09:48:35 ▶ Step 2 - Building the devbox image from /Users/dadou/workspace/cloudbees/training-docker-library/tmp/devbox/Dockerfile.generated 
Step 1/2 : FROM dind-base
 ---> d4647da426aa
Step 2/2 : RUN cat /foo.txt > /bar.txt
 ---> Running in 744ba5f31949
Removing intermediate container 744ba5f31949
 ---> 31121503c301
Successfully built 31121503c301
Successfully tagged devbox:latest
2018/05/29 09:48:36 ▶ Step 1 - Removing unwanted image dind-base 

=> It ends with Step 1 - Removing unwanted image dind-base

For information, using the flag -keep-all has the intented behavior.

What did I miss ?

@dduportal Hi, thanks for using habitus 😄

-noprune-rmi corresponds to docker's noprune, which affects untagged parent images of dind-base in this case. Probably this part of the official docker doc and habitus' code would help understanding this behavior.

To summarize, you need -keep-all to retain dind-base. Otherwise it is removed along with all the untagged parent images of dind-base. noprune-rmi keeps untagged parent images, but not dind-base itself.

Does this clarifies things enough? Perhaps we need to improve docs and/or log messages? Any input is welcomed. Thanks!

khash commented

Closing for lack of activity