I'm diving into Docker and trying to understand the best practices for setting things up. I've heard that it's better to minimize the number of layers in a Dockerfile since there's a limit of 127 layers. But I'm wondering about the balance between using a Dockerfile for initial setup versus using a bash script for further configuration once the container starts.
For instance, if I need to install various packages that aren't available via `apt-get`, set up GPG keys, create folders, clone a git repo, and manage SSL certificates—where should I run these instructions? Should I include them in the Dockerfile, or would it make more sense to handle them in a bash script when the container starts? The bash script could fetch the latest files easily, while the packages baked into the Dockerfile might become outdated. However, I also understand that adding too many instructions to a bash script could slow down the container startup. What are the recommended practices or middle grounds for this? Additionally, if I need to install something like the Bitwarden Secrets CLI, I'd have the same dilemma about versioning—if I bake it into the Dockerfile, I'm fixed to that version until I rebuild. Any insights would be appreciated!
1 Answer
Typically, you want to pre-build your container with all the necessary binaries and packages. This means you have to rebuild when new versions come out, but that’s where CI/CD pipelines can help automate things.
That said, if you need a flexible container for quick manual tests with various client versions—like database clients—you might build an Alpine image and use an entrypoint or run command to install those specific versions. It's especially handy for rapid testing without needing to rebuild every time.
I need to check out entrypoints more! My Dockerfile skills are solid, but my experience with entrypoints is pretty limited. I guess I'm not seeing the full potential of how they could help, so I’ve been defaulting to just using the Dockerfile and bash scripts.