Hacker News Reader

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

Got your point, and this is a nice solution. But another (not uncommon approach) is to understand the docker container itself as the application.

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

Thank you, I didn't know and will have a look :)

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

Thx for your constructive summary. Not sure what you mean with "tools might need" but deck-build only needs some well defined ENVs (https://bit.ly/2TSTImv). Regarding shell scripts used in RUN commands: Why not COPY a conf file that will be sourced by every script?

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

In the meantime I have realized that the term "framework" is very missleading... ;) But you're pointing out a crucial point. IMO, the need of many Show-HN solutions is often not fully understandable in the first moment. But when processes and requirements change over time, sometimes these solutions are remembered again and can be a starting point for own ideas. That's one of the reasons why I read HN :) Thank you for your constructive comments!

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

I am not sure if I understand your comment correctly, but we all know that there is a very large range of image requirements. Some of them need to be solved during builds (e.g. sometimes you want to distinguish between dev and production setups), other will be processed during container setup.

You are right regarding inheritors. Creating a docker-hub image has differnent requirements than creating images for your private environment.

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

No, it's not "easier" and it doesn't replace the thinking in images and using images in the final step. The user really need to understand the docker concept. As I wrote in the other answers: It's only (another) approach to avoid complex (RUN ... if ... else ...) Dockerfiles. Hey, this is HN: We share solutions. some you like, some you don't - But the ones you don't like will give you new ideas sometimes :)

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

Yes, your are both right, of course you can RUN "useradd ...". But we have often made the experience that we need to run more complex processes during docker builds (with if...else conditions etc.) resulting in complex Dockerfile RUNs. Bundling and reusing this code in plans/artefacts is very useful. In the end we use docker-build to create our images, of course it's not intended to be a substitution for the great (docker hub) image concept.

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

Build cache is supported (https://bit.ly/2S8Z3oi), it's the job of the user to structure his code wisely (same as with docker RUN commands). And: No, it's not "better", it's a different approach. Like most/any other community solution it will not replace the standard Dockerfile process :)

d3ckon Deck-build – A powerful and tiny bash framework to build custom Docker images

You are right, deck-build doesn't have any magic regarding the build process (this is part of the concept). But:

1.) It bundles a lot of useful functions (https://bit.ly/2N9mAEu) in the "kit": Have a look at this gist: https://bit.ly/2Nby0HZ - Four lines to create a container with two users (foo and root) including their own python packages installed in their home directories (PIP_USER=1).

2.) It's very easy to expand the kit and the plan/artefact concept helps to structure and reuse code (https://bit.ly/2BEIcnH) stored on your local disk or in repositories.