Docker Community Forums

Share and learn in the Docker community.

Where to store Dockerfile for existing image that I downloaded but not created

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 :slight_smile: 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 :wink:

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 :slight_smile:

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.

Thanks for the clearificatlion, Akos! Basicly docker history with a commited image is useless to re-create the steps to put the im in a Dockerfile.

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.

A Dockerfile is a description to create a new image. You can’t add a Dockerfile to an existing image. It doesn’t make sense. You also mentioned:

You can’t change an existing image. You installed those packages in a container, then you committed it, so eventually you created a new image.

I try to use a probably poor analogy: you can’t add a source code to a binary. You rebuild the binary from the new source code.

If you feel I still misunderstand you, please, try to describe your goal with more details.

That is where i got confused. Thanks for clearing up!

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 :slight_smile: 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.

1 Like