A container is like a small, portable, and self-sufficient unit that contains everything needed to run a specific application. This includes the application itself, the libraries, tools, runtime, and minimal system dependencies required by the application.
Key Concepts
Self-Contained:
A container includes all the necessary components for an application to run. Think of it as a "package" that contains the application and everything it needs, so it doesn't rely on the host system’s configuration.
Docker Container Images:
These are templates used to create containers. They bundle the application code, runtime, libraries, and settings needed to run the application. This makes the application run consistently regardless of where it's deployed.
Reliability and Speed:
Containers ensure that the application runs reliably by keeping the environment consistent across different deployment scenarios. They promote quick and seamless deployment, making it easier to move applications between development, testing, and production environments.
Containers and virtual machines are both technologies used to isolate applications and their dependencies, but they have some key differences:
1. Resource Utilization
Containers:
Shared OS Kernel: Containers share the host operating system kernel, which makes them lightweight.
Efficiency: Since they don't require a full OS, they use fewer system resources, making them faster and more efficient.
Virtual Machines (VMs):
Full OS and Hypervisor: Each VM runs a complete operating system on top of a hypervisor.
Resource Intensive: This makes VMs more resource-intensive as they require more memory and processing power.
Example:
If you have 5 applications to run, using containers might only require the resources equivalent to one full OS. Using VMs, you might need 5 separate OS instances, significantly increasing resource usage.
2. Portability
Containers:
High Portability: Containers are designed to be portable and can run on any system with a compatible container runtime (like Docker).
Consistency: They ensure the application behaves the same regardless of where they are deployed.
Virtual Machines (VMs):
Dependent on Hypervisor: VMs need a compatible hypervisor (like VMware, Hyper-V) to run, making them less portable.
Migration: Moving VMs between different environments can be more complex.
Example:
You can take a containerized application from your laptop to a cloud server without any changes. For a VM, you might need to ensure the cloud server supports the specific hypervisor used by your VM.
3. Security
Containers:
Shared OS: Containers share the host operating system, which can pose a security risk if one container is compromised.
Isolation: While they provide some level of isolation, it’s less robust compared to VMs.
Virtual Machines (VMs):
Full Isolation: Each VM has its own OS and is isolated from the host and other VMs, providing stronger security boundaries.
Higher Security: If one VM is compromised, it’s less likely to affect others.
Example:
In a multi-tenant environment, using VMs can prevent one tenant’s compromised VM from affecting others. Containers might require additional security measures to achieve the same level of isolation.
4. Management
Containers:
Ease of Management: Containers are lightweight and can be started, stopped, and scaled quickly.
Orchestration Tools: Tools like Kubernetes make it easier to manage large numbers of containers.
Virtual Machines (VMs):
Complex Management: VMs are heavier and take longer to start and stop.
Traditional Tools: Managing VMs often requires more traditional and complex management tools.
Example:
Deploying a new version of an application can be done in seconds with containers, but might take minutes or longer with VMs due to their larger size and longer startup times.
Containers are lightweight because they use a technology called containerization, which allows them to share the host operating system's kernel and libraries, while still providing isolation for the application and its dependencies. This results in a smaller footprint compared to traditional virtual machines, as the containers do not need to include a full operating system. Additionally, Docker containers are designed to be minimal, only including what is necessary for the application to run, further reducing their size.
Let's try to understand this with an example:
Below is the screenshot of official ubuntu base image which you can use for your container. It's just ~ 22 MB, isn't it very small ? on a contrary if you look at official ubuntu VM image it will be close to ~ 2.3 GB. So the container base image is almost 100 times less than VM image.
/bin: contains binary executable files, such as the ls, cp, and ps commands.
/sbin: contains system binary executable files, such as the init and shutdown commands.
/etc: contains configuration files for various system services.
/lib: contains library files that are used by the binary executables.
/usr: contains user-related files and utilities, such as applications, libraries, and documentation.
/var: contains variable data, such as log files, spool files, and temporary files.
/root: is the home directory of the root user.
The host's file system: Docker containers can access the host file system using bind mounts, which allow the container to read and write files in the host file system.
Networking stack: The host's networking stack is used to provide network connectivity to the container. Docker containers can be connected to the host's network directly or through a virtual network.
System calls: The host's kernel handles system calls from the container, which is how the container accesses the host's resources, such as CPU, memory, and I/O.
Namespaces: Docker containers use Linux namespaces to create isolated environments for the container's processes. Namespaces provide isolation for resources such as the file system, process ID, and network.
Control groups (cgroups): Docker containers use cgroups to limit and control the amount of resources, such as CPU, memory, and I/O, that a container can access.
It's important to note that while a container uses resources from the host operating system, it is still isolated from the host and other containers, so changes to the container do not affect the host or other containers.
Container base images are typically smaller compared to VM images because they are designed to be minimalist and only contain the necessary components for running a specific application or service. VMs, on the other hand, emulate an entire operating system, including all its libraries, utilities, and system files, resulting in a much larger size.
Docker is a containerization platform that provides easy way to containerize your applications, which means, using Docker you can build container images, run the images to create containers and also push these containers to container regestries such as DockerHub.
In simple words, you can understand as containerization is a concept or technology and Docker Implements Containerization.
The above picture, clearly indicates that Docker Deamon is brain of Docker. If Docker Deamon is killed, stops working for some reasons, Docker is brain dead.
There are three important things,
- docker build -> builds docker images from Dockerfile
- docker run -> runs container from docker images
- docker push -> push the container image to public/private regestries to share the docker images.
The Docker daemon (dockerd) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services.
The Docker client (docker) is the primary way that many Docker users interact with Docker. When you use commands such as docker run, the client sends these commands to dockerd, which carries them out. The docker command uses the Docker API. The Docker client can communicate with more than one daemon.
Docker Desktop is an easy-to-install application for your Mac, Windows or Linux environment that enables you to build and share containerized applications and microservices.
A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry.
When you use the docker pull or docker run commands, the required images are pulled from your configured registry. When you use the docker push command, your image is pushed to your configured registry.
Docker objects
When you use Docker, you are creating and using images, containers, networks, volumes, plugins, and other objects. This section is a brief overview of some of those objects.
Dockerfile is a file where you provide the steps to build your Docker Image.
An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the ubuntu image, but installs the Apache web server and your application, as well as the configuration details needed to make your application run.
You might create your own images or you might only use those created by others and published in a registry. To build your own image, you create a Dockerfile with a simple syntax for defining the steps needed to create the image and run it. Each instruction in a Dockerfile creates a layer in the image. When you change the Dockerfile and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization technologies.
A very detailed instructions to install Docker are provide in the below link
https://docs.docker.com/get-docker/
For Demo,
You can create an Ubuntu EC2 Instance on AWS and run the below commands to install docker.
sudo apt update
sudo apt install docker.io -y
A very common mistake that many beginners do is, After they install docker using the sudo access, they miss the step to Start the Docker daemon and grant acess to the user they want to use to interact with docker and run docker commands.
Always ensure the docker daemon is up and running.
A easy way to verify your Docker installation is by running the below command
docker run hello-world
If the output says:
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
This can mean two things,
- Docker deamon is not running.
- Your user does not have access to run docker commands.
You use the below command to verify if the docker daemon is actually started and Active
sudo systemctl status docker
If you notice that the docker daemon is not running, you can start the daemon using the below command
sudo systemctl start docker
To grant access to your user to run the docker command, you should add the user to the Docker Linux group. Docker group is create by default when docker is installed.
sudo usermod -aG docker ubuntu
In the above command ubuntu is the name of the user, you can change the username appropriately.
NOTE: : You need to logout and login back for the changes to be reflected.
Use the same command again, to verify that docker is up and running.
docker run hello-world
Output should look like:
....
....
Hello from Docker!
This message shows that your installation appears to be working correctly.
...
...
Great Job, Now start with the examples folder to write your first Dockerfile and move to the next examples. Happy Learning :)
git clone https://github.com/kohlidevops/DockerZeroToHero.git
cd examples/first-docker-file
Login to Docker [Create an account with https://hub.docker.com/]
docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: latchudevops
Password:
WARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
You need to change the username accoringly in the below command
docker build -t latchudevops/my-first-docker-image:latest .
Output of the above command
Sending build context to Docker daemon 992.8kB
Step 1/6 : FROM ubuntu:latest
latest: Pulling from library/ubuntu
677076032cca: Pull complete
Digest: sha256:9a0bdde4188b896a372804be2384015e90e3f84906b750c1a53539b585fbbe7f
Status: Downloaded newer image for ubuntu:latest
---> 58db3edaf2be
Step 2/6 : WORKDIR /app
---> Running in 630f5e4db7d3
Removing intermediate container 630f5e4db7d3
---> 6b1d9f654263
Step 3/6 : COPY . /app
---> 984edffabc23
Step 4/6 : RUN apt-get update && apt-get install -y python3 python3-pip
---> Running in a558acdc9b03
Step 5/6 : ENV NAME World
---> Running in 733207001f2e
Removing intermediate container 733207001f2e
---> 94128cf6be21
Step 6/6 : CMD ["python3", "app.py"]
---> Running in 5d60ad3a59ff
Removing intermediate container 5d60ad3a59ff
---> 960d37536dcd
Successfully built 960d37536dcd
Successfully tagged latchudevops/my-first-docker-image:latest
docker images
Output
REPOSITORY TAG IMAGE ID CREATED SIZE
latchudevops/my-first-docker-image latest 960d37536dcd 26 seconds ago 467MB
ubuntu latest 58db3edaf2be 13 days ago 77.8MB
hello-world latest feb5d9fea6a5 16 months ago 13.3kB
docker run -it latchudevops/my-first-docker-image
Output
Hello World
docker push latchudevops/my-first-docker-image
Output
Using default tag: latest
The push refers to repository [docker.io/latchudevops/my-first-docker-image]
896818320e80: Pushed
b8088c305a52: Pushed
69dd4ccec1a0: Pushed
c5ff2d88f679: Mounted from library/ubuntu
latest: digest: sha256:6e49841ad9e720a7baedcd41f9b666fcd7b583151d0763fe78101bb8221b1d88 size: 1157