> So the filesystem of final images would be in `/dest` and TAGGED_SWITCH_ROOT, would do the final commit?
no, please refer to this for details
I don't know how I forget to give you the link before
the syntax is SWITCH_ROOT <other_image> <root1> <root2> ...
where <other_image> can be scratch, busybox, fedora, ..etc.
it will be used as the filesystem root (preserving its layers)
but <root1> <root2>... will be copied to / in a new layer and commit
let me give you an example
FROM fedora
RUN yum install busybox && mkdir -p /dest/{bin,sbin}/ && cp /sbin/busybox /dest/sbin/
SWITCH_ROOT scratch /dest/
# RUN for i in $(/sbin/busybox --list);do ln -s /sbin/busybox /bin/$i; done
##### END
docker build -t myfedora/busybox .
the final image myfedora/busybox would just have fedora's busybox because it was from scratch
another example when you want to eliminate compilers and unnecessary layers ..etc
FROM fedora
RUN yum install -y git nodejs golang
RUN mkdir -p /dest/{bin,data}/ && \
git clone myUrl myproj && cd myproj && \
golang build -o /dest/bin/go-foo && \
cp data /dest/data/
SWITCH_ROOT busybox /dest/
##### END
docker build -t myfedora/go-foo .
would be a very small busybox with my statically linked go-foo
you can replace "SWITCH_ROOT busybox /dest/" with "SWITCH_ROOT fedora /dest/"
in case of python/nodejs where having a proper dynamically linked base system is a better option
the result in would be adding an extra layer over the already fetched/cached base image (busybox/fedora)
> ideally come up with a solution (and implementation).
the implementation is quite simple we start with a building container and a working container both initially refer to the same thing
with first "SWITCH_ROOT" (or if we change it to "PIVOT_ROOT") we start a new container from <other_image> which will be the working container (leaving the build container as is)
let's say we start a container from busybox image, then we use "docker cp" to copy the <root1> <root2> .. from build container to working container then we commit and cache
all next run/adds/copies are in working container then when done we commit and tag the working container and saves its image
we can have multiple images from same docker file using "TAGGED_SWITCH_ROOT" (or if we change it to "TAGGED_PIVOT_ROOT")
TAGGED_SWITCH_ROOT <tag-suffix> <other_image> <root1> <root2> ...
will do the same except when done it will commit and tag with extra "-<tag-suffix>" after the passed tag, for example
docker build -t myfedora/go-foo .
might result in myfedora/go-foo (from SWITCH_ROOT) and myfedora/go-foo-server (from "TAGGED_SWITCH_ROOT server ...")
note: there always be at most 2 containers, the initial build container and the current active working container,
in case of multiple TAGGED_SWITCH_ROOT <tag-suffix> <other_image> <root1>
the source of <root1> will always refer to the initial build container (not the previously active working container)
the builder has to keep track of at most 2 containers during the build of the docker file no matter how many images it will build.
please tell me what you like more PIVOT or SWITCH