The article is very long. It is recommended to collect it and read it slowly! Crazy maker circle general catalog language bird version | General directory code cloud version| General directory blog Garden Edition We offer you valuable learning resources:
-
Free classic books: Java high concurrency core programming (Volume 1) Necessary for interview + necessary for large factory + necessary for salary increase Ganyon received it free of charge
-
Free classic books: Java high concurrency core programming (Volume 2) Necessary for interview + necessary for large factory + necessary for salary increase Ganyon received it free of charge
-
Free classic books: Netty Zookeeper Redis high concurrency practice Necessary for interview + necessary for large factory + necessary for salary increase Ganyon received it free of charge
-
Free classic books: SpringCloud Nginx high concurrency core programming Necessary for interview + necessary for large factory + necessary for salary increase Ganyon received it free of charge
-
Free resource treasure house: Java essential Baidu network disk resource collection, value > 10000 yuan Ganyon received
Recommendation: wonderful blog posts on joining big factories, building architectures and vigorously improving Java internal skills
Background:
In the next video version, from the perspective of architects, Nien will create the principle and practice of high availability and high concurrency middleware for everyone.
Objective: to thoroughly introduce the high availability and high concurrency environment that architects must master through video and blog, including but not limited to:
-
Principle and practice of high availability and high concurrency nginx architecture
-
Principle and practice of high availability and high concurrency mysql architecture
-
Principle and practice of high availability and high concurrency nacos architecture
-
Principle and practice of high availability and high concurrency rocketmq architecture
-
Principle and practice of high availability and high concurrency es architecture
-
Principle and practice of high availability and high concurrency minio architecture
why the principle and practice of high availability and high concurrency middleware:
- In the actual development process, many small partners often work hard and focus on crud development. If there is a problem in a more complex environment, they can't start it by themselves. If there is a problem, they are like ants on the hot pot.
- The common phenomenon is that people spend more time looking down at the road and less time looking up at the sky, and their technical vision is relatively narrow. They often work hard on business development and rarely invest in technology improvement.
- As an architect, if you want to move towards high-end development or architecture in the future, you must master the principle and operation of high availability and high concurrency middleware.
For details of this series of blogs, see Crazy maker circle general catalog language bird version | General directory code cloud version| General directory blog Garden Edition
Docker introduction
Docker is an open source application container engine based on Go language And open source in accordance with Apache 2.0 protocol.
Docker allows developers to package their applications and dependency packages into a lightweight and portable container, and then publish them to any popular Linux machine. It can also realize virtualization.
Containers completely use the sandbox mechanism, and there will be no interfaces between them (similar to iPhone app s). More importantly, the performance overhead of containers is very low.
After version 17.03, Docker is divided into CE (Community Edition) and EE (Enterprise Edition). We can use the Community Edition
Application scenario of Docker
- Automated packaging and publishing of Web applications.
- Automated testing and continuous integration and release.
- Deploy and adjust databases or other background applications in a service-oriented environment.
- Compile or extend the existing OpenShift or Cloud Foundry platform from scratch to build your own PaaS environment.
Docker architecture
Docker includes three basic concepts:
- Image: Docker image is equivalent to a root file system. For example, the official image ubuntu:16.04 contains a complete set of root file system of the smallest system of Ubuntu 16.04.
- Container: the relationship between an Image and a container is like a class and instance in object-oriented programming. An Image is a static definition and a container is an entity when the Image runs. A container can be created, started, stopped, deleted, suspended, etc.
- Repository: a repository can be regarded as a code control center for storing images.
Docker uses client server (C/S) architecture mode and remote API s to manage and create docker containers.
Docker containers are created through docker images.
| concept | explain |
|---|---|
| Docker images | Docker image is a template for creating docker container, such as Ubuntu system. |
| Docker container | A container is an application or group of applications that run independently. It is an entity that mirrors the runtime. |
| Docker client | The Docker client uses the Docker SDK through the command line or other tools( https://docs.Docker.com/develop/sdk/ )Communicate with Docker's daemon. |
| Docker host | A physical or virtual machine is used to execute Docker daemons and containers. |
| Docker Registry | Docker warehouse is used to save images, which can be understood as a code warehouse in code control. Docker Hub( https://hub.docker.com )Provides a large collection of images for use. A Docker Registry can contain multiple repositories; Each warehouse can contain multiple tags; Each label corresponds to a mirror image. Usually, a warehouse contains images of different versions of the same software, and labels are often used to correspond to each version of the software. We can specify which version of the software is mirrored through the format of < warehouse name >: < label >. If no label is given, latest will be used as the default label. |
View the daemon of docker
systemctl status docker
docker image view
docker image ls
docker container view
docker ps
Docker Registry configuration and viewing
cat /etc/docker/daemon.json
Configure private warehouse
cat>/etc/docker/daemon.json<<EOF
{
"registry-mirrors":["http://10.24.2.30:5000","https://tnxkcso1.mirrors.aliyuncs.com"],
"insecure-registries":["10.24.2.30:5000"]
}
EOF
Install docker Online
Offline installation of docker
1, Basic environment
1. Operating system: CentOS 7.3
2. Docker version: 19.03.9 official download address
3. Official reference documents: https://docs.docker.com/install/linux/docker-ce/binaries/#install-static-binaries
2, Docker installation
1. Download
wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz
Note: if you download it in advance, you can ignore this step
2. Decompress
Store the compressed file in the specified directory (such as root) and decompress it
tar -zxvf docker-19.03.9.tgz
cd root [root@localhost ~]# tar -zxvf docker-19.03.6.tgz docker/ docker/containerd docker/docker docker/ctr docker/dockerd docker/runc docker/docker-proxy docker/docker-init docker/containerd-shim
3. Move the contents of the extracted docker file to the / usr/bin / directory
cp docker/* /usr/bin/
4. Register docker as a service
cat /etc/systemd/system/docker.service
vi /etc/systemd/system/docker.service
[Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network-online.target firewalld.service Wants=network-online.target [Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/dockerd ExecReload=/bin/kill -s HUP $MAINPID # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE=infinity LimitNPROC=infinity LimitCORE=infinity # Uncomment TasksMax if your systemd version supports it. # Only systemd 226 and above support this version. #TasksMax=infinity TimeoutStartSec=0 # set delegate yes so that systemd does not reset the cgroups of docker containers Delegate=yes # kill only the docker process, not all processes in the cgroup KillMode=process # restart the docker process if it exits prematurely Restart=on-failure StartLimitBurst=3 StartLimitInterval=60s [Install] WantedBy=multi-user.target
5. Start
chmod +x /etc/systemd/system/docker.service # add file permissions and start docker
Systemctl daemon reload # reloads the unit configuration file
systemctl start docker # start Docker
systemctl enable docker.service # sets the automatic startup
[root@localhost ~]# vi /etc/systemd/system/docker.service [root@localhost ~]# chmod +x /etc/systemd/system/docker.service [root@localhost ~]# systemctl daemon-reload [root@localhost ~]# systemctl start docker [root@localhost ~]# systemctl enable docker.service Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /etc/systemd/system/docker.service.
6. Verify
systemctl status docker # view Docker status
docker -v # view docker version
docker info
[root@localhost ~]# systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-10-09 15:25:44 CST; 29s ago
Docs: https://docs.docker.com
Main PID: 1916 (dockerd)
CGroup: /system.slice/docker.service
├─1916 /usr/bin/dockerd
└─1927 containerd --config /var/run/docker/containerd/containerd.toml --log-level info
Oct 09 15:25:43 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:43.671407996+08:00" level=info msg="scheme \"unix\" not r...e=grpc
Oct 09 15:25:43 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:43.671440368+08:00" level=info msg="ccResolverWrapper: se...e=grpc
Oct 09 15:25:43 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:43.671462935+08:00" level=info msg="ClientConn switching ...e=grpc
Oct 09 15:25:43 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:43.750687781+08:00" level=info msg="Loading containers: start."
Oct 09 15:25:44 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:44.072960862+08:00" level=info msg="Default bridge (docke...dress"
Oct 09 15:25:44 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:44.153444071+08:00" level=info msg="Loading containers: done."
Oct 09 15:25:44 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:44.175249299+08:00" level=info msg="Docker daemon" commit...9.03.6
Oct 09 15:25:44 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:44.175337834+08:00" level=info msg="Daemon has completed ...ation"
Oct 09 15:25:44 localhost.localdomain systemd[1]: Started Docker Application Container Engine.
Oct 09 15:25:44 localhost.localdomain dockerd[1916]: time="2021-10-09T15:25:44.195084106+08:00" level=info msg="API listen on /var/ru....sock"
Hint: Some lines were ellipsized, use -l to show in full.
[root@localhost ~]# docker -v
Docker version 19.03.6, build 369ce74a3c
[root@localhost ~]# docker info
Using docker
Adjust mirror warehouse
Modify the registry of docker
Modify the daemon.json file in the / etc/docker directory
Add to file
{
"registry-mirrors": ["https://registry.docker-cn.com"]
}
Save exit
Restart docker
chmod +x /etc/systemd/system/docker.service # add file permissions and start docker
Systemctl daemon reload # reloads the unit configuration file
systemctl start docker # start Docker
systemctl restart docker # restart Docker
systemctl enable docker.service # sets the automatic startup
[root@localhost ~]# vi /etc/systemd/system/docker.service [root@localhost ~]# chmod +x /etc/systemd/system/docker.service [root@localhost ~]# systemctl daemon-reload [root@localhost ~]# systemctl start docker [root@localhost ~]# systemctl enable docker.service Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /etc/systemd/system/docker.service.
I found that the Intranet environment was changed to Alibaba cloud, but it was useless
[root@localhost ~]# cat /etc/docker/daemon.json
{
"registry-mirrors": ["https://ku39pxyp.mirror.aliyuncs.com"],
"insecure-registries": ["hub.company.com"]
}
Ensure that the image warehouse can be ping ed
[root@localhost ~]# curl https://ku39pxyp.mirror.aliyuncs.com curl: (6) Could not resolve host: ku39pxyp.mirror.aliyuncs.com; Unknown error [root@localhost ~]# ping ku39pxyp.mirror.aliyuncs.com ping: ku39pxyp.mirror.aliyuncs.com: Name or service not known
Overview of open source image warehouse Harbor
Habor By VMWare The company's open source container image warehouse. in fact, Habor Yes Docker Registry The corresponding analysis is carried out on These new enterprise features include: management user interface and role-based access Ask control, AD/LDAP Integration and audit logs are sufficient to meet basic enterprise needs. Official address: https://vmware.github.io/harbor/cn/
1. What is Harbor
• Harbor is an open source enterprise Docker Registry project of VMware. Its goal is to help users quickly build an enterprise Docker Registry service
• based on Docker's open source Registry, Harbor provides functions required by enterprise users such as graphical management UI, role-based access control, AD/LDAP integration, and audit logging. At the same time, it supports Chinese
• each component of Harbor is built in the form of Docker container, and Docker compose is used to deploy it. The docker-compose template for deploying Harbor is located at Harbor / docker-compose.yml
2. Characteristics of Harbor
1. Role based control: users and warehouses are organized based on projects, and users can have different permissions in projects
2. Image based replication strategy: images can be replicated (synchronized) between multiple Harbor instances
3. Support LDAP/AD: Harbor can integrate AD/LDAP (a - table similar to the database) within the enterprise to authenticate and manage existing users
4. Image deletion and garbage collection: images can be deleted or the space occupied by images can be recycled
5. Graphical user interface: users can browse through the browser, search the image warehouse and manage the project
6. Audit management: all operations on the mirror warehouse can be recorded and traced for audit management
7. Support RESTful API: RESTful API provides administrators with more control over Harbor, making it easier to integrate with other management software
8. Relationship between harbor and docker registry: Harbor essentially encapsulates docker registry and extends its own business template
3. Composition of Harbor
In terms of architecture, Harbor mainly includes six components: Proxy, Registry, Core services, database (Harbor dB), log collector (Harbor log) and Job services
● Proxy: Harbor's Registry, UI, Token service and other components are behind nginx reverse proxy. The agent forwards requests from browsers and docker clients to different back-end services
● Registry: responsible for storing Docker images and handling Docker push/pull commands. Due to the access control of users, that is, different users have different read and write permissions on the Docker image, Registry will point to a Token service, forcing users to carry a legal Token in each Docker pull/push request, and Registry will decrypt and verify the Token through the public key
● core services: the core function of harbor, which mainly provides the following three services:
1. UI (harbor UI): provides a graphical interface to help users manage images on Registry. And authorize users
2.WebHook: in order to obtain the status change of image on Registry. In time, configure webhook on Registry. And pass the status change to UI module
3.Token service: responsible for issuing tokens to each Docker push/pull command according to user permissions. The request initiated by the Docker client to the Registry service,
If the Token is not included, it will be redirected to the Token service. After obtaining the Token, it will make a request to the Registry again
● database (harbor dB): it provides database services for core services, and is responsible for storing data such as user permissions, audit logs, Docker image grouping information, etc
● Job services: mainly used for image replication. Local images can be synchronized to remote Harbor instances
● log collector (harbor log): responsible for collecting logs of other components to one place
• each component of Harbor is built in the form of Docker container. Therefore, Docker Compose is used to deploy it.
• it is run in seven containers in total. You can view it by executing the docker compose PS command in the directory where docker-compose.yml is located,
The names are nginx, harbor jobservice, harbor UI, harbor dB, harbor adminserver, registry, and harbor log
Among them, harbor admin server is mainly used as a back-end configuration data management, and does not have many other functions. All data to be operated by harbor UI is completed through a data configuration management center such as harbor adminserver.
Insecure mirror warehouse
[root@localhost ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.11.1.107 hub.company.com
I found that the Intranet environment was changed to Alibaba cloud, but it was useless
[root@localhost ~]# cat /etc/docker/daemon.json
{
"registry-mirrors": ["http://hub.company.co"],
"insecure-registries": ["hub.company.com"]
}
View the engine information of docker info
[root@localhost ~]# docker info Client: Debug Mode: false Server: Containers: 14 Running: 7 Paused: 0 Stopped: 7 Images: 19 Server Version: 19.03.6 Storage Driver: overlay2 Backing Filesystem: xfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339 runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657 init version: fec3683 Security Options: seccomp Profile: default Kernel Version: 3.10.0-1062.el7.x86_64 Operating System: CentOS Linux 7 (Core) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 15.49GiB Name: localhost.localdomain ID: I5KF:Y5JA:VCWG:DJYG:PGZO:PZVA:FYXQ:F624:RWH6:4S6R:BI6Z:L2MT Docker Root Dir: /var/lib/docker Debug Mode: false Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: hub.gsafety.com 127.0.0.0/8 Registry Mirrors: https://ku39pxyp.mirror.aliyuncs.com/ Live Restore Enabled: false
View docker related processes
[root@localhost ~]# ps -ef | grep docker root 1460 1 0 Jun23 ? 04:45:43 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock root 2249 1460 0 Jun23 ? 00:00:09 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 5433 -container-ip 172.26.0.2 -container-port 5432 root 2280 1460 0 Jun23 ? 00:00:09 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 5432 -container-ip 172.26.0.3 -container-port 5432 root 2310 1455 0 Jun23 ? 00:09:35 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/78dc6aacc7d9490fa7c7252dd6b4df01af3b68c2adb69767fb0d51974ea0728c -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 2311 1455 0 Jun23 ? 00:16:19 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/d6ec26035ca0428d5c3bd1cc154a76b356cf3a7d0746b0455d81223c7b9ab7fd -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 2483 1460 0 Jun23 ? 00:00:32 /usr/bin/docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 1514 -container-ip 172.21.0.4 -container-port 10514 root 2538 1455 0 Jun23 ? 02:25:41 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/98500167fb283c56fd43f42d3357c52b393481fdcca2bc7a87128ac35e19fa5a -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 2571 1455 0 Jun23 ? 02:17:17 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/412652067b159ca617625c315940ce6865534e80fa94b93ef3174f653d21b826 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 7077 1460 0 Jun23 ? 00:00:09 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3306 -container-ip 172.19.0.2 -container-port 3306 root 7085 1455 0 Jun23 ? 00:09:39 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/976bb8cd43729535a74d1583a758be937b6cf8f7a3329a1737fcb722576d1fea -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 7354 1460 0 Jun23 ? 00:00:09 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3308 -container-ip 172.19.0.3 -container-port 3306 root 7386 1455 0 Jun23 ? 00:09:45 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/14112371b62521a9b52968a6b0d275700343afeceaac478cfb7a90241dfcdf61 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 7402 1460 0 Jun23 ? 00:00:09 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3307 -container-ip 172.19.0.4 -container-port 3306 root 7431 1455 0 Jun23 ? 00:10:30 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/a0c6a5d5f891d293ae19e0bc3413729ac41cf38cc7e58d5a547b0f0df87fd6c4 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 28336 21582 0 15:32 pts/0 00:00:00 grep --color=auto docker
Docker local image loading and unloading
Two approaches
- Save image (the image with the same id as the original image is obtained after the image is loaded)
- Save container (after the save container is loaded, an image different from the original image id is obtained)
Pull image
You can pull images from the image warehouse through the command. By default, you can pull images from the image warehouse Docker Hub obtain.
Command format:
docker image pull :
docker image pull rancher/rke-tools:v0.1.52
[rancher/rke-tools:v0.1.52
Save image
- docker save image id -o /home/mysql.tar
- docker save image ID > / home / mysql.tar
docker save docker.io/rancher/rancher-agent -o /home/rancher-agent .tar
docker save f29ece87a195 -o /home/rancher-agent.tar
docker save docker.io/rancher/rke-tools -o /home/rke-tools-v0.1.52.tar
Load image
- docker load -i mysql.tar
docker load -i /usr/local/rancher-v2.3.5.tar
docker load -i /usr/local/rancher-agent.tar
docker inspect f29ece87a1954772accb8a2332ee8c3fe460697e3f102ffbdc76eb9bc4f4f1d0
docker load -i /usr/local/rke-tools-v0.1.52.tar
docker load -i mysql.tar [root@localhost ~]# docker load -i /usr/local/rancher-v2.3.5.tar 43c67172d1d1: Loading layer [==================================================>] 65.57MB/65.57MB 21ec61b65b20: Loading layer [==================================================>] 991.2kB/991.2kB 1d0dfb259f6a: Loading layer [==================================================>] 15.87kB/15.87kB f55aa0bd26b8: Loading layer [==================================================>] 3.072kB/3.072kB e0af200d6950: Loading layer [==================================================>] 126.1MB/126.1MB 088ed892f9ad: Loading layer [==================================================>] 6.656kB/6.656kB 6aa3142b4130: Loading layer [==================================================>] 34.5MB/34.5MB f4e84c05ab29: Loading layer [==================================================>] 70.41MB/70.41MB 11a6e4332b53: Loading layer [==================================================>] 224.8MB/224.8MB 46d1ac556da7: Loading layer [==================================================>] 3.072kB/3.072kB 0f8b224a5802: Loading layer [==================================================>] 57.87MB/57.87MB 519eba7d586a: Loading layer [==================================================>] 99.58MB/99.58MB 3f8bb7c0c150: Loading layer [==================================================>] 4.608kB/4.608kB c22c9a5a8211: Loading layer [==================================================>] 3.072kB/3.072kB Loaded image: rancher/rancher:v2.3.5
Make a tag
docker tag f29ece87a1954772accb8a2332ee8c3fe460697e3f102ffbdc76eb9bc4f4f1d0 rancher/rancher-agent:v2.3.5
docker tag f29ece87a195 172.18.8.104/rancher/rancher-agent:v2.3.5
docker tag 6e421b8753a2 172.18.8.104/rancher/rke-tools:v0.1.52
83fe4871cf67
docker rmi image_name
docker rmi -f 172.18.8.104/rancher/coredns-coredns:1.6.5
docker rmi -f 172.18.8.104/rancher/coredns-coredns:v3.4.3-rancher1
docker rmi hub.doge.net/ubuntu:latest
Save image
- docker export image id -o /home/mysql-export.tar
- docker save image tag -o /home/mysql-export.tar
Load image
- docker import mysql-export.tar
Docker local container related operations
Create container
Create a container named "centos6" and view the process information in the container inside the container and in the host
docker run -itd -p 6080:80 -p 6022:22 docker.io/lemonbar/centos6-ssh:latest
give the result as follows
[root@VM-4-17-centos ~]# docker run -itd -p 80:80 -p 6022:22 docker.io/lemonbar/centos6-ssh:latest Unable to find image 'lemonbar/centos6-ssh:latest' locally latest: Pulling from lemonbar/centos6-ssh a3ed95caeb02: Pull complete f79eb1f22352: Pull complete 67c1aaa530c8: Pull complete 80447774eee7: Pull complete 6d67b3a80e5a: Pull complete f1819e4b2f8f: Pull complete 09712b5b9acc: Pull complete 8bc987c5494f: Pull complete c42b021d0ff2: Pull complete Digest: sha256:093c2165b3c6fe05d5658343456f9b59bb7ecc690a7d3a112641c86083227dd1 Status: Downloaded newer image for lemonbar/centos6-ssh:latest a4f1c9b8abcda78c8764cc285183dfa56cd1aa4ce6d111d4d9e77f3a57f3d5fc
View active containers
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a4f1c9b8abcd lemonbar/centos6-ssh:latest "/bin/sh -c '/usr/sb..." 32 seconds ago Up 31 seconds 0.0.0.0:6022->22/tcp, 0.0.0.0:6080->80/tcp determined_curie
View all containers
docker ps -a
Stop container
docker stop id
Delete container
docker rm id
View the process information of the container
**docker top 😗* View the process information running in the container and support ps command parameters.
grammar
docker top [OPTIONS] CONTAINER [ps OPTIONS]
The container does not necessarily have a / bin/bash terminal to execute the top command interactively when running, and the container does not necessarily have a top command. You can use docker top to view the running processes in the container.
from Docker 1.11 At first, the Docker container is not simply started through the Docker daemon, but integrates containerd, runC and other components. After the Docker service is started, we can also see that dockerd, Docker containerd and other processes are started on the system. This paper mainly introduces the functions and functions of each part of the new Docker (after 1.11).
Find container name command
[root@localhost ~]# docker ps --format "{{.Names}}"
The results are as follows:
[root@VM-4-17-centos ~]# docker ps --format "{{.Names}}"
determined_curie
redis
nginx_slave
nginx_master
nginx_empty
loving_agnesi
pxc_proxy
pxc03
pxc02
pxc01
affectionate_austin
nostalgic_blackwell
View the process information in the container inside the container and in the host
docker exec -it determined_curie ps -ef
The results are as follows:
[root@VM-4-17-centos ~]# docker exec -it determined_curie ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:14 pts/0 00:00:00 /usr/sbin/sshd -D root 5 0 0 08:16 pts/1 00:00:00 ps -ef
We can use the docker exec command to enter the container PID namespace and execute the application.
Through the ps -ef command, you can see each determined_ Every Curie container contains a process with PID 1, "/ usr/sbin/sshd", which is the starting process of the container and has special significance.
Using the docker top command, we can see the process information of the container from the host operating system.
[root@VM-4-17-centos ~]# docker top determined_curie UID PID PPID C STIME TTY TIME CMD root 27880 27866 0 16:14 pts/0 00:00:00 /usr/sbin/sshd -D [root@VM-4-17-centos ~]#
View its parent process information
root 17205 1414 0 16:37 pts/0 00:00:00 grep --color=auto 27866 root 27866 5587 0 16:14 ? 00:00:00 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/a4f1c9b8abcda78c8764cc285183dfa56cd1aa4ce6d111d4d9e77f3a57f3d5fc -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc root 27880 27866 0 16:14 pts/0 00:00:00 /usr/sbin/sshd -D
View child process information
[root@VM-4-17-centos ~]# ps aux | grep 27880 root 17777 0.0 0.0 115928 1008 pts/0 S+ 16:38 0:00 grep --color=auto 27880 root 27880 0.0 0.0 66664 3072 pts/0 Ss+ 16:14 0:00 /usr/sbin/sshd -D
Three commands in total
ps -ef | grep 4948 #View parent process ps aux | grep 27880 #View child processes (containers) docker ps -a | grep determined_curie #Locate container id
Start another centos container
docker run -itd --name centos6-2 -p 6081:80 -p 6021:22 docker.io/lemonbar/centos6-ssh:latest
The output is as follows:
[root@VM-4-17-centos ~]# docker run -itd --name centos6-2 -p 6081:80 -p 6021:22 docker.io/lemonbar/centos6-ssh:latest 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd
View process information
Using the docker top command, we can see the process information of the container from the host operating system.
[root@VM-4-17-centos ~]# docker top centos6-2 UID PID PPID C STIME TTY TIME CMD root 4962 4948 0 16:24 pts/0 00:00:00 /usr/sbin/sshd -D
View its parent process information
[root@VM-4-17-centos ~]# ps -ef | grep 4948 root 4948 5587 0 16:24 ? 00:00:00 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc root 4962 4948 0 16:24 pts/0 00:00:00 /usr/sbin/sshd -D
View child process information
[root@VM-4-17-centos ~]# ps aux | grep 4962 root 4962 0.0 0.0 66664 3068 pts/0 Ss+ 16:24 0:00 /usr/sbin/sshd -D root 15311 0.0 0.0 115932 1008 pts/0 S+ 16:35 0:00 grep --color=auto 4962
Three commands in total
ps -ef | grep 4948 #View parent process ps aux | grep 4962 #View child processes (containers) docker ps -a | grep centos6-2 #Locate container id
Correspondence between processes
Linux views the file path through the process ID
File path of child process
[root@VM-4-17-centos ~]# ls -l /proc/27880 total 0 dr-xr-xr-x 2 root root 0 Nov 3 16:41 attr -rw-r--r-- 1 root root 0 Nov 3 16:41 autogroup -r-------- 1 root root 0 Nov 3 16:41 auxv -r--r--r-- 1 root root 0 Nov 3 16:14 cgroup --w------- 1 root root 0 Nov 3 16:41 clear_refs -r--r--r-- 1 root root 0 Nov 3 16:15 cmdline -rw-r--r-- 1 root root 0 Nov 3 16:41 comm -rw-r--r-- 1 root root 0 Nov 3 16:41 coredump_filter -r--r--r-- 1 root root 0 Nov 3 16:41 cpuset lrwxrwxrwx 1 root root 0 Nov 3 16:41 cwd -> / -r-------- 1 root root 0 Nov 3 16:41 environ lrwxrwxrwx 1 root root 0 Nov 3 16:14 exe -> /usr/sbin/sshd dr-x------ 2 root root 0 Nov 3 16:14 fd dr-x------ 2 root root 0 Nov 3 16:41 fdinfo -rw-r--r-- 1 root root 0 Nov 3 16:41 gid_map -r-------- 1 root root 0 Nov 3 16:41 io -r--r--r-- 1 root root 0 Nov 3 16:41 limits -rw-r--r-- 1 root root 0 Nov 3 16:41 loginuid dr-x------ 2 root root 0 Nov 3 16:41 map_files -r--r--r-- 1 root root 0 Nov 3 16:41 maps -rw------- 1 root root 0 Nov 3 16:41 mem -r--r--r-- 1 root root 0 Nov 3 16:14 mountinfo -r--r--r-- 1 root root 0 Nov 3 16:41 mounts -r-------- 1 root root 0 Nov 3 16:41 mountstats dr-xr-xr-x 5 root root 0 Nov 3 16:41 net dr-x--x--x 2 root root 0 Nov 3 16:14 ns -r--r--r-- 1 root root 0 Nov 3 16:41 numa_maps -rw-r--r-- 1 root root 0 Nov 3 16:41 oom_adj -r--r--r-- 1 root root 0 Nov 3 16:41 oom_score -rw-r--r-- 1 root root 0 Nov 3 16:41 oom_score_adj -r--r--r-- 1 root root 0 Nov 3 16:41 pagemap -r-------- 1 root root 0 Nov 3 16:41 patch_state -r--r--r-- 1 root root 0 Nov 3 16:41 personality -rw-r--r-- 1 root root 0 Nov 3 16:41 projid_map lrwxrwxrwx 1 root root 0 Nov 3 16:41 root -> / -rw-r--r-- 1 root root 0 Nov 3 16:41 sched -r--r--r-- 1 root root 0 Nov 3 16:41 schedstat -r--r--r-- 1 root root 0 Nov 3 16:41 sessionid -rw-r--r-- 1 root root 0 Nov 3 16:41 setgroups -r--r--r-- 1 root root 0 Nov 3 16:41 smaps -r--r--r-- 1 root root 0 Nov 3 16:41 stack -r--r--r-- 1 root root 0 Nov 3 16:14 stat -r--r--r-- 1 root root 0 Nov 3 16:41 statm -r--r--r-- 1 root root 0 Nov 3 16:14 status -r--r--r-- 1 root root 0 Nov 3 16:41 syscall dr-xr-xr-x 3 root root 0 Nov 3 16:41 task -r--r--r-- 1 root root 0 Nov 3 16:41 timers -rw-r--r-- 1 root root 0 Nov 3 16:14 uid_map -r--r--r-- 1 root root 0 Nov 3 16:41 wchan
The following is a description of the process 27880 in the / proc Directory:
proc/27880 pid by N Process information for /proc/27880/cmdline Process start command /proc/27880/cwd Link to the current working directory of the process /proc/27880/environ Process environment variable list /proc/27880/exe Execute command file linked to the process /proc/27880/fd Contains all process related file descriptors /proc/27880/maps Memory mapping information related to the process /proc/27880/mem Refers to the memory held by the process, which is unreadable /proc/27880/root Link to the root directory of the process /proc/27880/stat Status of the process /proc/27880/statm The state of memory used by the process /proc/27880/status Process status information, ratio stat/statm More readable
PID namespace (namespace) of the container
In Docker, the process management is based on the PID name in the Linux kernel.
In different PID namespaces, the process ID is independent; That is, processes in two spaces with different names can have the same PID.
In docker, each Container process has a different PID namespace by default. Docker implements process isolation between containers by name space technology.
The container process running in docker is essentially running on the host, so it will also have the corresponding PID
Find the container ID
# docker ps
output
[root@VM-4-17-centos ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 460d68823930 lemonbar/centos6-ssh:latest "/bin/sh -c '/usr/sb..." 32 minutes ago Up 32 minutes 0.0.0.0:6021->22/tcp, 0.0.0.0:6081->80/tcp centos6-2
View container information
docker inspect id
output
[root@VM-4-17-centos ~]# docker inspect 460d68823930
[root@VM-4-17-centos ~]# docker inspect 460d68823930
[
{
"Id": "460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd",
"Created": "2021-11-03T08:24:36.934129599Z",
"Path": "/bin/sh",
"Args": [
"-c",
"/usr/sbin/sshd -D"
],
"State": {
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 4962,
"ExitCode": 0,
"Error": "",
"StartedAt": "2021-11-03T08:24:37.223255812Z",
"FinishedAt": "0001-01-01T00:00:00Z"
},
"Image": "sha256:efd998bd6817af509d348b488e3ce4259f9f05632644a7bf574b785bbc8950b8",
"ResolvConfPath": "/var/lib/docker/containers/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/resolv.conf",
"HostnamePath": "/var/lib/docker/containers/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/hostname",
"HostsPath": "/var/lib/docker/containers/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/hosts",
"LogPath": "/var/lib/docker/containers/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd-json.log",
"Name": "/centos6-2",
"RestartCount": 0,
"Driver": "overlay2",
"Platform": "linux",
"MountLabel": "",
"ProcessLabel": "",
"AppArmorProfile": "",
"ExecIDs": null,
"HostConfig": {
"Binds": null,
"ContainerIDFile": "",
"LogConfig": {
"Type": "json-file",
"Config": {}
},
"NetworkMode": "default",
"PortBindings": {
"22/tcp": [
{
"HostIp": "",
"HostPort": "6021"
}
],
"80/tcp": [
{
"HostIp": "",
"HostPort": "6081"
}
]
},
"RestartPolicy": {
"Name": "no",
"MaximumRetryCount": 0
},
"AutoRemove": false,
"VolumeDriver": "",
"VolumesFrom": null,
"CapAdd": null,
"CapDrop": null,
"Dns": [],
"DnsOptions": [],
"DnsSearch": [],
"ExtraHosts": null,
"GroupAdd": null,
"IpcMode": "shareable",
"Cgroup": "",
"Links": null,
"OomScoreAdj": 0,
"PidMode": "",
"Privileged": false,
"PublishAllPorts": false,
"ReadonlyRootfs": false,
"SecurityOpt": null,
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 0,
"Memory": 0,
"NanoCpus": 0,
"CgroupParent": "",
"BlkioWeight": 0,
"BlkioWeightDevice": [],
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 0,
"CpuQuota": 0,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": [],
"DeviceCgroupRules": null,
"DiskQuota": 0,
"KernelMemory": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"MemorySwappiness": null,
"OomKillDisable": false,
"PidsLimit": 0,
"Ulimits": null,
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0
},
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/6835c1b48237aafe27e2efabeda92a3a6623f254f88d54b5e6acce454e560dd6-init/diff:/var/lib/docker/overlay2/7139bf0b716c6e0b6a0c709b7043466f9bbfd7024f8ae584061c00b0bd97348c/diff:/var/lib/docker/overlay2/66a3e278259cdcf50741ce30a115baa3bd6247a60c487e4118e85f2f39328f11/diff:/var/lib/docker/overlay2/20e22c4c28ebadb615eb4c7c290253d3eb91cb49722ee2931b0ee628352a5857/diff:/var/lib/docker/overlay2/a3fa9dbebc83a853083205b8f7921c632cd67f64531f4a25cab419a43172e3ae/diff:/var/lib/docker/overlay2/3af7958c9a4e54d24598058a9fa1e85eb35e3d40f766fa498a674b52724ae73e/diff:/var/lib/docker/overlay2/becb65af4396137ed41fe6d516e834e6e6e9120f4edfac8e2ca8dd67cce23268/diff:/var/lib/docker/overlay2/fef055305158cc96906514c447f0eaea05945138896b0b35ac4146b6a2a3e273/diff:/var/lib/docker/overlay2/79158cdf3ba832493ab0d02d560c784208fe51c74236a5a86f7fb4fb50ab6e44/diff:/var/lib/docker/overlay2/86258a18e1110582b819719593687f11f0404d00a41667b3432c3b974fb1ce42/diff:/var/lib/docker/overlay2/8826b2e0068653fb2c5e8a3dbf839470e2b8eef8cf752b5fe901bea1b210849f/diff:/var/lib/docker/overlay2/145301e2738a8a7581c2bbd5beb9bf7a49b247e46642b8084efbc026a1826116/diff:/var/lib/docker/overlay2/f621f37535e0db1fe44902e22dba7ef0844b9a8b562a9daa39a842a49e9cc9bb/diff:/var/lib/docker/overlay2/7b493e4a97907aaa18b97ad2e9120b5bf87c0e9908ee390a35ea6ff546d8cec6/diff",
"MergedDir": "/var/lib/docker/overlay2/6835c1b48237aafe27e2efabeda92a3a6623f254f88d54b5e6acce454e560dd6/merged",
"UpperDir": "/var/lib/docker/overlay2/6835c1b48237aafe27e2efabeda92a3a6623f254f88d54b5e6acce454e560dd6/diff",
"WorkDir": "/var/lib/docker/overlay2/6835c1b48237aafe27e2efabeda92a3a6623f254f88d54b5e6acce454e560dd6/work"
},
"Name": "overlay2"
},
"Mounts": [],
"Config": {
"Hostname": "460d68823930",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"22/tcp": {},
"80/tcp": {}
},
"Tty": true,
"OpenStdin": true,
"StdinOnce": false,
"Env": [
"HOME=/",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh",
"-c",
"/usr/sbin/sshd -D"
],
"Image": "docker.io/lemonbar/centos6-ssh:latest",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": {}
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "ea66261fb6d8089d5b2d585a2dc32b2003365df7118f5f5e898a152fb5b35773",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"22/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "6021"
}
],
"80/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "6081"
}
]
},
"SandboxKey": "/var/run/docker/netns/ea66261fb6d8",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "09ad719a4e9115ee56c5fb0f5b0d39c50bf5acaf0a1afacedc13969c82a2969f",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.6",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "02:42:ac:11:00:06",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"NetworkID": "2586283d16a08210c955d705f05e0f6999b59523a84b0c163e33f535af809ddd",
"EndpointID": "09ad719a4e9115ee56c5fb0f5b0d39c50bf5acaf0a1afacedc13969c82a2969f",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.6",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:11:00:06",
"DriverOpts": null
}
}
}
}
]
Enter the corresponding directory
# cd /sys/fs/cgroup/memory/docker/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/
output
cd /sys/fs/cgroup/memory/docker/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd/ [root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# ll total 0 -rw-r--r-- 1 root root 0 Nov 3 16:24 cgroup.clone_children --w--w--w- 1 root root 0 Nov 3 16:24 cgroup.event_control -rw-r--r-- 1 root root 0 Nov 3 16:24 cgroup.procs -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.failcnt --w------- 1 root root 0 Nov 3 16:24 memory.force_empty -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.failcnt -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.limit_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.max_usage_in_bytes -r--r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.slabinfo -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.tcp.failcnt -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.tcp.limit_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.tcp.max_usage_in_bytes -r--r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.tcp.usage_in_bytes -r--r--r-- 1 root root 0 Nov 3 16:24 memory.kmem.usage_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.limit_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.max_usage_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.memsw.failcnt -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.memsw.limit_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.memsw.max_usage_in_bytes -r--r--r-- 1 root root 0 Nov 3 16:24 memory.memsw.usage_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.move_charge_at_immigrate -r--r--r-- 1 root root 0 Nov 3 16:24 memory.numa_stat -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.oom_control ---------- 1 root root 0 Nov 3 16:24 memory.pressure_level -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.soft_limit_in_bytes -r--r--r-- 1 root root 0 Nov 3 16:24 memory.stat -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.swappiness -r--r--r-- 1 root root 0 Nov 3 16:24 memory.usage_in_bytes -rw-r--r-- 1 root root 0 Nov 3 16:24 memory.use_hierarchy -rw-r--r-- 1 root root 0 Nov 3 16:24 notify_on_release -rw-r--r-- 1 root root 0 Nov 3 16:24 tasks
[root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat cgroup.procs 4962 11539 [root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat pids.max max [root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat tasks 4962 11539 [root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat cgroup.clone_children 0 [root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# pwd /sys/fs/cgroup/pids/docker/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd
View the process number in the container directory
The process number is stored in a file
[root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat cgroup.procs 4962
As before, using the docker top command allows us to see the process information of the container from the host operating system.
[root@VM-4-17-centos ~]# docker top centos6-2 UID PID PPID C STIME TTY TIME CMD root 4962 4948 0 16:24 pts/0 00:00:00 /usr/sbin/sshd -D
Start a process
Next, we will start a "sleep" process with the docker exec command in the CentOS 6-2 container
[root@VM-4-17-centos ]# docker exec -d centos6-2 sleep 2000 [root@VM-4-17-centos ]# docker exec centos6-2 ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:24 pts/0 00:00:00 /usr/sbin/sshd -D root 6 0 0 09:06 ? 00:00:00 sleep 2000 root 10 0 0 09:06 ? 00:00:00 ps -ef
View the process number of the host
[root@VM-4-17-centos ]# docker top centos6-2 UID PID PPID C STIME TTY TIME CMD root 4962 4948 0 16:24 pts/0 00:00:00 /usr/sbin/sshd -D root 11539 4948 0 17:06 ? 00:00:00 sleep 2000
We can clearly see that the sleep process created by the exec command belongs to the namespace of CentOS 6-2 container, but its parent process is the startup process of Docker container.
View the process number in the container directory
The process number is stored in a file
[root@VM-4-17-centos 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd]# cat cgroup.procs 4962 11539
docker exec -d centos6-2 pstree -p docker exec -d centos6-2 ps -auxf docker exec -d centos6-2 ll /proc
output
[root@VM-4-17-centos docker]# docker exec centos6-2 ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:24 pts/0 00:00:00 /usr/sbin/sshd -D root 6 0 0 09:06 ? 00:00:00 sleep 2000 root 40 0 0 09:26 ? 00:00:00 ps -ef [root@VM-4-17-centos docker]# docker exec centos6-2 ps -auxf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 44 0.0 0.0 13360 1012 ? Rs 09:26 0:00 ps -auxf root 6 0.0 0.0 4120 316 ? Ss 09:06 0:00 sleep 2000 root 1 0.0 0.0 66664 3068 pts/0 Ss+ 08:24 0:00 /usr/sbin/sshd -D Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ [root@VM-4-17-centos docker]# docker exec centos6-2 pstree -p sshd(1)
Docker file directory and container internal operations
The default file directory of Docker is located under / var/lib/docker of Linux server. The directory structure is as follows
|-----containers: used to store container information
|-----Image: used to store the image middleware and its own information, size and dependency information
|-----network
|-----swarm
|-----tmp: docker temporary directory
|-----Trust: docker trust directory
|-----volumes: docker volume directory
You can also confirm the file location through the docker command:
docker info
To view the file directory of a container:
docker exec container name ls
docker exec centos6-2 ls /proc
[root@VM-4-17-centos containers]# docker exec centos6-2 ls /proc 1 103 acpi buddyinfo bus cgroups cmdline consoles cpuinfo crypto devices diskstats dma driver execdomains fb filesystems fs interrupts iomem ioports irq kallsyms kcore key-users keys kmsg kpagecount kpageflags loadavg locks mdstat meminfo misc modules mounts mtrr net pagetypeinfo partitions sched_debug schedstat scsi self slabinfo softirqs stat swaps sys sysrq-trigger sysvipc timer_list timer_stats tty uptime version vmallocinfo vmstat zoneinfo
Docker daemon
pidof dockerd #View docker daemon pid lsof -p 3197 | wc -l #The number of files opened by the docker daemon
"centos" in the two containers are two independent processes, but they have the same parent process Docker Daemon.
Therefore, Docker can interact between Docker Daemon and Redis container in the way of parent-child process.
Another noteworthy aspect is that the docker exec command can enter the specified container to execute commands. The process started by it belongs to the container's namespace and the corresponding cgroup.
However, the parent process of these processes is Docker Daemon, not the PID1 process of the container.
Next, we will start a "sleep" process in the Redis container with the docker exec command
docker@default:~$ docker exec -d redis sleep 2000 docker@default:~$ docker exec redis ps -ef UID PID PPID C STIME TTY TIME CMD redis 1 0 0 02:26 ? 00:00:00 redis-server *:6379 root 11 0 0 02:26 ? 00:00:00 sleep 2000 root 21 0 0 02:29 ? 00:00:00 ps -ef docker@default:~$ docker top redis UID PID PPID C STIME TTY TIME CMD 999 9955 1264 0 02:12 ? 00:00:00 redis-server *:6379 root 9984 1264 0 02:13 ? 00:00:00 sleep 2000
We can clearly see that the sleep process created by the exec command belongs to the Redis container namespace, but its parent process is Docker Daemon.
If we manually kill the container's startup process (redis server in the above example) in the host operating system, the container will automatically end and all processes in the container namespace will exit.
docker@default:~$ PID=$(docker inspect --format="{{.State.Pid}}" redis)
docker@default:~$ sudo kill $PID
docker@default:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
356eca186321 redis "/entrypoint.sh redis" 23 minutes ago Up 4 minutes 6379/tcp redis2
f6bc57cc1b46 redis "/entrypoint.sh redis" 23 minutes ago Exited (0) 4 seconds ago redis
Through the above example:
- Each container has a separate PID namespace,
- The life cycle of the container is consistent with its PID1 process
- Using docker exec, you can enter the namespace of the container and start the process
Docker Daemon principle
As a daemon for docker container management, Docker Daemon has been integrated into docker commands (before version 1.11) and later independent into separate binary programs (since version 1.11). Its functions are gradually split and refined and allocated to individual modules.
Evolution: Docker Daemon Start
From the startup script of Docker service, you can also see the gradual stripping of the daemon:
Before Docker 1.8, the commands started by the Docker daemon are:
docker -d
At this stage, the daemon appears to be just an option for the Docker client.
From Docker 1.8, the startup command becomes:
docker daemon
At this stage, the daemon appears to be a module of the docker command.
Starting from Docker 1.11, the daemon startup command becomes:
dockerd
The service configuration file is:
[Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/dockerd ExecReload=/bin/kill -s HUP $MAINPID
At this time, it is separated from Docker client and becomes a binary program.
Of course, the daemon module is constantly refactoring, and its basic functions and positioning have not changed. Like the general CS architecture system, the daemon is responsible for interacting with Docker client s and managing Docker images and containers.
OCI(Open Container Initiative)
The Open Container Initiative, also known as OCI, is a project jointly established by several companies and managed by the linux foundation. It is committed to the formulation of container runtime standards and the development of runc.
The official introduction is
An open governance structure for the express purpose of creating open industry standards around container formats and runtime. – Open Containers Official Site
The so-called container runtime is mainly responsible for the management of container life cycle. The runtime spec standard of oci defines the status description of containers and the operations of creating, deleting and viewing containers.
At present, there are mainly two standard documents: container runtime standard (runtime spec) and container image standard (image spec).
The two protocols are connected through the standard format of OCI runtime filesytem bundle. The OCI image can be converted into a bundle through tools, and then the OCI container engine can recognize the bundle to run the container.
image spec
OCI container image mainly includes several pieces of content:
File system: the file system saved in layers. Each layer saves the part that changes with the upper layer, which files should be saved in the layer, and how to represent the added, modified and deleted files
config file: it saves the hierarchy information of the file system (hash value and historical information of each hierarchy), as well as some information required by the container during operation (such as environment variables, working directory, command parameters and mount list), and specifies the configuration of the image on a specific platform and system. Closer, we use docker inspect < image_ ID > what you see
Manifest file: the index of the mirrored config file, which layer s are there, and additional annotation information. The manifest file stores a lot of information related to the current platform
Index file: an optional file that points to the manifest files of different platforms. This file can ensure that an image can be used across platforms. Each platform has different manifest files and uses index as the index
runtime spec
OCI's standard for container runtime is mainly to specify the running state of the container and the commands to be provided by runtime. The following figure can be a container state transition diagram:
Docker CLI
/usr/bin/docker
Docker's client tools communicate with dockerd API through cli. Examples of CLI include docker build... docker run
Docker Daemon
/usr/bin/dockerd
Of course, the daemon module is constantly refactoring, and its basic functions and positioning have not changed. Like the general CS architecture system, the daemon is responsible for interacting with Docker client s and managing Docker images and containers.
Containerd
/usr/bin/docker-containerd
Containerd is the product of container technology standardization. In order to be compatible with OCI standards, the container runtime and its management functions are stripped from Docker Daemon. In theory, containers can be managed directly through containerd even if dockerd is not running. (of course, containerd itself is just a daemon, and the actual running time of the container is controlled by runC described later.)
Recently, Docker just announced open source containerd. It can be seen from the project introduction page that containerd is mainly responsible for image management (image, meta information, etc.) and container execution (calling the final runtime component for execution).
Containerd provides a gRPC interface for Docker Daemon upward, so that Docker Daemon can shield the following structural changes and ensure the downward compatibility of the original interface. Downward through containerd shim and runC, the engine can be upgraded independently to avoid the unavailability of all containers caused by the previous Docker Daemon upgrade.
containerd fully leverages the OCI runtime specification1, image format specifications and OCI reference implementation (runc).
containerd includes a daemon exposing gRPC API over a local UNIX socket. The API is a low-level one designed for higher layers to wrap and extend. Containerd uses RunC to run containers according to the OCI specification.
docker-shim
/usr/bin/docker-containerd-shim
Every time a container is started, a new docker-shim process will be started
He directly creates a container by specifying three parameters:
- Container id
- Boundary directory (containerd corresponds to the directory generated by a container, usually located in: / var/run/docker/libcontainerd/containerID)
- The runtime is binary (the default is runc) to call the runc api (for example, when creating a container, the last assembled command is as follows: runc create...)
His role is:
- It allows the container runtime (i.e. runC) to exit after starting the container, which simply means that you don't have to run a container runtime (runC) for each container all the time
- Even if containerd and dockerd are hung, the container's standard IO and other file descriptors are available
- Report the exit status of the container to containerd
The first two points are especially important, with which you can upgrade or restart dockerd without interrupting the operation of the container (which is of great significance for the production environment).
runc (OCI reference implementation)
/usr/bin/docker-runc
OCI defines the container runtime standard OCI Runtime Spec support (aka runC), which is a specific implementation of Docker according to the open container format standard (OCF).
runC is migrated from the libcontainer of Docker and implements the functions of container startup and shutdown and resource isolation.
Docker provides a docker runc implementation by default. In fact, through the encapsulation of containerd, the implementation of runc can be specified when Docker Daemon is started.
We can select other runC options by adding the – add runtime parameter when starting Docker Daemon. For example:
docker daemon --add-runtime "custom=/usr/local/bin/my-runc-replacement"
Relationship among Docker, containerd, containerd shim and runc
The relationship between them is shown in the figure below:
We can start a Docker container to observe the association between processes.
Start a container process through docker and runc
View process information
Using the docker top command, we can see the process information of the container from the host operating system.
[root@VM-4-17-centos ~]# docker top centos6-2 UID PID PPID C STIME TTY TIME CMD root 4962 4948 0 16:24 pts/0 00:00:00 /usr/sbin/sshd -D
View child process information
[root@VM-4-17-centos containerd]# ps aux | grep 4948 root 4948 0.0 0.0 12212 3696 ? Sl 16:24 0:00 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc root 27040 0.0 0.0 115932 1004 pts/0 S+ 18:32 0:00 grep --color=auto 4948
View process tree
pstree -l -a -A 4948 -p
The output results are as follows:
[root@VM-4-17-centos containerd]# pstree -l -a -A 4948 -p
docker-containe,4948 -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc
|-sshd,4962 -D
|-{docker-containe},4949
|-{docker-containe},4950
|-{docker-containe},4951
|-{docker-containe},4952
|-{docker-containe},4953
|-{docker-containe},4954
`-{docker-containe},1593
Although the pstree command truncates the command, we can still see that the docked and docker container processes always exist after the Docker daemon is started.
After the container is started, the docker containerd process (also the containerd component described here) will create the docker containerd shim process. The parameter 460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd is the id of the container to be started.
Finally, the docker containerd shim sub process is already the process actually running in the container (i.e. sleep 1000).
Another parameter of docker containerd shim is a container related directory / var/run/docker/containerd/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd, which contains:
[root@VM-4-17-centos containerd]# ll /var/run/docker/containerd/460d688239304172f39bb9586bfc5959e0c3db64e7c3a0937f1003f94408ebbd total 0 prwx------ 1 root root 0 Nov 3 16:24 init-stdin prwx------ 1 root root 0 Nov 3 16:24 init-stdout
It includes three pipeline files: container configuration, standard input, standard output and standard error.
docker-shim
Docker shim is a real gasket carrier of a real running container. Each container starts a new docker shim process,
It directly specifies three parameters: container id and boundary directory (the directory generated by a container corresponding to containerd, which is generally located in: / var/run/docker/libcontainerd/containerID),
The runtime is binary (the default is runc) to call the runc api to create a container (for example, create container: the last assembled command is as follows: runc create...)
RunC
OCI defines the container runtime standard. runC is a specific implementation of Docker according to the open container format standard (OCF).
Runc is migrated from the libcontainer of docker and implements the functions of container startup and shutdown and resource isolation. Docker provides a docker runc implementation by default. In fact, through the encapsulation of containerd, the implementation of runc can be specified when Docker Daemon is started.
CRI
kubernetes is compatible with multiple container engines in the early version, so you can use docker and rkt to manage containers. Take docker as an example. A docker manager will be started in kubelet to create containers by directly calling docker api.
After k8s version 1.5, kubernetes launched its own runtime interface api – CRI(container runtime interface). The introduction of cri interface isolates the differences between various container engines, and interacts with each container engine through a unified interface.
Different from oci, cri and kubernetes are more compatible and closely bound. cri not only defines the management of container life cycle, but also introduces the concept of pod in k8s and defines the life cycle of managing pod.
In kubernetes, pod is composed of a set of containers in an isolated environment with resource constraints. This isolated environment is called PodSandbox. At the beginning of cri, docker and rkt were mainly supported. kubelet is implemented by calling docker shim and docker api through cri interface.
As mentioned above, docker is independent of containerd. kubernetes also followed the trend and incubated the cri containerd project to connect containerd to the cri standard.
In order to be more compatible with oci, kubernetes also hatched cri-o, which became a bridge between CRI and oci. In this way, it is convenient for more container runtime meeting oci standard to access kubernetes for integrated use. It can be predicted that the compatibility and universality of kubernetes will be further strengthened through cri-o.
Install docker compose
Docker compose project is the official open source project of docker, which is responsible for the rapid arrangement of docker container clusters.
The Docker Compose project is written in Python and calls the API provided by the Docker service to manage the container. Therefore, as long as the operating platform supports Docker API, composition can be used for orchestration management.
Check the version first
[root@k8s-master ~]# /usr/local/bin/docker-compose -version docker-compose version 1.25.1, build a82fef07
If it is installed, it is ok. If it is not installed, install docker
1. Download the docker compose binary file from github and install it
Download the latest docker compose file
# curl -L https://github.com/docker/compose/releases/download/1.25.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
Note: offline installation package has been provided. After uploading, copy it to / usr/local/bin /
cp /root/docker-compose /usr/local/bin/
Add executable permissions
# chmod +x /usr/local/bin/docker-compose
Test installation results
[root@localhost ~]# docker-compose --version docker-compose version 1.25.1, build a82fef07 cp /root/docker-compose /usr/local/bin/ chmod +x /usr/local/bin/docker-compose docker-compose --version
reference:
https://blog.csdn.net/qq_21222149/article/details/89201744
https://blog.csdn.net/warrior_0319/article/details/80073720
http://www.sel.zju.edu.cn/?p=840
http://alexander.holbreich.org/docker-components-explained/
https://www.cnblogs.com/sparkdev/p/9129334.htmls