We have installed Ephesoft on a docker.
One file (in particular
dcma-batch.properties
in
Ephesoft/Application/WEB-INF/classes/META-INF/dcma-batch/
is reset after the docker exits and it is relaunched. Is there any way of stopping this?
If you restart a docker container, all data is lost, and it is reset to the initial image.
If you want persistent storage, look into docker volumes here:
https://docs.docker.com/engine/admin/volumes/
Related
I know that when we stop docker our changes are lost. There are many answers how to prevent this - commit each time. Idea is that when docker runs it will spin up a fresh container based on the image. On the other hand container persists some data after it exists unless you start using --rm.
Just to simplify:
If you run apt-get install vim, you must commit to save the change
BUT If you change nginx.conf or upload new file to HDFS, you do not lose the data.
So, just curious:
How docker knows what to save and what not? Ex: At the end of apt-get-install we have new files in the system. The same is when I upload new file. for the container/image there is NO difference , Right? Just I/O modification. So how docker know which modification should be saved when we stop the image?
The basic rules here:
Anything you explicitly store outside the container — a database, S3 — will outlive the container.
If you attach a volume to the container when you create the container using a docker run -v option or a Docker Compose volumes: option, any data written to that directory outlives the container. (If it’s a named volume, it lasts until you docker volume rm it.)
Anything else in the container filesystem is lost as soon as you docker rm the container.
If you need things like your application source code or a helper tool installed in an image, write a Dockerfile to describe how to build the image and run docker build. Check the Dockerfile into source control alongside your application.
The general theory of working with Docker is that you always start from a clean slate. When you docker build an image, you start from a base image and install your application into it; you never try to upgrade an installed application. Similarly, when you docker run a container, you start from a fresh copy of its image.
So the clearest answer to the question you ask is really, if you consistently docker rm a container when you stop it, when you docker run a new container, it will have the base image plus the content from the mounted volumes. Docker will never automatically persist anything outside of this.
You should never run docker commit: this leads to magic images that can’t be recreated later (in six months when you discover a critical security issue that risks taking your site down). Similarly, you should never install software in a running container, because it will be lost as soon as the container exits; add it to your Dockerfile and rebuild.
For any Container working with the Docker platform by default all the data generated is temporary and all the file generation or data generation is temporary and no data will persist if you have not mounted the filesystem part of if you have not attached volumes to the container.
IF you are finding that the nginx.conf is getting reused even after changes i would suggest try to find what directories are you trying to mount or mapped to the docker volumes.
The configurations for nginx which reside at /etc/nginx/conf.d/* and you might be mapping the volume with this directory. So if you make any changes in a working container and then remove the container the data will still persist as the data gets written to the writable layer. If the new container which you deploy later with the same volume mapping you will find all the changes you had initially done in the previous case are reflected in the newer container as well.
Trying to make sure I understand the proper usage of docker volumes. If I have a container running MongoDB that I plan to start and stop do I need a volume configured with I "docker run" the first time? My understanding is that if use Docker run once, then docker stop/start my data is saved inside the container. The volume is more useful if multiple containers want access to the data. Is that accurate or am I misunderstanding something?
Starting and stopping a container will not delete the container specific data. However, you upgrade containers by replacing them with new containers. Any changes to the container specific read/write layer will be lost when that happens, and the new container will go back to it's initial state. If there are files inside your container that you want to preserve when the container is replaced, then you need to store those files in a volume, and then mount that same volume in the new container.
In some places when I read about Docker containers, I found some people talking that they lose their data (saved inside the container and not a part of volume data) when they restart the container.
I tried to create a simple Ubuntu container like this: docker run -it ubuntu /bin/bash, and created some files inside the container and then restarted it, but my data still there. Why does that actually happen? why do my data still there? Is this something new in the newer versions of Docker or do I have misunderstanding for something?
The data is lost when the container is removed, not when it's stopped or restarted.
Basically, if you do docker ps, if the containers keeps the same id (the big ugly hexadecimal id), the data is not lost.
It gets complicated when somehow your docker containers are not managed by you, but by some kind of automated-managing method. Tools like these usually start new containers if there is failure. In that case you should mount a volume to store your data on the host.
You might want to look at the Container Lifecycle: https://github.com/wsargent/docker-cheat-sheet#lifecycle
docker create creates a container but does not start it.
docker rename allows the container to be renamed.
docker run creates and starts a container in one operation.
docker rm deletes a container.
docker update updates a container's resource limits.
If you do docker rm and docker run again your state will not be there anymore.
If you want a transient container, docker run --rm will remove the container after it stops.
We found that running docker rm myprocess takes quite a bit of time, much longer than docker run takes to start a fresh copy.
Is there a way we can make a container give up its name, so that we can first free up the name to be able to docker run again, and then do the time-consuming cleanup of the old container later?
That would make the stop/start cycle when updating to newer versions of the underlying image faster.
You can rename a container that already exists, or you could deploy with a new name then rename it afterwards:
docker rename myprocess myprocess-old
There have been multiple reports of that problem.
Issue 16281 mentions (about the devicemapper or dm):
Switching the dm.basesize to 10GB seems to be fixing the issue so far, maybe it would be worth reverting the default to 10GB instead of 100GB or even specify this option at the creation of the container as requested in issue 14678
See the docker daemon storage driver options:
docker daemon --storage-opt dm.basesize=10G
Switching to thinpool can help too:
docker daemon --storage-opt dm.thinpooldev=/dev/mapper/thin-pool
What happens when the docker host is shut down and restarted?
will the images that were running be restarted?
will the changes that were made to those images persist, or will a new instance of the image be spawned and changes be lost?
does docker have any configuration option, such as the list of images to be automatically executed at startup and the options to run the images? Where? If not, I suppose only the docker command line can be used to alter docker state. Where is that state stored (I suppose somewhere in /var). This could be useful to backup the docker state.
(I'd have liked to find this in the FAQ)
will the images that were running be restarted?
Docker will restart containers when the daemon restarts if you pass -r=True to the startup options. On Ubuntu, you can accomplish this permanently by modifying DOCKER_OPTS="-r=true" in /etc/default/docker.
will the changes that were made to those images persist, or will a new instance of the image be spawned and changes be lost?
Containers will be stopped. Any modifications to the container will still be present when the container next starts, which will happen automatically when the docker daemon starts if -r=true is provided as mentioned above.
where is the docker configuration stored on the host system?
There is no configuration file per se. You can tune the upstart/init options in /etc/default/docker.