Use Dockerfile ARGs

[berney]

The use of ARG in Dockerfiles could allow vanilla use of Dockerfiles without the Dockerfile.template source. Instead of engine/docker.sh using the generate_dockerfile() function, the docker build steps could pass the appropriate build args.

Docker build reference: https://docs.docker.com/build/guide/build-args/ Dockerfile Reference for ARG: https://docs.docker.com/engine/reference/builder/#arg

Leveraging the dockerfile feature could simply kubler.

For example instead of having images/figlet/Dockerfile.template:

FROM ${IMAGE_PARENT}
LABEL maintainer ${MAINTAINER}

ADD rootfs.tar /

#COPY docker-healthcheck.sh /usr/bin/docker-healthcheck
#HEALTHCHECK --interval=60s --timeout=5s --start-period=5s --retries=3 CMD ["docker-healthcheck"]

CMD ["figlet", "gentoo-bb"]

We could have images/figlet/Dockerfile:

ARG IMAGE_PARENT
FROM ${IMAGE_PARENT}
ARG MAINTAINER
LABEL maintainer ${MAINTAINER}

ADD rootfs.tar /

#COPY docker-healthcheck.sh /usr/bin/docker-healthcheck
#HEALTHCHECK --interval=60s --timeout=5s --start-period=5s --retries=3 CMD ["docker-healthcheck"]

CMD ["figlet", "gentoo-bb"]

and remove Dockerfile from .gitignore.

When Kubler was first written Docker at the time didn't support Dockerfile Build ARGs for templating Dockerfiles. It was added in Docker 1.9 (2015-11-03) https://docs.docker.com/engine/release-notes/prior-releases/#builder-6

I'm happy to work on a PR for this. Does anyone foresee any issues with removing the templating feature and moving to build args? Besides the fact that end users will need to migrate their Dockerfiles.templates to Dockerfiles (adding the ARG directives).

[r7l]

I am not against this change but i'd guess this change would break any existing image as you would have to replace all the template files with a Dockerfile. I actually prefer the current name as it makes clear that it's not a simple Dockerfile on it's own but instead it's a template that will be used and maybe even altered by Kubler.

[berney]

Thanks for the comments r71.

I working on #215 and was thinking it could simplify kubler, by leveraging docker features.

Right now I mostly see IMAGE_PARENT and MAINTAINER like the figlet example in the OP. The MAINTAINER seems to be just a way to centralise it, in your central kubler.conf you can update this, and every image will get the update.

The IMAGE_PARENT is important as it is used to define the dependency graph hierarchy, if build.conf didn't declare it and it was just hardcoded in the FROM directives then kubler wouldn't understand the image dependency graph, couldn't order the builds, and dependency images would be missing due to not being built yet.

[r7l]

Maybe i got your idea wrong. What i meant is that currently every image has a file called Dockerfile.template like you've said and the .template file extension is a nice way to not mix this template file with a real Dockerfile.

I don't mind changing these variables if this helps. But it's up to @edannenberg anyways.

[berney]

You understood me right. I was thinking to effectively git mv Dockerfile.template Dockerfile, and to add the ARG IMAGE_PARENT etc to the dockerfile, and then in the docker build commands add the --build-arg IMAGE_PARENT="${IMAGE_PARENT}" sort of thing.

The way Kubler is right now, before a build, you have the Dockerfile.template, and after a build you have the generated Dockerfile with the concrete values, and the rootfs.tar, together which is enough to feed to native docker to (re)create the image.