A container is close to a VM. While a VM is entirely a new machine (from a software view) build on a physical machine, a container doesn’t have all the component a machine usually has. To be more precise, it doesn’t have a whole OS, but only what it needs to run its applications. It is built from an image, which corresponds to its configuration.
You might heard of Docker-compose. The difference between Docker and Docker-compose is simple: docker commands are focused on only one container (or image) at once while docker-compose manage several containers docker.
These few commands are in my mind the first you need to know when using Docker.
docker ps (-a)
docker ps displays every docker instance currently running in your environment. If you add the
-a option, then you even have the stopped ones.
docker images (-a)
docker images show to you the images you have build, and the
-a show you the intermediate images.
docker network ls
docker network ls list the networks and
docker-compose ps displays all the containers once started with it (currently running or not).
You now need images and containers to test the few previous commands.
docker-compose up (-d) (--build)
The docker-compose is easiest because you only need 2 commands: up and stop.
stop is explicit and stop (not remove) your containers, but
up require more explanations: it will build your images if they aren't already and will start your dockers. If you want to re-build your images, use the option
--build (you can also use the command
docker-compose build to only build the images). The option
-d, which means "detach" make the containers run in the background.
docker build (-t <NAME>) <PATH>/<URL>
With Docker, you need a separate command to build your image where you can specify the name of your image and you have to specify the PATH or URL to your context (this can be a git repository).
docker run (-d) (-p <hostPort>:<containerPort>) (--name <NAME>) <IMGNAME>/<IMGID>
run create the container using the image you tell it. You can specify lots of parameters, I recommend you to add a name to your container and you may need to specify some ports to expose. As for docker-compose, the
-d make the container run in the background.
docker start <ID>/<NAME>
docker stop <ID>/<NAME>
stop shouldn’t be hard to understand, but you have to note that you can only start containers already stopped, this means already built with
docker exec -it <NAME>/<ID> <“sh”>/<”/bin/bash”>
This command allows you to connect to the shell of your container. I prefer using "/bin/bash" but your container may not have bash installed and only "sh" which is more common. If you put some special configuration to your container, you may need to use extra arguments to connect to it. This command can do much more than this, I recommend to read the doc for further information.
These commands remove your containers and images, you will likely need them to save disk space.
docker rm <ID>/<NAME>
docker rm remove only one container when
docker-compose rm remove every container started with a docker-compose command.
docker rmi <ID>/<NAME>
docker rmi delete the image you give as a parameter and recursively all the images intermediate used to build it.
The commands below are useful when you need to debug some of your containers (or more often the applications you deploy in it).
docker logs <ID>/<NAME> (-f --tail <NBLINE>)
This command prints you the logs of the container you specify. If you use the option
-f --tail <NBLINE> you can follow the live flux of your logs (<NBLINE> is the number of lines you want to display. Keep in mind to choose a number of lines you can handle and to not be overwhelmed by your logs).
docker-compose logs (<ID>/<NAME>)
The option (<ID>/<NAME>) with the
docker-compose logs let you see the logs from only one container instead of every logs. The point here is if you don’t use the
-d option when using
docker run or
docker-compose up you will see your logs directly (but you will need to stop the container to quit the view). It can still be useful to debug launching apps.