I've just done my first ever Docker deployment, when i run this command to see the status of recent processes...
docker ps -a
I get this output
My question is; what are those name referring to?
Those are random names generated for each container you are running.
You can see those names at pkg/namesgenerator/names-generator.go.
// Docker, starting from 0.7.x, generates names from notable scientists and hackers.
// Please, for any amazing man that you add to the list, consider adding an equally amazing woman to it, and vice versa.
right = [...]string{
// Muhammad ibn Jābir al-Ḥarrānī al-Battānī was a founding father of astronomy. https://en.wikipedia.org/wiki/Mu%E1%B8%A5ammad_ibn_J%C4%81bir_al-%E1%B8%A4arr%C4%81n%C4%AB_al-Batt%C4%81n%C4%AB
"albattani",
// Frances E. Allen, became the first female IBM Fellow in 1989. In 2006, she became the first female recipient of the ACM's Turing Award. https://en.wikipedia.org/wiki/Frances_E._Allen
"allen",
...
You could have fixed name by adding --name to your docker run commands.
That practice was introduced in commit 0d29244 by Michael Crosby (crosbymichael) for docker 0.6.5 in Oct. 2013:
Add -name for docker run
Remove docker link
Do not add container id as default name
Create an auto generated container name if not specified at runtime.
Solomon Hykes (shykes) evolved that practice in docker 0.7 with commit 5d6ef317:
New collection of random names for 0.7:
mood + famous inventor.
Eg. 'sad-tesla' or 'naughty-turing'
As VonC already wrote, "those are random names generated for each container you are running". So why should you use custom names?
docker run [image-name] -[container-name]
docker run wildfly-8.1 -mywildfly
well if you want to stop/kill/run/inspect or do anything with your container, you can use your name to do so:
docker kill mydocker
docker run mydocker
Otherwise you have to do docker ps all the time and check the id (since you will not remember those made-up custom names).
One important sidenote, if you assign custom name to docker, it will be forever assigned to that specific container, which means even if you kill the container, it is not running anymore, you cannot reuse the name.
If you run
docker ps -a
you can see the old one is still there, but stopped. You can't re-use a container name until the previous container has been removed by docker rm.
To remove containers older than some custom time, use the command:
$ docker ps -a | grep 'weeks ago' | awk '{print $1}' | xargs
--no-run-if-empty docker rm
More on removing containers here.
Related
I've just done my first ever Docker deployment, when i run this command to see the status of recent processes...
docker ps -a
I get this output
My question is; what are those name referring to?
Those are random names generated for each container you are running.
You can see those names at pkg/namesgenerator/names-generator.go.
// Docker, starting from 0.7.x, generates names from notable scientists and hackers.
// Please, for any amazing man that you add to the list, consider adding an equally amazing woman to it, and vice versa.
right = [...]string{
// Muhammad ibn Jābir al-Ḥarrānī al-Battānī was a founding father of astronomy. https://en.wikipedia.org/wiki/Mu%E1%B8%A5ammad_ibn_J%C4%81bir_al-%E1%B8%A4arr%C4%81n%C4%AB_al-Batt%C4%81n%C4%AB
"albattani",
// Frances E. Allen, became the first female IBM Fellow in 1989. In 2006, she became the first female recipient of the ACM's Turing Award. https://en.wikipedia.org/wiki/Frances_E._Allen
"allen",
...
You could have fixed name by adding --name to your docker run commands.
That practice was introduced in commit 0d29244 by Michael Crosby (crosbymichael) for docker 0.6.5 in Oct. 2013:
Add -name for docker run
Remove docker link
Do not add container id as default name
Create an auto generated container name if not specified at runtime.
Solomon Hykes (shykes) evolved that practice in docker 0.7 with commit 5d6ef317:
New collection of random names for 0.7:
mood + famous inventor.
Eg. 'sad-tesla' or 'naughty-turing'
As VonC already wrote, "those are random names generated for each container you are running". So why should you use custom names?
docker run [image-name] -[container-name]
docker run wildfly-8.1 -mywildfly
well if you want to stop/kill/run/inspect or do anything with your container, you can use your name to do so:
docker kill mydocker
docker run mydocker
Otherwise you have to do docker ps all the time and check the id (since you will not remember those made-up custom names).
One important sidenote, if you assign custom name to docker, it will be forever assigned to that specific container, which means even if you kill the container, it is not running anymore, you cannot reuse the name.
If you run
docker ps -a
you can see the old one is still there, but stopped. You can't re-use a container name until the previous container has been removed by docker rm.
To remove containers older than some custom time, use the command:
$ docker ps -a | grep 'weeks ago' | awk '{print $1}' | xargs
--no-run-if-empty docker rm
More on removing containers here.
I have many Docker containers both running and exited. I only want to keep the containers that were created before today/some specified time -- I would like to remove all containers created today. Easiest way to approach this?
Out of the box on all OS there is the possibility to remove all containers younger than a given one:
docker rm -f $(docker ps -a --filter 'since=<containername>' --format "{{.ID}}")
so the container given in since will be kept, but all newer ones not. Maybe that suits your use case.
If you really need a period of time there will be some bash magic doing that. But specify your needs exactly then..
In detail:
docker rm: removing one or more containers
-f: force running containers to stop
docker ps -a: listing all containers
--filter 'since=..' filtering containers created since given with all details
--format "{{.ID}}": filtering ID-column only
As a novice user of a complicated CI system, trying out scripts, I am confused whether my scripts are executed directly by my system's bash, or from a docker container running on the same system. Hence the question: what command (environment variable query or whatever) could tell me whether I am in docker or not?
I guess you are trying to find out whether your script is run from within the context of a docker container OR from within the host machine which runs docker.
Another way of looking at this is: you have a script which is running and this script is actually a process. And any given process has an associated PID.
You might want to find out if this process is running within a docker container or directly within the host machine.
Let's say that your process runs within docker container, then we can conclude that docker process is the parent of your process
Running the top command would list all the processes in the machine. Then using another command ps -axfo pid,uname,cmd would give full listing of processes
Let's say you have identified the parent process id (for eg: 2871). Now you can run
docker ps | awk '{ print $1}' | xargs docker inspect -f '{{ .State.Pid }} {{ .Config.Hostname }}' | grep 2871
Using this you can identify the container containing the process
If we run pstree, we could the process tree all the way upto boot process
Courtesy:
Finding out to which docker container a process belongs to
how-do-i-get-the-parent-process-id-of-a-given-child-process
Hope this helps
If you find yourself in a container, you must have execute a command to enter that container.
If you forgot where you are, type docker ps. If it fails, you are in a docker container.
Edit :
Obviously, this simple trick does not work when you run docker in docker.
I already have a running container for both postgres and redis in use for various things. However, I started those from the command line months ago. Now I'm trying to install a new application and the recipe for this involves writing out a docker compose file which includes both postgres and redis as services.
Can the compose file be modified in such a way as to specify the already-running containers? Postgres already does a fine job of siloing any of the data, and I can't imagine that it would be a problem to reuse the running redis.
Should I even reuse them? It occurs to me that I could run multiple containers for both, and I'm not sure there would be any disadvantage to that (other than a cluttered docker ps output).
When I set container_name to the names of the existing containers, I get what I assume is a rather typical error of:
cb7cb3e78dc50b527f71b71b7842e1a1c". You have to remove (or rename) that container to be able to reuse that name.
Followed by a few that compain that the ports are already in use (5432, 6579, etc).
Other answers here on Stackoverflow suggest that if I had originally invoked these services from another compose file with the exact same details, I could do so here as well and it would reuse them. But the command I used to start them was somehow never written to my bash_history, so I'm not even sure of the details (other than name, ports, and restart always).
Are you looking for docker-compose's external_links keyword?
external_links allows you reuse already running containers.
According to docker-compose specification:
This keyword links to containers started outside this docker-compose.yml or even outside of Compose, especially for containers that provide shared or common services. external_links follow semantics similar to the legacy option links when specifying both the container name and the link alias (CONTAINER:ALIAS).
And here's the syntax:
external_links:
- redis_1
- project_db_1:mysql
- project_db_1:postgresql
You can give name for your container. If there is no container with the given name, then it is the first time to run the image. If the named container is found, restart the container.
In this way, you can reuse the container. Here is my sample script.
containerName="IamContainer"
if docker ps -a --format '{{.Names}}' | grep -Eq "^${containerName}\$"; then
docker restart ${containerName}
else
docker run --name ${containerName} -d hello-world
fi
You probably don't want to keep using a container that you don't know how to create. However, the good news is that you should be able to figure out how you can create your container again by inspecting it with the command
$ docker container inspect ID
This will display all settings, the docker-compose specific ones will be under Config.Labels. For container reuse across projects, you'd be interested in the values of com.docker.compose.project and com.docker.compose.service, so that you can pass them to docker-compose --project-name and use them as the service's name in your docker-compose.yaml.
When I'm debugging my Dockerfile, y constantly need to run these two commands:
$ docker build -t myuser/myapp:mytag - < myapp.docker # to create the container
$ docker run -i -t myuser/myapp:mytag /bin/bash # to enter the container and see what's going on when something went wrong
("mytag" is usually something like "production", "testing", or "development". Not sure if I'm supposed to use tags this way)
But now the second command doesn't seem to work anymore: it's starting an old container. If I list all the containers with $ docker images, I see my tagged container in the 3rd place, and other untagged containers before it. If I use the ID of the 1st container it works fine, but it will be annoying to do it that way, I will have to search for its ID every time.
What am I doing wrong?
You just have to start and attach a container using:
docker start -i #ContainerID
It's important to be clear about containers vs images. It sounds like your tagged image is 3rd in the list of images, and that you believe the first image that only has n ID really should be tagged but it isn't. This probably means that there's a problem building the image. The docker build output is verbose by default and should show you the problem.
As an aside, I'm not entirely sure about your use case but the idea of having different containers for development, testing and production is an anti-pattern. The entire point is to minimize differences between execution environments. In most cases you should use the same image but provide different environment variables to configure the application as desired for each environment. But again, I'm sure there are reasons to do this and you may have a legitimate one.
Here's what I use:
run_most_recent_container() { docker exec -it `docker ps -a --no-trunc -q | head -n 1` bash; }