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.
Related
TLDR: When using docker compose, I can simply recreate a container by changing its configuration and/or image in the docker-compose.yml file along with running docker-compose up. Is there any generic equivalent for recreating a container (to apply changes) which was created by a bare docker create/run command?
Elaborating a bit:
The associated docker compose documentation states:
If there are existing containers for a service, and the service’s configuration or image was changed after the container’s creation, docker-compose up picks up the changes by stopping and recreating the containers (preserving mounted volumes).
I'm having troubles to understand which underlaying steps are actually performed during this recreation, as e.g. the docker (without compose) documentation doesn't really seem to use the recreate term at all.
Is it safe to simply run docker container rm xy and then docker container create/run (along with passing the full and modified configuration)? Or is docker compose actually doing more under the hood?
I already found answers about applying specific configuration changes like e.g. this one about port mappings, but I'm still wondering whether there is a more general answer to this.
I'm having troubles to understand which underlaying steps are actually performed during this recreation, as e.g. the docker (without compose) documentation doesn't really seem to use the recreate term at all.
docker-compose is a high level tool; it performs in a single operation what would require multiple commands using the docker cli. When docker-compose says, "docker-compose up picks up the changes by stopping and recreating the containers", it means it is doing the equivalent of:
docker stop <somecontainer>
docker rm <somecontainer>
docker run ...
(Where ... represents whatever configuration is implied by the service definition in your docker-compose.yaml).
Let's say it recognizes a change in container1 it does (not really, working via API):
docker compose rm -fs container1
docker compose create (--build) container1
docker compose start container1
What is partially close to (depending on your compose-config):
docker rm -f projectname_container1
(docker build --flags)
docker create --allDozensOfAttributes projectname_container1
docker start projectname_container1
docker network connect (--flags) projectname_networkname projectname_container1
and maybe more..
so i would advise to use the docker compose commands for single services instead of docker cli if suitable..
The issue is that the variables and settings are not exposed through any docker apis. It may be possible by way of connecting directly to the docker socket, parsing the variables, and then stopping/removing the container and recreating it.
This would be prone to all kinds of errors and would require lots of debugging to get these values.
What I do is to simply store my docker commands in a shell script. You can just save the command you need to run into a text file, name it .sh, set the -x on the file, then run it. Then when you stop/delete the container, you can just rerun the shell script.
Another thing you can do would be to replace the docker command with a function (in something like your ~/.bashrc) that stores the arguments to a text file and rechecks that text file with a passed argument (like "recreate" followed by a name). However, I'm more a fan of doing docker containers in their own shell scripts as its more portable.
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:
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.
I have a container with PHP and a linked container with MySQL database, because I need an ability to run PHPUnit with database (integration tests).
The basic command looks like this:
docker run -i --rm --link db binarydata/phpunit php script.php
I have created db container and started it before running this command.
binarydata/phpunit container gets removed after a command was run. But db container stays up and running.
Question is: how can I achieve --rm functionality on a linked container, so it will be removed too after command was executed?
how can I achieve --rm functionality on a linked container, so it will be removed too after command was executed?
First, you don't have to use --link anymore with docker 1.10+. docker-compose will create for you a network in which all containers see each others.
And with docker-compose alias, you can declare your binary/phpunit as "db" for other containers to use.
Second, with that network in place, if you stop/remove the php container, it will be removed from said network, including its alias 'db'.
That differs from the old link (docker 1.8 and before), which would modify the /etc/hosts of the container who needed it. In that case, removing the linked container would not, indeed, change the /etc/hosts.
With the new embedded docker-daemon DNS, there is no longer a need for that.
Matt suggests in the comments the following command and caveats:
docker-compose up --abort-on-container-exit --force-recreate otherwise the command never returns and the db container would never be removed.
up messes with stdout a bit though.
The exit status for the tests will be lost too, it's printed to screen instead.
I created a data only container containing static HTML files that are intended to be consumed by a nginx container. Goal is that my webapp is providing a volume that nginx can use.
For this reason I created a simple Dockerfile:
FROM scratch
MAINTAINER me <me#me.com>
ADD dist/ /webappp/
When I run the created container from command line run -d -v /webappp --name webapp myOrg/webapp echo yo
I get the error Error response from daemon: Cannot start container db7fd5cd40d76311f8776b1710b4fe6d66284fe75253a806e281cd8ae5169637: exec: "echo": executable file not found in $PATH which if of course correct because the image has no commands at all the can be executed. Running a container without a command is not possible.
While this error on command line is not a big problem for me because I know the data container is still created and can now be accessed by nginx it turns out to be a no go if I want to automate it with Vagrant. The automated processes always fail because of this error.
My only solution so far is to extend my little handy image from from a distro which IMHO doesn't make sense for a data only container in order just to call echo or true!
Is there a NOP exec command in docker or does docker need always to execute something, is it possible to run a scratch container that does nothing or does not produce an error.
As mentioned in the Docker manual: The container don't need to be running. It also doesn't say that the container "should" be able to run at all.
So instead of echoing something stupid by running a data only container e.g. docker run -v /webappp --name webapp myOrg/webapp echo yo
It is already enough to just create the container and never run/start it.
docker create -v /webappp --name webapp myOrg/webapp
Note to self: Vagrant does not support docker create when provisioning!
Why are you using scratch?
Just use the nginx image as a base. You already have the image cached so it won't take up any more space and you'll be able to call echo.
Some references for data containers:
Data-only container madness
Understanding Volumes in Docker
Offiical docs on data containers