This is a very basic question, but I'm struggling a bit and would like to make sure I understand properly.
After a container is started from an image and some changes done to files within (i.e.: some data stored in the DB of a WebApp running on the container), what's the appropriate way to continue working with the same data between container stop and restart?
Is my understanding correct that once the container is stopped/finished (i.e.: exit after an interactive session), then that container is gone together with all file changes?
So if I want to keep some file changes I have to commit the state of the container into a new image / new version of the image?
Is my understanding correct that once the container is stopped/finished (i.e.: exit after an interactive session), then that container is gone together with all file changes?
No, a container persists after it exits, unless you started it using the --rm argument to docker run. Consider this:
$ docker run -it busybox sh
/ # date > example_file
/ # exit
Since we exited our shell, the container is no longer running:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
But if we had the -a option, we can see it:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
79aee3e2774e busybox:latest "sh" About a minute ago Exited (0) 54 seconds ago loving_fermat
And we can restart it and re-attach to it:
$ docker start 79aee3e2774e
$ docker attach 79aee3e2774e
<i press RETURN>
/ #
And the file we created earlier is still there:
/ # cat example_file
Wed Feb 18 01:51:38 UTC 2015
/ #
You can use the docker commit command to save the contents of the container into a new image, which you can then use to start new containers, or share with someone else, etc. Note, however, that if you find yourself regularly using docker commit you are probably doing yourself a disservice. In general, it is more manageable to consider containers to be read-only and generate new images using a Dockerfile and docker build.
Using this model, data is typically kept external to the container,
either through host volume mounts or using a data-only container.
You can see finished containers with docker ps -a
You can save a finished container, with the filesystem changes, into an image using docker commit container_name new_image_name
You can also extract data files from the finished container with: docker cp containerID:/path/to/find/files /path/to/put/copy
Note that you can also "plan ahead" and avoid trapping data you'll need permanently within a temporary container by having the container mount a directory from the host, e.g.
docker run -v /dir/on/host:/dir/on/container -it ubuntu:14.04
Related
We are trying to create a docker image from a container based on the Oracle 12c Enterprise Edition image from docker store (https://store.docker.com/images/oracle-database-enterprise-edition). We have the container working ok and then, after stopping the container we create an image based on that container with the following command.
docker commit Oracle_12 oracle/oradb:1
Then, we try to run a container using the commited image with the following command:
docker run -d -it --name oradb_cont -p 1512:1521 -p 5500:5500 oracle/oradb:1
This container fails with the following error:
Start up Oracle Database
Wed Nov 15 10:31:29 UTC 2017
start database
start listener
The database is ready for use .
tail: cannot open '/u01/app/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/alert_ORCLCDB.log' for reading: No such file or directory
tail: no files remaining
The container is "Exited" although the message "The database is ready for use".
We have attached a bash to the container to inspect where the missing file is. And the result seems to be that the "/diag" folder is a broken symlink:
Starting the original Oracle 12c container and attaching a bash, the folder is present. It seems symlink is broken or the file is not present only in the image created from the container.
The problem is that /ORCL is a data volume. The commit operation does not include any files that are inside volumes. You can check the commit documentation for more info.
Thus when starting the new instance, it appears that somehow the log file is being referenced and has not been yet created. Your current container is in an inconsistent state, as the files under '/ORCL' that were present in the commited container are missing from the new instance.
If you are running the new instance on a new machine you need to migrate the old volume into the new machine. You can find the volume of the old container by running docker inspect -f '{{ .Mounts }}' <old-container-name>, and migrate as specified in How to port data-only volumes from one host to another?
If you are running the new instance on the same machine, just mount the old volume using: <volume-name-or-id>:/ORCL
In general, as a best practice, you shouldn't rely on the commit command to get identical instances of a container. Rather build a DockerFile which extends the base image, and then add customizations by selecting only the necessary files to copy over on the new instance.
I am completely new to docker. I have a quick question about docker images.
Assume that I have setup a local docker image with certain software / server installed. So now I would need to set a checkpoint / snapshot here, then all the work done after this checkpoint is temporary; which means at a certain time, I would restore the original image (from that checkpoint) and overwrite everything in the temporary image.
My first question is if the above use-case make sense?
My second question, if the above make sense, what is the approach in doing that checkpoint (simply how, as I am keeping the checkpoint image in local diskspace only, no cloud repos involved) and how to restore the images to overwrite everything in the temporary image when needed.
Though I have read a bit of docker documentation, but am still struggling in the conceptual things.
It makes sense even though you could consider managing data in container or volume (or host folder mounted in the container).
That way the data remains persistent even when you stop and restart the container.
what is the approach in doing that checkpoint
If your container does not mount a volume, and has its data inside, then yes, stopping and removing a container will lose that data.
One possibility is to create that snapshot with docker commit.
That will freeze the container state as a new image, that you can run later.
Example:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours desperate_dubinsky
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours focused_hamilton
$ docker commit c3f279d17e0a svendowideit/testimage:version3
f5283438590d
$ docker images
REPOSITORY TAG ID CREATED SIZE
svendowideit/testimage version3 f5283438590d 16 seconds ago 335.7 MB
As far as I know there is nothing like checkpoint or so with respect to Docker. But you can save the actions performed on the container as Images to create a new Image.
Giving an example to have better understanding:
Lets run a container using an base Ubuntu Image and create a folder inside the container:
#docker run -it ubuntu:14.04 /bin/bash
root#58246867493d:/#
root#58246867493d:/# cd /root
root#58246867493d:~# ls
root#58246867493d:~# mkdir TEST_DIR
root#58246867493d:~# exit
Status of the exited container:
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58246867493d ubuntu:14.04 "/bin/bash" 2 minutes ago Exited (127) 57 seconds ago hungry_turing
Now you can commit the changes so that the container will be saved into a new Docker Image:
#docker commit 58246867493d ubuntu:15.0
Get docker Images
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
**ubuntu 15.0 acac1f3733b2 10 seconds ago 188MB**
ubuntu 14.04 132b7427a3b4 10 hours ago 188MB
Run the newly build Image to see the changes committed in the previous container.
# docker run -it ubuntu:15.0 /bin/bash
root#3a48af5eaec9:/# cd /root/
root#3a48af5eaec9:~# ls
TEST_DIR
root#3a48af5eaec9:~# exit
As you have asked, any further changes you do on this container either can be committed to form a new Image or can be ignored .
Hope it helps.
Is there a way to clone a container and its data into a new one with different starting parameters?
At the moment I'm only able to start a new cloned container (from custom image) WITHOUT the data.
I tell you what I have to do: I started a "docker-jenkins" container with some starting parameters and then configured it, but now I noticed that I forgot some important starting parameters so I wanna restart the same container adding more starting parameters...
The problem is (if I understand well) that I cannot modify the starting parameters of existing running container, so my idea is to start a cloned one (data INCLUDED) with different parameters but I don't understand how to do it...
Can someone help me?
1. Using volumes
If your sole point is to persist your data you need to use Volumes.
A data volume is a specially-designated directory within one or more
containers that bypasses the Union File System. Data volumes provide
several useful features for persistent or shared data:
Volumes are initialized when a container is created. If the container’s base image contains data at the specified mount point,
that existing data is copied into the new volume upon volume
initialization. (Note that this does not apply when mounting a host
directory.)
Data volumes can be shared and reused among containers.
Changes to a data volume are made directly.
Changes to a data volume will not be included when you update an image.
Data volumes persist even if the container itself is deleted.
Source:
https://docs.docker.com/engine/tutorials/dockervolumes/
Essentially you map a folder from your machine to one into your container.
When you kill the container and spawn a new instance (with modified parameters) your volume (with the existing data) is re-mapped.
Example:
docker run -p 8080:8080 -p 50000:50000 -v /your/home:/var/jenkins_home jenkins
Source:
https://hub.docker.com/_/jenkins/
2. Using commit to create snapshots
A different route is to make use of the docker commit command.
It can be useful to commit a container’s file changes or settings into
a new image. This allows you debug a container by running an
interactive shell, or to export a working dataset to another server.
Generally, it is better to use Dockerfiles to manage your images in a
documented and maintainable way.
The commit operation will not include any data contained in volumes
mounted inside the container.
https://docs.docker.com/engine/reference/commandline/commit/
$ docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
$ docker commit c3f279d17e0a svendowideit/testimage:version3
f5283438590d
$ docker images
REPOSITORY TAG ID CREATED SIZE
svendowideit/testimage version3 f5283438590d 16 seconds ago 335.7 MB
It is also possible to commit with altered configuration:
docker commit --change='CMD ["apachectl", "-DFOREGROUND"]' -c "EXPOSE 80" c3f279d17e0a svendowideit/testimage:version4
To clone a container in docker, you can use docker commit and create a snapshot the container
Use docker images to view the docker image REPOSITORY and TAG names.
Use docker ps -a to view the available containers and note the CONTAINER ID of the container of which a snapshot is to be created.
use docker commit <CONTAINER ID> <REPOSITORY>:<TAG> to create snapshot and save it as an image.
Again use docker images to view the saved image.
To access saved snapshot
run,
docker run -i -t <IMAGE ID> /bin/bash
docker ps -a
docker start <CONTAINER ID>
docker exec -ti <CONTAINER ID> bash
I am running an instance of docker, and I would like to save my work - the docs just aren't 100% clear on how to do this, so I'm asking here. I opened the docker instance using:
docker run -it [public dockerhub name]
Now I would like to save all my work locally so that I can come back to it. I don't particularly want to check it into dockerhub, unless that's advisable.
Here's what I have done. I have opened a new docker CLI tab, and done docker ps there to find the ID of the running docker instance. Then in the same tab I tried doing this:
docker commit <docker-id> me/myinstance
This gave me a commit hash.
Can I now safely exit the running docker instance? What command would I use to open it again - do I need to store the commit hash, or can I just do docker run -it me/myinstance?
As the docs mention:
You pull an image from Docker hub
You run that image on a container using docker run <image>
When you make changes to a container, you're not changing the underlying image, so those changes are not persisted if the container is stopped. To persist the changes you've made to the container, you create a new image with docker commit <container_id>
In the example that is on Docker docs:
# What containers are running on my system?
$ docker ps
ID IMAGE COMMAND CREATED
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago
# Create a new image called svendowideit/testimage, tag it as "version3"
$ docker commit c3f279d17e0a svendowideit/testimage:version3
f5283438590d
# What images do I have on my system?
$ docker images
REPOSITORY TAG ID
svendowideit/testimage version3 f5283438590d
This way, you have persisted the changes to container c3f279d17e0a, on a new image, called svendowideit/testimage:version3.
Now you have an image with your modification, so you can run it as many times as you want on a container:
$ docker run svendowideit/testimage:version3
Again, containers are stateless. Any change you make inside a container, is lost when that container stops. One way to persist data even after a container exists, is by using volumes. This way your container has access to a directory in the host filesystem, that you can read and write.
Changes made inside a container are not lost when the container exits and containers (container applications) are not stateless unless you have specifically separated the data storage from the application (by mounting folders from the host filesystem or sending data to a database outside of the container).
To see your changes persisted in a container, start the old container (docker start ~) instead of creating a new container (docker run ~).
This is easier to do if you name your containers.
ie.
docker run -it --name containerName imageName
do stuff to your container
docker kill containerName
docker start containerName
You will see that your changes are persisted in that container.
You can also commit your container as an image, which can be pushed to a registry or exported to a file.
I'm quite new to docker.I have a docker container running.
[root#vm Downloads]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fc86020fff36 centos:6.6 "/bin/bash" 5 days ago Up 17 hours drunk_tesla
I want to stop this vm and run it as --privileged. But I have bunch of things in this docker.
I don't want to use --run because it creates a new docker instance and i have to re-do everything.
Is there anyway i can stop and start the docker container in privileged mode?
Thanks,
r
Since the docker image you used (centos:6.6) for creating this container has no volumes, that means that any data you modified in this container is written on the container filesystem itself (as opposed to on a docker volume).
The docker commit command will take the content of a container filesystem (excluding volumes) and produce a new docker image from it. This way you will be able to create a new container from that new image that will have the same content.
docker commit drunk_tesla mycentosimage
docker run -it --privileged mycentosimage bash