It seems like the --restart option for docker run will try to restart the exact same container which has stopped. I would like it to restart with a completely new container, as if I had just run the 'docker run' command again. Is this currently possible?
Think of a docker "container" as an instance of a docker "image". Once you've created that instance it will live on with its state. If you want a new container you'll need to create a new one with the same image with "docker run".
If you have lots of parameters passed in when you create your container, you might want to checkout using docker-compose for the behavior you want. That way you can create a docker-compose.yml file with all the parameters you use to create your container then run:
docker-compose up --force-recreate
This would manage creating the exact container you want each time.
Related
i'm trying to start up tomcat on my docker desktop,and i followed the official tomcat tutorial on docker hub.but somehow i found that docker will create a new container everytime after running the command:docker run -it --rm tomcat and delete the container automatically when tomcat shuts down.
i have already known the reason is that run --rm can automatically remove the container when it exits.
now i finally built webs on tomcat,and i don't want them to be vanished.
how can i save my container before it's deleted?
thx! ;D
Based on what I've found on the internet, remove the --rm flag is not possible currently. docker update gives you the ability to update some parameters after you start your container, but you cannot update the cleanup flag (--rm) according to the document.
References:
I started a docker container with --rm Is there an easy way to keep it, without redoing everything?
Cancel --rm option on running docker container
But some workaround can be applied. You can export your current container to an image, act as a checkpoint, then you can start a new container without the --rm flag, and based on the image you exported. You can use docker commit to do so:
docker commit [your container name/id] [repo/name:tag]
(Use docker ps to list your containers, do it in a new bash/cmd/PowerShell session, or you will lose your work when you exit your docker container)
Then start a new container without the --rm flag:
docker run -it [repo/name:tag]
Disclaimer:
In the production environment, you should never change the container by running bash or sh in it. Use Dockerfile and docker build instead. Dockerfile will give you a reproducible configuration even you delete your container. By design, the container should not have any important data (aka not persistent). Use the image and volumes to save your custom changes and configurations.
Is there a docker command which works like the vagrant up command?
I'd like to use the arangodb docker image and provide a Dockerfile for my team without forcing my teammates to get educated on the details of its operation, it should 'just work'. Within the the project root, I would expect the database to start and stop with a standard docker command. Does this not exist? If so, why not?
Docker Compose could do it.
docker-compose up builds image, creates container and starts it.
docker-compose stop stops the container.
docker-compose start restarts the container.
docker-compose down stops the container and removes image and the container.
With Docker compose file you can configure the ArangoDB (expose ports, volume mapping for db initialisation, etc.). Place the compose file to the project root, and run the up command.
I have a container (i'm using this container https://hub.docker.com/_/mysql/) which had started before, with ID 5f96e9570d1b1475a888d7a615acdd9a7715c1ed6f0c40900f2e9c1ab485c7cf, but now how can i restart it ? I tried this command but not work
$ docker run --name mysql -e MYSQL_ROOT_PASSWORD=*Abcd1234 -d mysql:5.7
D:\CWindow10\Docker Toolbox\docker.exe: Error response from daemon: Conflict. The container name "/mysql" is already in use by container "5f96e9570d1b1475a888d7a615acdd9a7715c1ed6f0c40900f2e9c1ab485c7cf". You have to remove (or rename) that container to be able to reuse that name.
See 'D:\CWindow10\Docker Toolbox\docker.exe run --help'.
If i delete the container and retype the command, will the old data still exist in new container?
To restart an existing container, simply run docker start <container_name_or_id>.
Regarding the data: docker uses the concept of volumes to put data. For the mysql image, there's a section "Where to Store Data" on the docker hub site. If you don't manually declare where the image should go, docker will create one for you. If you want your data to be kept, the easiest way is to create a folder and tell the docker run command to map that volume. That way, you can still use it if you throw away your container.
use this command to restart container docker restart <CONTAINER>
starting new container will not preserve your data unless you have mounted external volume and stored data on it. Have a look at this blog http://blog.arungupta.me/docker-mysql-persistence/
I edited a file in a running docker container and restarted it, unfortunately my last edit was not correct. So every time I start the container with:
docker start <containerId>
It always exits immediately.
Now I can not even modify my edit back, since
docker exec -it <containerId> bash
can only run on a running docker.
The question is how can I change it and restart the container now? Or I had to abandon it and start a new container from an existing image?
You didn't supply any details regarding your container's purpose, or what you modified. Conceptually, you could create the file that needs to be modified in a place on your filesystem and mount that file into the container as a volume when you start it, like:
docker run -it -v /Users/<path_to_file>:<container_path_to_file> <container>
Hovever, this is bad form, as your container loses portability at that point without committing a new image.
Ideally, changes that need to be made inside of a Docker container are made in the Dockerfile, and the container image re-built. This way, your initial, working container state is represented in your Dockerfile code, making your configuration repeatable, portable, and immutable.
The file system of exited containers can still be changed. The preferable way is probably:
docker cp <fixedFile> <containerId>:<brokenFile>
But you can also circumvent docker completely; see here.
When you initially run a Docker container from an image you can specify the option:
--restart="always"
This ensures that the container is always restarted by the Docker daemon if for some reason it stops. So you could run a container like so:
docker run --restart="always" <IMAGE>
Also you can restart an existing Docker container by specifying its container ID, i.e.:
docker start <CONTAINER ID>
However I can't determine if it's possible to change an existing container, that originally was not run with the --restart="always" option, to convert it to always restart in future.
Currently the only way I can think to do this is to save the container as a new image and then run that image as a new container with the --restart="always" option. Would this in fact be the correct way to do this?
EDIT: What I perhaps didn't make clear enough originally is that I am thinking about the situation where there have been changes in the container since it was originally run, which need to be persisted. So just running a new container from the original image would not be sufficient.
We now have docker update, which allows changing the restart policy of a running container.
docker update --restart=always <CONTAINER ID>
There are three other options:
no (default)
on-failure
unless-stopped
Please refer to the link for details.
Ok, so to answer my own question, it seems that it's not possible just to restart the same container with --restart=always, because that's something you have to do when you run a container for the first time and not a parameter that you can use when you start an existing container.
There are three possible work-arounds to this:
As #user2915097 stated, you can abandon the original container (stopping it and then deleting it with docker rm <CONTAINER ID>to tidy up). Then just run a new container from the original image specifying the -restart=always option this time.
If no volumes were used, so the changes are internal to the container, you need to commit the container to a new image and then run a new container from that image.
docker commit <CONTAINER ID> <NEW IMAGE NAME>
docker run -d --restart=always ... <NEW IMAGE NAME>
If volumes were used and all changes are restricted to the volumes, then you can run a second container with the --volumes-from parameter without having to commit a new version of the image. i.e.
docker stop <CONTAINER 1 NAME>
docker run -d --restart=always --volumes-from <CONTAINER 1 NAME> ... <ORIGINAL IMAGE NAME>
It would then be safe to delete Container 1, as the volumes will not be deleted whilst another container continues to use them.
I guess there is a fourth possibility too; if you used a volume(s) and you know that there have been changes to the container that aren't on the volume, then you'll have to use a combination of (2) and (3).
Update: This worked to enable restart. But setting it back to no and it gets reset back to always and the container starts again! :( I'm going to leave this answer here in case someone figures out how this really works. I must be close!
Folks, I've found the most hacky solution that gets around copying containers etc.
vi /var/lib/docker/containers/$(docker inspect -f '{{ .Id }}' $ContainerID)/hostconfig.json
Search for "RestartPolicy". Set it to "no", "always" etc
Maybe someone could wrap that up in a script!?
Anyway, that piece of json along with the config.json would allow you to modify all sorts of things that you missed when creating your container.
extract from http://www.brandpending.com/blog/2014/11/21/setting-and-re-setting-the-restart-behaviour-of-a-docker-container
So let say you want to change the restart policy of this container
from always to on-failure. To do this, you need to stop the container,
remove it and re-run it with the new restart policy.