I want to know what containers I have available and seems like the command docker ps do it, but this command is also running the containers.
You can see in the picture the status of the containers "Up less than a second" meaning that they has just been started with the command docker ps.
What command can I run to just see the containers without running them?
Best regards.
docker ps shouldn't run the containers. In the unlikely event that it does, I would go through the standard steps of reporting Docker bugs: Reproduction steps, Docker version, etc. If it really is a bug, you could roll back to an older Docker version and surely there are a bunch where docker ps does not contain such critical bugs.
Most likely the problem is specific to your environment. The easy way to confirm this is to try the same commands on a different machine or VM. On my machine, for instance, docker ps does not run containers - once you find a machine that also has correct docker ps behavior you can then start comparing them to find the difference.
Maybe you have docker ps aliased to something else or something like that? There are other ways to check container status, such as Portainer and ctop. I think these probably rely on the same logic as docker ps, but you should see if they have the same issue in any case.
By the way, the status is just the status of the container. It could be that the container is failing a few seconds after launch, and being restarted by Docker, which is why you see the message. Try running a standard container like ubuntu or hello-world with simple parameters (definitely without --restart=always or --rm), and see if that also gets "restarted". My bet is it won't, unless you have a serious misconfiguration/Docker bug (in which case do a clean install of older Docker version).
To directly answer your question:
What command can I run to just see the containers without running them?
You can also run the command: docker container list
Which results in this:
Related
I succeeded in connecting to a remote server configured with Docker through vscode. By the way, the list of containers from the past was fetched from the remote explorer of vscode. If you look at this list of containers, they are obviously containers made with images I downloaded a few days ago. I don't know why this is happening.
Presumably, it is a problem with the settings.json file or a problem with some log.
I pressed f1 in vscode and select Remote-Containers: Attach to Running Container...
Then the docker command was entered automatically in the terminal. Here, a container (b25ee2cb9162) that I do not know where it came from has appeared.
After running this container, a new window opens with the message Starting Dev Container.
This is the list of containers that I said downloaded a few days ago. This is what vscode showed me.
What's the reason that this happened?
Those containers you are seeing are similar to those if you run docker container ls. The containers you are seeing have exited and are not automatically cleaned up by Docker unless specified in CLI --rm option.
The docs for the --rm option explain the reason for this nicely:
By default a container’s file system persists even after the container exits. This makes debugging a lot easier (since you can inspect the final state) and you retain all your data by default. But if you are running short-term foreground processes, these container file systems can really pile up. If instead you’d like Docker to automatically clean up the container and remove the file system when the container exits, you can add the --rm flag:
From this answer about these non-running containers taking up system resources you don't have to be concerned about these taking up much space expect minimal disk space.
To remove those containers, you have a few options:
[Preemptive] Use --rm flag when running container
You can pass the --rm flag when you run a container with the Docker to remove the containers after they have exited so old containers don't accumulate.
As the docs mention, the downside is after the container exits, it's difficult to debug why the container exited if something failed inside the container.
See the docs here if using docker run: https://docs.docker.com/engine/reference/run/#clean-up---rm
See this answer if using docker-compose run
Clean up existing containers from the command line
Use the docker container prune command to remove all stopped containers.
See the docs here: https://docs.docker.com/engine/reference/commandline/container_prune/
See this related SO answer if you're looking for other options:
Clean up containers from VSCode
VSCode Docker Containers Extension you clean up containers if you open the command palate and enter Docker Containers: Remove
Or you can simply right click those containers.
So, is there a point in the command "start"? like in "docker start -i albineContainer".
If I do this, I can't really do anything with the albine inside the container, I would have to do a run and create another container with the "-it" command and "sh" after (or "/bin/bash", don't remember it correctly right now).
Is that how it will go most of the times? delete and rebuilt containers and do the command "-it" if you want to do stuff in them? or would it more depend on the Dockerfile, how you define the cmd.
New to Docker in general and trying to understand the basics on how to use it. Thanks for the help.
Running docker run/exec with -it means you run the docker container and attach an interactive terminal to it.
Note that you can also run docker applications without attaching to them, and they will still run in the background.
Docker allows you to run a program (which can be bash, but does not have to be) in an isolated environment.
For example, try running the jenkins docker image: https://hub.docker.com/_/jenkins.
this will create a container, without you having attach to it, and you would still be able to use it.
You can also attach to an existing, running container by using docker exec -it [container_name] bash.
You can also use docker logs to peek at the stdout of a certain docker container, without actually attaching to its shell interactively.
You almost never use docker start. It's only possible to use it in two unusual circumstances:
If you've created a container with docker create, then docker start will run the process you named there. (But it's much more common to use docker run to do both things together.)
If you've stopped a container with docker stop, docker start will run its process again. (But typically you'll want to docker rm the container once you've stopped it.)
Your question and other comments hint at using an interactive shell in an unmodified Alpine container. Neither is a typical practice. Usually you'll take some complete application and its dependencies and package it into an image, and docker run will run that complete packaged application. Tutorials like Docker's Build and run your image go through this workflow in reasonable detail.
My general day-to-day workflow involves building and testing a program outside of Docker. Once I believe it works, then I run docker build and docker run, and docker rm the container once I'm done. I rarely run docker exec: it is a useful debugging tool but not the standard way to interact with a process. docker start isn't something I really ever run.
Can anyone help me in the understanding difference between docker run & docker container run?
when i do docker run --help & docker container run --help from docker cmd line. I see the following
Run a command in a new container.
Is there any difference in how they run the container internally or both are same doing same work?
As per https://forums.docker.com/t/docker-run-and-docker-container-run/30526. docker run is still the old one, which will be deprecated soon but same is not confirmed.
They are exactly the same.
Prior to docker 1.13 the docker run command was only available. The CLI commands were then refactored to have the form docker COMMAND SUBCOMMAND, wherein this case the COMMAND is container and the SUBCOMMAND is run. This was done to have a more intuitive grouping of commands since the number of commands at the time has grown substantially.
You can read more under CLI restructured.
docker run no, we aren't even hiding it, it's staying as a permanent alias.
The rest, not any time soon. Maybe in a year or two if we're good about converting all > the docs to the new form, and communicating the new canonical way of doing things.
So, they are exactly same, just format changed, see discusstion about this PR: https://github.com/moby/moby/pull/26025
Maybe a bit late, but wanted to share a wider & cleaner image from The docker Handbook about the question:
Previously [...] the generic syntax for this command is as follows:
docker run <image name>
Although this is a perfectly valid command, there is a better way of dispatching commands to the docker daemon.
Prior to version 1.13, Docker had only the previously mentioned command syntax. Later on, the command-line was restructured to have the following syntax:
docker <object> <command> <options>
In this syntax:
<object> indicates the type of Docker object you'll be manipulating. This can be a container, image, network or volume object.
<command> indicates the task to be carried out by the daemon, that is the run command.
<options> can be any valid parameter that can override the default behavior of the command, like the --publish option for port mapping.
Thus,
docker container run :
container is the object
run is the command to be executed by Docker Daemon.
I use the dotnet3.5 image to run containers on win10 with docker desktop 2.1.0.1(37199). Sadly, I found that after I had created a container, did nothing to it, and left it alone for 4 days, the container automotically became unstoppable. The snapshot tells the story.
The container seemed existing there when docker ps -a, but I cannot get into the container by docker exec. And for I cannot stop it--the docker stop process hangs there after I use docker stop container2--I cannot rm the container.
The only way to resolve this issue is to restore docker desktop's factory setting.
By the way, although in the snapshot the running image is aspnet:3.5-windowsservercore-10.0.14393.953, this issue also happens when the aspnet:3.5
Does anyone have good ideas to the unstoppable container? Any suggestions are welcome.
The command used above is incorrect. There is a difference between the commands and options we use. "# docker ps" or "# docker container ls" will give you the list of currently running processes or active containers.
Whereas "-a" will give you all the list of all those which are used to date which contains the list of active and deleted containers.
In your case, the container was is not there and you are trying to access the one which is non-existing, which is why it is stuck.
I have two docker containers which are linked. The first one is a mariadb database and the other one is a MediaWiki instance. I don't need these two anymore, that's why I would like to stop and remove them.
My Problem is now, that I can't do that.
I tried a lot of things already:
Executing docker update --restart=no "containers". But it keeps restarting after I stop the container with docker container stop "container".
Tried to remove the images with no joy as they are in use by the containers (even if I kill the container and then quickly try to delete the image)
Restarted the entire Docker service with systemctl restart docker.
I even restarted my entire Server.
All of these with no positive result.
I'm kinda frustated.
I got 2 more containers running very well. (pyload and netdata). No problems at all with them.
As I'm new in the Docker world, please tell me what you need to help me :)
Thank you in advance!
Killing the container does not delete them. You have to remove the stopped containers before you can remove the images.
docker ps shows you the list of current running container. docker ps -a will show the list of all the containers (stopped and running).
First clean up all the containers that are not running via docker rm $(docker ps -aq)
Then delete the images that you dont want docker rmi $(docker images)
Try to reset to factory setting by clicking the bug icon of docker desktop and choose "reset to factory default". It will remove everything. It worked for me. I spent days to figure this out and finally I got it. Hopefully it helps you too!