docker bao gồm các images và container
chạy 1 image sẽ khởi tạo 1 container có chứa image đó
1 container giống như 1 máy áo hoàn toàn, giả sử khi build 1 container từ ubbuntu image ta sẽ được 1 container chạy ubuntu, container này là một môi trường hoàn toàn độc lập, các nội dung ghi thêm sau khi khởi chạy container được ghi lên 1 layer gọi là writeable layer, lớp writeable layer này sẽ không xuất hiện nếu build 1 cái container khác cũng từ image ubuntu lúc nãy vì lần build này lại tạo nên 1 container mới hoàn toàn độc lập.
Hiểu nôm na như hình vẽ dưới đây thì lớp image layer là consistency, có thể sử dụng để build lên hàng chục cái container khác nhau và cùng share chung 1 lượng disk amount(gọi là virtual disk).
- container use/share with host os kernel while virtual machine comes with its own guest os which is just as heavy as the host os.
uname -a
# Linux ubuntu 5.15.0-1014-azure #17~20.04.1-Ubuntu SMP Thu Jun 23 20:01:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
docker run alpine uname -a
# Linux 18fd4260bd0b 5.15.0-1014-azure #17~20.04.1-Ubuntu SMP Thu Jun 23 20:01:51 UTC 2022 x86_64 Linux
uname -a command on host operating system to print out the kernel details. we can see kernel detail in container run alpine linux same as in host machine
Prior to Docker version 1.11, the Docker Engine daemon downloaded container images, launched container processes, exposed a remote API, and acted as a log collection daemon, all in a centralized process running as root. ince version 1.11, the Docker daemon no longer handles the execution of containers itself. The execution of containers is handled by a container runtime which is called containerd.
The containerd component makes sure that the container image you want to run is in place, then starts the container by calling a component named runc to do the business of actually instantiating a container.
A containerized process, just as any other Linux process, uses system calls, and needs permissions. And that is why all the traditional Linux stuff like system calls, namespaces, control groups, permissions, capabilities are all related to docker.
Applications run in what’s called user space, which has a lower level of privilege than the operating system kernel. If an application wants to do something like accessing a file, communicate using a network, create a file, or even find the time of day, it has to ask the kernel to do it on the application’s behalf. The kernel does it for you then hands control back to userspace. The programmatic interface that the userspace code uses to make these requests of the kernel is known as the system call or syscall interface.
On Linux, any Linux system, whether you are using docker containers or not, you are using files. Everything is a file in Linux
Initially Docker was built as an abstraction layer on top of Linux Containers (LXC). LXC itself is a just an API for the Linux containment features.
Starting with Docker 0.9, LXC is not the default anymore and has been replaced with a custom library (libcontainer) written in Go. Overall libcontainer’s advantage is a more consistent interface to the Kernel across various Linux distributions. The only gotcha is that it requires Linux 3.8 and higher.