I am currently working on a Cloud Technology project and I realized I missed a few essential dependencies in my initial setup. I need to install a specific package like 'curl' or 'vim' inside my active Docker container. Should I be using the 'docker exec' command to install it manually while the container is running, or is it strictly better practice to update my Dockerfile and rebuild the entire image? Also, how do I ensure these packages aren't lost if the container restarts?
3 answers
The industry standard for Software Development and Cloud operations is to always define your packages in the Dockerfile. You should use the RUN instruction combined with your package manager's update command to keep the image slim. For a Debian-based image, the syntax is RUN apt-get update && apt-get install -y curl. The -y flag is crucial as it automatically answers 'yes' to prompts, allowing the build to finish without human intervention. By putting this in the Dockerfile, you ensure that every time you spin up a new instance, the environment is identical. Installing packages via docker exec is great for quick debugging, but those changes are "ephemeral"—meaning they will vanish the moment the container is deleted and recreated from the original image.
If I use docker exec to install a package for testing right now, is there a way to "save" that state into a new image without having to manually rewrite my entire Dockerfile from scratch? I've heard about the docker commit command, but is that considered a bad practice in professional cloud environments?
For Alpine Linux images, which are popular because they are tiny, you should use apk add --no-cache <package>. It keeps the image size small by not storing the index locally.
Great point, Amanda! Using the --no-cache flag is a pro tip for Cloud Technology experts looking to optimize their CI/CD pipelines and reduce storage costs in AWS or Azure.
Robert, you're right that docker commit exists, but it is generally discouraged in professional DevOps workflows. The reason is "traceability." If you commit a container, nobody else on your team can see how that package was installed or what version was used. It turns your image into a "black box." It’s much better to spend the five minutes updating your Dockerfile. This way, your build pipeline remains transparent, and you can track changes through version control systems like Git. Stick to the Dockerfile for anything intended for production!