(Just a suggestion)
We usually have the following structure for building our docker images:
my-image/
├── assets
│ ├── entrypoint.sh
│ └── install.sh
├── build.sh
├── Dockerfile
├── README.md
└── VERSION
- build.sh: This is where you should invoke
script_that_creates_magic_file.sh. Other common tasks involve downloading required files or temporarily copying ssh keys from the host. Finally, this script will calldocker build . - Dockerfile: As usual, but depending on the number of commands we need to run we might have an
install.sh - install.sh: This is copied and run inside the container, installs packages, removes unnecessary files, etc. Without being 100% sure – I think such an approach reduces the number of layers avoiding multiple commands in a single
RUN - entrypoint.sh: Container’s entrypoint. Allows us to perform tasks when the container starts (like parse environment variables) and print debugging info
I find the above structure convenient and self-documented since everyone in the team can build any image (no special instructions/steps). The README is there to explain what the image is doing… but I won’t lie to you… it is usually empty… (or has an h1 for the gitlab to display) 🙂