This is a theory-cheatsheet, that complements docker commands cheatsheets. I find these kind of concept recaps handy time to time when I need to revisit fundamental concepts.

I'll start with the following image that shows the basic workflow in docker.

[pull]->(image)->[run]->(container)
          ↑                 ↑    ↑
          |                 |     \
        [build]            bash   [mount]
          |                 |        \    
      (Dockerfile)        [exec]   (volume)                

It shows the key elements in docker

1. image
2. Dockerfile ***
3. container
4. volumes

... and maybe

1. docker-compose.yml***

*** integral part of ecosystem, but might be not discussed
frequently in this guide

Order of operation

‏‏‎ ‎
The diagram explains the order of operation as:
‏‏‎ ‎

1. You can either pull an image into your local machine (stays in /var/lib/docker/overlay2 by default)
2. Or you can build an image from a Dockerfile
3. You can run the image to start up a container
   1. containers can be counted as running instances of an image; where image is the executable and the container is the process. (N.B. This is not an exact definition because a container can potentially be a collection of multiple processes.)
   2. see 4.1 later
   3. While on development phase of the docker image, it's good idea to run using -d flag
4. And you can execute different commands in running the containers, such as bash
   1. you can run and execute commands at the same time, which causes confusion between usage of run and exec commands
5. Because containers are processes, and everything is lost when a container is stopped, you can use Volumes as a mean of persistent storage.
   1. Volumes can be created and then mounted to containers
   2. Or creation and mounting of a volume can be done in one command as well ‏‏‎ ‎

Cleaning after work

1. Pruning
   1. because all these entities are somewhat losely-connected by default, stopping one doesn't remove the related artifacts. for which you can use docker system prune command to remove resources that are not needed anymore.
   2. docker system prune -a --volumes come handy to clean things time to time
      1. you can use docker system prune -af --volumes if you dont want to be prompted
   3. time to time you'll realize docker volumes to be treated specially, this is because volumes are treated to be persistent and to destroy and manage them, it should require more attention of the developer. ‏‏‎ ‎ ‏‏‎ ‎

2. Stopping / Removing

   1. Anything that is running needs to be stopped first, ie. containers.
      1. docker stop my_container
         1. it still doesn't mean the container has been removed though, it's just paused from executing
      2. docker rm my_container to remove the container
   2. To remove an image do docker image rm or docker rmi

   3. to remove a volume do docker volume rm

      1. A volume cannot be removed if it's being mounted to a container, in those cases you'll get a prompt
         while removing like
         

           Error response from daemon: remove 4e12af8913af888ba67243dec78419bf18adddc3c7a4b2345754b6db64293163: volume is in use - [c7188935a38a6c3f9f11297f8c98ce9996ef5ddad6e6187be62bad3001a66c8e]
         

‏‏‎ ‎

Checking things

‏‏‎ ‎

1. docker ps to list all running containers
   1. docker ps -a Show all containers (default shows just running)
2. docker image ls list images
   1. docker image ls -a Show all images (default hides intermediate images)
3. docker volume ls lists all volumes
4. Inspecting things Might be handy when you want to see different attributes of certain entity
   1. docker container inspect
   2. docker image inspect
   3. docker volume inspect

more to come...

‏‏‎ ‎
I will keep improving this article and may add more articles for this series if I get more responses. For example,

• Anatomy of Dockerfile
• Anatomy of docker-compose
• basic bash scripting for docker based development
• how to manage volumes efficiently
• best practises of docker monorepo

... and more

Background

Few years ago when I started working on docker containers; when laravel was in full swing, I didn't know where to start.

I was a beginner fullstack programmer, and I only knew a bit of ci/cd; and never worked in a project that had rigorous workflow requirement.

I kept on gathering my knowledge and always noted my understanding to share someday, so that people who are starting docker, it's easy to understand.

Do you have a specific thing that confuses you in docker? or something you want me to add in here? lets talk about that in the comments.