I needed to install couple of package under docker image I am using. Because its state lost everytime I login. I also needed to save file.
Is docker commit best way? 1. to save files 2. to save installed packages.
Online discussion points docker commit is a poor way of doing so and Dockerfile is suggested.
But I am not sure #2 can be done with Dockerfile.
Lets say if I go for dockerfile creation but where do I store for existing image that I did not create?
If I go for docker commit route, is it better for both 1 and 2 above?
If docker commit is okay for you, then use that but it does come with some down-sides, the obvious one is that you wont easily be able to re-create the image if you need to change something, you can only add to the current one, making it bloaty
Dockerfile is the correct way to go, as it will create a recipe for your image, that you always can change and just build it again.
The dockerfile language supports the same things as you would do in the terminal, all terminal commands can be run with âCMDâ in a dockerfile, and also add files to that image via COPY/ADD, so you should be able to build the same image in a dockerfile, if you can remember what you did
I think @terpz answered almost everything, but I feel I need to add the following to make it more clear what really happens behind the scenes. At least I try
You donât have to have Dockerfile for those images. Doesnât matter if you use docker commit or write a Dockerfile and build your image with docker build. You will always have a new image layer on top of the original image. The only difference is that if you donât use Dockerfile you wonât have a standard file to describe your changes (the new layers).
Even if you commit the container using the same name as the original image had, you will have a new image with a new ID and the name will be reassigned to the new ID.
If you really want to store your Dockerfile and the image online, you can create a private (or public) GitHub repository, build the image and push it to a private Docker registry. You can have 1 private repository on Docker Hub for free.
Just out of curriousity and laziness (as in forgive me that I am not going to test something I donât see myself using in the future): how would docker history look for an image created using commit?
Would it contain the history of commands used that lead to the image, like it does for an image build using a Dockerfile?
I must admit, docker commit is one of the few commands I didnât use so far.
You would only see the command in the history which kept the container alive. In case of an interactive bash container it would be âbashâ and nothing else that would be executed in that shell.
Please note that the accuracy here is important. I Am not talking about creating or committing docker file or docker image, respectively for my own image i created. I am pulling someone elseâs or other orgâs image and talking about committing or adding dockerfile.
Latest development: I got someoneâs image and I was confused because of lack of understanding of image and container. It seems commit is not necessary at all?
Because I downloaded someoneâs image run it and once it exists, next time I run the same container! everything was kept there including installed packages. What I was confused was I kept running the same image and created multiple new containers and of course those new cotnainers does not have what i did before.
So i just use the same container to keept change?
sudo container start
sudo container attach â all changes are there.
Except there may be circumstances owner of the docker images decide to update to new release etcâŠ
In that case, will my current container affected? Will the container decoupled or still coupled to image?
Lets say docker image is updated online when the update can be pulled?
You shoudnt really edit a running container, by updating stuff in the container and so on.
The point of an container is that you should be able to completly delete it (not the persistant data) and just start it again and it will be the same as before, or if you start a faulty version of an image, just delete it and start up from an working version.
what kind of application are you running since you need to edit in container?
If you need to create your own version of it, you should look into a dockerfile (a recipe for a image)
Then you will have a backup of the dockerfile, so you easily can recreate the image if it gets deleted, and then you can run a container from that image, and youâre back online.
and yes, you can stop/start a container where you changes are still there, but what if you delete it? (docker rm ID) i will be the same case if you need to restore from backup, you dont want to backup full images and containers.
the dockerfile, the compose file, and the persistant storage is the things you need to backup
Listen to Martin Also it is a little offtopic, but I wouldnât use âattachâ unless you really need to connect to the main process again. Otherwise use docker exec -it containername bash or other supported shell instead of bash or any command actually. This is mainly for learning, investigation and some management, but donât install anything you want to keep. In some cases even a temporary install could breake your container if the installed package does something that you other processes donât expect or the installation sometimes removes incompatible packages whcih you actually need.
but it does come with some down-sides, the obvious one is that you wont easily be able to re-create the image if you need to change something, you can only add to the current one, making it bloaty
Also it is a little offtopic, but I wouldnât use âattachâ unless you really need to connect to the main process again. Otherwise use