There are three aspects of Docker that aren't too bad in itself (and have obvious or logical reasons), but taking them together leads to close coupling and code duplication:
- There is no composition of images, but only inheritance
- Shell scripts can't define any environmental variables that will survive beyond the script itself
- Docker doesn't have any way to take or template values from other Dockerfiles
That means that you might be able to separate RUN logic out into shell script (like the method deck-build proposes), so that you can compose multiple tools into the same image. Still any ENV variables that your tools might need (if only a simple $PATH) need to be manually copied into the composing Dockerfile and maintained when changes occur.
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?
- There is no composition of images, but only inheritance
- Shell scripts can't define any environmental variables that will survive beyond the script itself
- Docker doesn't have any way to take or template values from other Dockerfiles
That means that you might be able to separate RUN logic out into shell script (like the method deck-build proposes), so that you can compose multiple tools into the same image. Still any ENV variables that your tools might need (if only a simple $PATH) need to be manually copied into the composing Dockerfile and maintained when changes occur.