6 ms·
I wish Dockerfiles allowed you to group commands so that they would end up in the same layer, so you don't have to do something ridiculous like RUN cmd1 && cmd
by fnord77 7y ago
I wish Dockerfiles allowed you to group commands so that they would end up in the same layer, so you don't have to do something ridiculous like
RUN cmd1 && cmd2 && cmd3 && cmd4
maybe with brackets:
# 1 layer
{
RUN cmd1
COPY someshit
RUN cmd2 -lots -of -long flags
...
}
- IanCal 7y agoYou might be interested in this: https://github.com/uber/makisu https://github.com/uber/makisu I've not used it but it's on my list to try out, the explicit caching I think ties in with what you're after: * Requires no elevated privileges or containerd/Docker daemon, making the build process portable. * Uses a distributed layer cache to improve performance across a build cluster. * Provides control over generated layers with a new optional keyword #!COMMIT, reducing the number of layers in images. * Is Docker compatible. Note, the Dockerfile parser in Makisu is opinionated in some scenarios. More details can be found here.
- IanCal 7y agoI can't edit any more, but I'd really be interested in people's experiences with it.
- fctorial 7y agoWhy do you want to avoid multiple layers. Performance?
- lbotos 7y agoSize of the resulting container is my understanding.
- orf 7y agoBuild performance, image size and deployment speed mostly.
- kortex 7y agoEach layer is a write only operation. So if you `RUN some_build.sh` and then `RUN rm junk`, you basically do nothing to reduce the final image size. So you see a lot of like `RUN some_build.sh && rm -rf junk`. There's some overhead with each layer as well.
- silviot 7y agoNowadays docker server, when run with the experimental flag, allows you to build images with the `--squash` option, so your whole image will contain a single layer. Alternatively you can use buildah [1] to build your images via a script, but you'll lose the cache docker puts in place. [1] https://buildah.io/ https://buildah.io/