Here’s a Docker cheat sheet that covers the most commonly used Docker commands, organized by categories.

Docker Basics

• docker --version: Show the Docker version installed on your system.
• docker info: Display system-wide information, including Docker version, number of containers, and images.
• docker help: Get help on Docker commands.

Docker Images

• docker images: List all Docker images on your system.
• docker pull <image>: Download an image from a Docker registry (e.g., Docker Hub).
• docker build -t <image_name> .: Build an image from a Dockerfile in the current directory and tag it with a name.
• docker tag <image_id> <new_image_name>: Tag an image with a new name.
• docker rmi <image>: Remove one or more images.
• docker history <image>: Show the history of an image (layers).

Docker Containers

• docker ps: List all running containers.
• docker ps -a: List all containers (running and stopped).
• docker run <image>: Run a container from an image.
• docker run -d <image>: Run a container in detached mode (in the background).
• docker run -it <image>: Run a container in interactive mode with a terminal.
• docker run -p <host_port>:<container_port> <image>: Map a port from the host to the container.
• docker stop <container>: Stop a running container.
• docker start <container>: Start a stopped container.
• docker restart <container>: Restart a running container.
• docker rm <container>: Remove a stopped container.
• docker logs <container>: View the logs of a container.
• docker exec -it <container> <command>: Execute a command inside a running container (e.g., bash to open a shell).

Docker Networks

• docker network ls: List all Docker networks.
• docker network create <network_name>: Create a new Docker network.
• docker network inspect <network_name>: View detailed information about a network.
• docker network connect <network_name> <container>: Connect a container to a network.
• docker network disconnect <network_name> <container>: Disconnect a container from a network.
• docker network rm <network_name>: Remove a Docker network.

Docker Volumes

• docker volume ls: List all Docker volumes.
• docker volume create <volume_name>: Create a new Docker volume.
• docker volume inspect <volume_name>: View detailed information about a volume.
• docker volume rm <volume_name>: Remove a Docker volume.
• docker run -v <volume_name>:<container_path> <image>: Mount a volume inside a container.

Docker Compose

• docker-compose up: Start the services defined in a docker-compose.yml file.
• docker-compose down: Stop and remove containers, networks, volumes, and images created by docker-compose up.
• docker-compose build: Build or rebuild services defined in a docker-compose.yml file.
• docker-compose ps: List containers managed by Docker Compose.
• docker-compose logs: View logs for services managed by Docker Compose.
• docker-compose exec <service> <command>: Execute a command in a running service.

Dockerfile Directives

• FROM: Specifies the base image.
• WORKDIR: Sets the working directory inside the container.
• COPY: Copies files from the host to the container.
• RUN: Executes a command in the container.
• CMD: Specifies the command to run when the container starts.
• EXPOSE: Specifies the port on which the container will listen.
• ENV: Sets environment variables.
• ENTRYPOINT: Configures the container to run as an executable.

Docker Cleanup Commands

• docker system prune: Remove unused data (stopped containers, unused networks, dangling images, etc.).
• docker container prune: Remove all stopped containers.
• docker image prune: Remove unused images.
• docker volume prune: Remove all unused volumes.
• docker network prune: Remove all unused networks.

Miscellaneous

• docker inspect <container_or_image>: Return low-level information on Docker objects (containers, images, volumes, etc.).
• docker stats: Display a live stream of container(s) resource usage statistics.
• docker top <container>: Display the running processes of a container.
• docker cp <container>:<path> <local_path>: Copy files from a container to the host or vice versa.

The Client-Server Architecture

Once upon a time in the electronic city of Banglore, there was a popular digital tea kadai. This cafe was unique because it didn’t serve traditional coffee or pastries. Instead, it served data and services to its customers developers, businesses, and tech enthusiasts who were hungry for information and resources.

The Client:

One day, a young developer named Dinesh walked into tea kadai. He was working on a new app and needed to fetch some data from the cafe’s servers. In this story, Dinesh represents the client. As a client, his role was to request specific services and data from the cafe. He approached the counter and handed over his order slip, detailing what he needed.

The Server:

Behind the counter was Syed, the tea master, representing the server. Syed’s job was to take Dinesh’s request, process it, and deliver the requested data back to him.

Syed had access to a vast array of resources stored in the cafe’s back room, where all the data was kept. When Dinesh made his request, Syed quickly went to the back, gathered the data, and handed it back to Dinesh.

The client-server architecture at Tea Kadai worked seamlessly.

Dinesh, as the client, could make requests whenever he needed, and

Syed, as the server, would respond by providing the requested data.

This interaction was efficient, allowing many clients to be served by a single server at the cafe.

Docker’s Client-Server Technology

As Tea Kadai grew in popularity, it decided to expand its services to deliver data more efficiently and flexibly. To do this, they adopted a new technology called Docker, which helped them manage their operations more effectively.

Docker Client:

In the world of Docker at Tea Kadai, Dinesh still played the role of the client. But now, instead of just making simple data requests, she could request entire environments where he could test and run his applications.

These environments, called containers, were like personalized booths in the cafe where Alice could have her own setup with everything she needed to work on her app.

Dinesh used a special tool called the Docker Client to place his order. With this tool, he could specify exactly what he wanted in his container like the operating system, libraries, and applications needed for his app. The Docker Client was her interface for communicating with the cafe’s new backend system.

Docker Server (Daemon):

Behind the scenes, Tea Kadai had installed a powerful system known as the Docker Daemon, which acted as the server in this setup. The Docker Daemon was responsible for creating, running, and managing the containers requested by clients like Dinesh.

When Dinesh sent his container request using the Docker Client, the Docker Daemon received it, built the container environment, and handed it back to Dinesh for use.

Docker Images:

The Tea Kadai had a collection of premade recipes called Docker Images. These images were like blueprints for creating containers, containing all the necessary ingredients and instructions.

When Dinesh requested a new container, the Docker Daemon used these images to quickly prepare the environment.

Flexibility and Isolation:

The beauty of Docker at Tea Kadai was that it allowed multiple clients like Dinesh to have their containers running simultaneously, each isolated from the others. This isolation ensured that one client’s work wouldn’t interfere with another’s, just like having separate booths in the cafe for each customer. Dinesh could run, test, and even destroy his environment without affecting anyone else.

At the end,

In the vibrant city of Banglore, Tea Kadai thrived by adopting client-server architecture and Docker’s client-server technology. This approach allowed them to efficiently serve data and services while providing flexible, isolated environments for their clients. Dinesh and many others continued to come to tea kadai, knowing they could always get what they needed in a reliable and innovative way.

SNo.	Virtual Machines(VM)	Containers
1	VM is a piece of software that allows you to install other software inside of it so you control it virtually as opposed to installing the software directly on the computer.	While a container is software that allows different functionalities of an application independently.
2.	Applications running on a VM system, or hypervisor, can run different OS.	While applications running in a container environment share a single OS.
3.	VM virtualizes the computer system, meaning its hardware.	While containers virtualize the operating system, or the software only.
4.	VM size is very large, generally in gigabytes.	While the size of the container is very light, generally a few hundred megabytes, though it may vary as per use.
5.	VM takes longer to run than containers, the exact time depending on the underlying hardware.	While containers take far less time to run.
6.	VM uses a lot of system memory.	While containers require very less memory.
7.	VM is more secure, as the underlying hardware isn’t shared between processes.	While containers are less secure, as the virtualization is software-based, and memory is shared.
8.	VMs are useful when we require all of the OS resources to run various applications.	While containers are useful when we are required to maximize the running applications using minimal servers.
9.	Examples of Type 1 hypervisors are KVM, Xen, and VMware. Virtualbox is a Type 2 hypervisor	Examples of containers are RancherOS, PhotonOS, and Containers by Docker.