Open cpitman opened 7 years ago
Let me go through the critic one by one.
Lots of extra layers created with no effect, for example many USER layers
That's correct. Since we are abstracting script execution we need to be able to define the user that should be used to run these scripts. It's true that this could be optimized (some of the USER
commands are not necessary because we've already witched to that particular user).
Commands that can be concatenated into fewer layers (like RUN) are not
That's also true, but there is always a trade off between caching and being able to built image quicker. If you concatenate executions then change in any script will invalidate every other scripts. If these are long-running tasks you will at the end open a ticket about exactly opposite what you are suggesting now.
Files are removed in later layers, literally making the images larger because of the COW filesystem
That's true again. But we don't care about this and let me explain why we do things like we do so you get a better picture.
This tool was created to overcome Docker limitations in the first place. Dockerfile syntax is just broken, sometimes doesn't make sense, it's hard to maintain does not allow to share scripts/files between images and so on. I could create a fairly long list why it's not optimal.
At the same time Dockerfile is (still) a kind of standard when we talk about building container images. This will hopefully change soon and I already see promising projects (https://github.com/projectatomic/buildah for example).
OK, now we know that Dockerfile is broken and it's a standard. Our approach is to:
Since Dockerfiles are broken by design there are many issues we need to fight and we still see it in our generated Dockerfiles. Most important issues are:
I agree with everything you pointed out but these are not the generator tool issues but Dockerfile syntax issues, which luckily can be solved. For this purpose we do post processing on every single container image we release using this tool: https://github.com/goldmann/docker-squash I won't repeat README of that project here, but it's solving exactly these issues I pointed out above.
So, to recap - at development time - we're perfectly fine with a bit "too big" images, but when we release them we make them pretty.
Hope you understand the background better now.
BTW, Dogen is now in maintenance mode. Next generation of this tool is now available here: https://github.com/jboss-container-images/concreate. It's still early days (first RC was released), but it'll replace this tool soon.
Dockerfiles generated are suboptimal, not following standard best practices:
An example is below. A handcrafted version of this Dockerfile would be both much cleaner, and result in a smaller image.