>摘要：Docker为什么火，靠的就是Docker镜像。他打包了应用程序的所有依赖，彻底解决了环境的一致性问题，重新定义了软件的交付方式，提高了生产效率。本文分享自华为云社区[《认识容器，我们从它的历史开始聊起》](https://bbs.huaweicloud.com/blogs/285728?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 关于容器的历史、发展以及技术本质，在互联网上已经有非常多的文章了。这里旨在结合自身的工作经验和理解，通过一系列的文章，讲清楚这项技术。 # 容器的历史和发展 ### 1、前世 讲到容器，就不得不提LXC（Linux Container），他是Docker的前生，或者说Docker是LXC的使用者。完整的LXC能力在2008年合入Linux主线，所以容器的概念在2008年就基本定型了，并不是后面Docker造出来的。关于LXC的介绍很多，大体都会说“LXC是Linux内核提供的容器技术，能提供轻量级的虚拟化能力，能隔离进程和资源”，但总结起来，无外乎就两大知识点Cgroups（Linux Control Group）和Linux Namespace。搞清楚他俩，容器技术就基本掌握了。 - Cgroups：重点在“限制”。限制资源的使用，包括CPU、内存、磁盘的使用，体现出对资源的管理能力。 - Namespace：重点在“隔离”。隔离进程看到的Linux视图。说大白话就是，容器和容器之间不要相互影响，容器和宿主机之间不要相互影响。 ### 2、少年期起步艰难 2009年，Cloud Foundry基于LXC实现了对容器的操作，该项目取名为Warden。2010年，dotCloud公司同样基于LXC技术，使用Go语言实现了一款容器引擎，也就是现在的Docker。那时，dotCloud公司还是个小公司，出生卑微的Docker没什么热度，活得相当艰难。 ### 3、 成长为巨无霸 2013年，dotCloud公司决定将Docker开源。开源后，项目突然就火了。从大的说，火的原因就是Docker的这句口号“Build once，Run AnyWhere”。呵呵，是不是似曾相识？对的，和Java的Write Once，Run AnyWhere一个道理。对于一个程序员来说，程序写完后打包成镜像就可以随处部署和运行，开发、测试和生产环境完全一致，这是多么大一个诱惑。程序员再也不用去定位因环境差异导致的各种坑爹问题。 Docker开源项目的异常火爆，直接驱动dotCloud公司在2013年更名为Docker公司。Docker也快速成长，干掉了CoreOS公司的rkt容器和Google的lmctfy容器，直接变成了容器的事实标准。也就有了后来人一提到容器就认为是Docker。 总结起来，Docker为什么火，靠的就是Docker镜像。他打包了应用程序的所有依赖，彻底解决了环境的一致性问题，重新定义了软件的交付方式，提高了生产效率。 ### 4、 被列强蚕食 Docker在容器领域快速成长，野心自然也变大了。2014年推出了容器云产品Swarm（K8s的同类产品），想扩张事业版图。同时Docker在开源社区拥有绝对话语权，相当强势。这种走自己的路，让别人无路可走的行为，让容器领域的其他大厂玩家很是不爽，为了不让Docker一家独大，决定要干他。 2015年6月，在Google、Redhat等大厂的“运作”下，Linux基金会成立了OCI（Open Container Initiative）组织，旨在围绕容器格式和运行时制定一个开放的工业化标准，也就是我们常说的OCI标准。同时，Docker公司将Libcontainer模块捐给CNCF社区，作为OCI标准的实现，这就是现在的RunC项目。说白了，就是现在这块儿有个标准了，大家一起玩儿，不被某个特定项目的绑定。 讲到Docker，就得说说Google家的Kubernetes，他作为容器云平台的事实标准，如今已被广泛使用，俨然已成为大厂标配。Kubernetes原生支持Docker，让Docker的市场占有率一直居高不下。如图是2019年容器运行时的市场占有率。  但在2020年，Kubernetes突然宣布在1.20版本以后，也就是2021年以后，不再支持Docker作为默认的容器运行时，将在代码主干中去除dockershim。  如图所示，K8s自身定义了标准的容器运行时接口CRI（Container Runtime Interface），目的是能对接任何实现了CRI接口的容器运行时。在初期，Docker是容器运行时不容置疑的王者，K8s便内置了对Docker的支持，通过dockershim来实现标准CRI接口到Docker接口的适配，以此获得更多的用户。随着开源的容器运行时Containerd（实现了CRI接口，同样由Docker捐给CNCF）的成熟，K8s不再维护dockershim，仅负责维护标准的CRI，解除与某特定容器运行时的绑定。当然，也不是K8s不支持Docker了，只是dockershim谁维护的问题。 随着K8s态度的变化，预计将会有越来越多的开发者选择直接与开源的Containerd对接，Docker公司和Docker开源项目（现已改名为moby）未来将会发生什么样的变化，谁也说不好。  讲到这里，不知道大家有没有注意到，Docker公司其实是捐献了Containerd和runC。这俩到底是啥东西。简单的说，runC是OCI标准的实现，也叫OCI运行时，是真正负责操作容器的。Containerd对外提供接口，管理、控制着runC。所以上面的图，真正应该长这样。  Docker公司是一个典型的小公司因一个爆款项目火起来的案例，不管是技术层面、公司经营层面以及如何跟大厂缠斗，不管是好的方面还是坏的方面，都值得我们去学习和了解其背后的故事。 # 什么是容器 按国际惯例，在介绍一个新概念的时候，都得从大家熟悉的东西说起。幸好容器这个概念还算好理解，喝水的杯子，洗脚的桶，养鱼的缸都是容器。容器技术里面的“容器”也是类似概念，只是装的东西不同罢了，他装的是应用软件本身以及软件运行起来需要的依赖。用鱼缸来类比，鱼缸这个容器里面装的应用软件就是鱼，装的依赖就是鱼食和水。这样大家就能理解docker的logo了。大海就是宿主机，docker就是那条鲸鱼，鲸鱼背上的集装箱就是容器，我们的应用程序就装在集装箱里面。  在讲容器的时候一定绕不开容器镜像，这里先简单的把容器镜像理解为是一个压缩包。压缩包里包含应用的可执行程序以及程序依赖的文件（例如：配置文件和需要调用的动态库等），接下来通过实际操作来看看容器到底是个啥。 ## 一、宿主机视角看容器： **1、首先，我们启动容器。** `docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"` 这是Docker的标准命令。意思是使用euleros_arm:2.0SP8SPC306镜像（镜像名:版本号）创建一个新的名字为"aimar-1-container"的容器，并在容器中执行shell命令：每秒打印一次“aimar-1-container”。 - **参数说明：** -d：使用后台运行模式启动容器，并返回容器ID。 --name：为容器指定一个名字。 docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done" 207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c 从输出中，我们看到一串长字符207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c。他就是容器ID，能唯一标识一个容器。当然在使用的时候，不需要使用全id，直接使用缩写id即可（全id的前几位）。例如下图中，通过docker ps查询到的容器id为207b7c0cbd81  aimar-1-container容器启动成功后，我们在宿主机上使用ps进行查看。这时可以发现刚才启动的容器就是个进程，PID为12280。  我们尝试着再启动2个容器，并再次在宿主机进行查看，你会发现又新增了2个进程，PID分别为20049和21097。  所以，我们可以得到一个结论。**从宿主机的视角看，容器就是进程。** **2、接下来，我们进入这个容器。** `docker exec -it 207b7c0cbd81 /bin/bash` docker exec也是Docker的标准命令，用于进入某个容器。意思是进入容器id为207b7c0cbd81的容器，进入后执行/bin/bash命令，开启命令交互。 - **参数说明：** -it其实是-i和-t两个参数，意思是容器启动后，要分配一个输入/输出终端，方便我们跟容器进行交互，实现跟容器的“对话”能力。  从hostname从kwephispra09909变化为207b7c0cbd81，说明我们已经进入到容器里面了。在容器中，我们尝试着启动一个新的进程。 `[root@207b7c0cbd81 /]# /bin/sh -c "while true; do echo aimar-1-container-embed; sleep 1; done" &`  再次回到宿主机进行ps查看，你会发现**不管是直接启动容器，还是在容器中启动新的进程，从宿主机的角度看，他们都是进程。** # 二、容器视角看容器： 前面我们已经进入容器里面，并启动了新的进程。但是我们并没有在容器里查看进程的情况。在容器中执行ps，会发现得到的结果和宿主机上执行ps的结果完全不一样。下图是容器中的执行结果。  在Container1容器中只能看见刚起启动的shell进程（container1和container1-embed），看不到宿主机上的其他进程，也看不到Container2和Container3里面的进程。这些进程像被关进了一个盒子里面，完全感知不到外界，甚至认为我们执行的container1是1号进程（1号进程也叫init进程，是系统中所有其他用户进程的祖先进程）。所以，**从容器的视角，容器觉得“我就是天，我就是地，欢迎来到我的世界”。**  但尴尬的是，在宿主机上，他们却是普通得不能再普通的进程。注意，相同的进程，在容器里看到的进程ID和在宿主机上看到的进程ID是不一样的。容器中的进程ID分别是1和1859，宿主机上对应的进程ID分别是12280和9775（见上图）。 # 三、总结 通过上面的实验，对容器的定义就需要再加上一个定语。**容器就是进程=>容器是与系统其他部分隔离开的进程。** 这个时候我们再看下图就更容易理解，容器是跑在宿主机OS（虚机容器的宿主机OS就是Guest OS）上的进程，容器间以及容器和宿主机间存在隔离性，例如：进程号的隔离。  在容器内和宿主机上，同一个进程的进程ID不同。例如：Container1在容器内PID是1，在宿主机上是12280。那么该进程真正的PID是什么呢？当然是12280！那为什么会造成在容器内看到的PID是1呢，造成这种幻象的，正是Linux Namespace。 Linux Namespace是Linux内核用来隔离资源的方式。每个Namespace下的资源对于其他Namespace都是不透明，不可见的。  Namespace按隔离的资源进行分类：  前面提到的容器内外，看到的进程ID不同，正是使用了PID Namespace。那么这个Namespace在哪呢？在Linux上一切皆文件。是的，这个Namespace就在文件里。在宿主机上的proc文件中（/proc/进程号/ns）变记录了某个进程对应的Namespace信息。如下图，其中的数字（例如：pid:[ 4026534312]）则表示一个Namespace。  对于Container1、Container2、Container3这3个容器，我们可以看到，他们的PID Namespace是不一样的。说明他们3个容器中的PID相互隔离，也就是说，这3个容器里面可以同时拥有PID号相同的进程，例如：都有PID=1的进程。  在一个命名空间中，那这俩进程就相互可见，只是PID与宿主机上看到的不同而已。  至此，我们可以对容器的定义再细化一层。**容器是与系统其他部分隔离开的进程=》容器是使用Linux Namespace实现与系统其他部分隔离开的进程。**

【问题】本人看了一些华为这边提供的文档，论坛的帖子也看了，也连接设备操作过了，但是目前本人还没有形成一套对AR502H完整的体系，能不能请华为这方面的专家，用简单的白话文来讲解一下lxc-docker-deb-app他们之间的关系？

本文目的:在沃土云环境的前提下搭建docker技术支持的微服务1.代码结构采用微服务编写,各个服务采用http,rpc都可,本文重点不在代码层面2.把单个服务用docker 运行起来,编写Dcokerfile 可参考:https://www.bookstack.cn/read/gin-EDDYCJY-blog/golang-gin-2018-03-24-Gin%E5%AE%9E%E8%B7%B5-%E8%BF%9E%E8%BD%BD%E4%B9%9D-%E5%B0%86Golang%E5%BA%94%E7%94%A8%E9%83%A8%E7%BD%B2%E5%88%B0Docker.md3.在沃土上编译golang的项目(需要注意) 编译命令需要使用环境变量CGO_ENABLED直接使用go build . 生成的可执行文件 会报  line 1: syntax error: unexpected word (expecting ")")这种情况要用CGO_ENABLED当CGO_ENABLED=1， 进行编译时， 会将文件中引用libc的库（比如常用的net包），以动态链接的方式生成目标文件。当CGO_ENABLED=0， 进行编译时， 则会把在目标文件中未定义的符号（外部函数）一起链接到可执行文件中。示例: CGO_ENABLED=0 go build -o  projectName4.用docker网络或docker swarm搭建docker 网络,把各个微服务加到同一个网络中docker run --net=project-network --network-alias subService5.在项目根目录 docker build .6.注意,启动时先用构建出来的可执行文件,本地测试,可以运行,方可以运行在各个容器环境

使用eciot-ova.tar.gz中的create-ova工具，将docker镜像文件转成ova容器，对docker镜像文件有什么限制吗？比如大小限制

【故障现象】docker 容器中运行redis无法启动，详情截图如下：【故障诊断】根据redis的日志信息提示，初步判断是配置文件的问题。【故障原因】配置文件中的内容导致redis无法启动。【解决方案】Redis will now exit to prevent data corruption. Note that it is possible to suppress this warning by setting the following config: ignore-warnings ARM64-COW-BUG。根据信息提示，即在 redis.conf 中取消这最后一条注释： ignore-warnings ARM64-COW-BUG ，再重启redis服务即可。

**一、现象描述** 1、CCE控制台创建无状态工作负载，一个负载同时创建两个实例，在创建过程中，一个创建成功，一个创建失败。创建失败的报错信息为镜像拉取失败，具体报错如下所示： Failed to pull image “swr.cn-north-4.myhuaweicloud.com/tansj/hw_cns_bmfw_web:v50”: [rpc error: code = Unknown desc = Error response from daemon: Get https://swr.cn-north-4.myhuaweicloud.com/v2/: dial tcp: lookup swr.cn-north-4.myhuaweicloud.com on [::1]:53: read udp [::1]:58207->[::1]:53: read: connection refused, rpc error: code = Unknown desc = Error response from daemon: Get https://swr.cn-north-4.myhuaweicloud.com/v2/: dial tcp: lookup swr.cn-north-4.myhuaweicloud.com on [::1]:53: read udp [::1]:47536->[::1]:53: read: connection refused] **二、问题分析** 1、根据具体的报错可知，镜像拉取过程中，在访问华为云的SWR时连接被拒绝。初步分析为服务器访问华为云SWR时被拒绝。 2、登录镜像拉取失败的服务器执行以下命令: curl https://swr.cn-north-4.myhuaweicloud.com/v2/  Cloud not resolve host swr.cn-north-4.myhuaweicloud.com ，根据报错可知当前服务器没办法正常解析域名 尝试curl其他网站，如curl www.baidu.com，还是出现同样的问题。  3、查看当前服务器的resolv.conf 文件。 cat /etc/resolv.conf  根据以上文件配置内容可知，当前服务器没有配置DNS服务器的地址，导致解析出现问题。 **三、解决方案** 1、查询北京四DNS服务器的内网地址 https://support.huaweicloud.com/dns_faq/dns_faq_002.html  2、resolv.conf 文件配置上nameserver nameserver 100.125.1.250 nameserver 100.125.129.250 3、重新curl https://swr.cn-north-4.myhuaweicloud.com/v2/  4、CCE控制台重新创建负载，如图可见两个实例创建成功 

【功能模块】按照《边缘网关二次开发指南（AR502系列）》说明，安装容器失败【操作步骤&问题现象】1、container install demo latest.ova2、 Failed to start container.【截图信息】 【日志信息】（可选，上传日志内容或者附件）不知道去哪里查容器日志

通过Docker运行TensorFlow　　该方式的优点是不用操心软件依赖问题。方法　　首先，安装Docker，一旦Docker已经启动运行，可以通过命令启动一个容器:$ docker run -it b.gcr.io/tensorflow/tensorflow　　该命令将启动一个已经安装好的TensorFlow及相关依赖的容器。其它镜像 　　默认的 Docker 镜像只包含启动和运行 TensorFlow 所需依赖库的一个最小集. 我们额外提供了 下面的容器, 该容器同样可以通过上述 docker run 命令安装:　　b.gcr.io/tensorflow/tensorflow-full: 镜像中的 TensorFlow 是从源代码完整安装的, 包含了编译和运行 TensorFlow 所需的全部工具。　　在该镜像上, 可以直接使用源代码进行实验, 而不需要再安装上述的任何依赖.

目前robox容器可以启动，但是进入docker容器里发现android镜像并没有启动成功，使用的是华为云官网上提供的android镜像：

按照官网robox方案搭建android环境（地址：https://support.huaweicloud.com/prtg-robox-kunpengcps/kunpengcps_02_0002.html），按照操作步骤完成安装部署（除了ExaGear没有安装部署，因为不需要arm32转arm64），最后运行的时候报错，不知道有没有人能帮忙看下。从运行日志上看主要是session-manager 起不来，单独起docker也是ok的，单独启动session-manager 报错如下：root@ni:/home/robox-master# export DISPLAY=:0 root@ni:/home/robox-master# export XDG_RUNTIME_DIR=/run/user/0 root@ni:/home/robox-master# mkdir /run/user/0 root@ni:/home/robox-master# root@ni:/home/robox-master# anbox session-manager --run-multiple=1 --standalone --experimental --single-window --window-size=720,1280 libEGL warning: DRI2: failed to authenticate [ 2021-09-05 08:19:57] [daemon.cpp:63@Run] Failed to connect to DBus root@ni:/home/robox-master# 单独起docker运行：root@ni:/home/robox-master# root@ni:/home/robox-master# docker images REPOSITORY TAG IMAGE ID CREATED SIZE android robox_with_exagear 2cc0051fd624 2 days ago 860MB root@ni:/home/robox-master# root@ni:/home/robox-master# docker run -d -it --name instance1 android:robox_with_exagear /anbox-init.sh 53e1c5f5e883e3cd6ee086ca493bf529fba6eb3c6bc65e0095766370ef4b67b1 root@ni:/home/robox-master# root@ni:/home/robox-master# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 53e1c5f5e883 android:robox_with_exagear "/anbox-init.sh" 5 seconds ago Up 4 seconds instance1 root@ni:/home/robox-master# Xorg启动运行如下：root@ni:/home/robox-master# root@ni:/home/robox-master# Xorg :0 -config /etc/X11/xorg.conf X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.15.0-140-generic aarch64 Ubuntu Current Operating System: Linux ni 4.15.18 #1 SMP Fri Sep 3 11:35:37 CST 2021 aarch64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.18 root=/dev/mapper/ni--vg-root ro Build Date: 08 April 2021 01:53:49PM xorg-server 2:1.19.6-1ubuntu4.9 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Sep 5 16:22:06 2021 (++) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" pci id for fd 13: 19e5:1711, driver (null) EGL_MESA_drm_image required.

参考bootkit arm云原生编译robox启动报错，anbox_bridge qemu_pipe anbox_audio 这3个没有，是否是缺包导致还是可能什么步骤没执行，帮忙指导看下目前使用Ubuntu18.04.1 内核4.15.18https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=151195看日志是docker容器没有成功启动，可以用docker ps -a查看是哪个容器启动失败，再使用docker logs 容器id查看具体报错排查一下1.xorg的进程是否启动 2.启动脚本里的镜像名字与你注册的是否一样 3.启动脚本里xorg的端口号是否xorg的进程端口号一致客户反馈目前就起了一个容器， 执行./robox -v start 1 启动命令的时候， 没有容器启动信息， 所以docker logs看不了。其他排查点：1.xorg的进程是否启动 2.启动脚本里的镜像名字与你注册的是否一样 3.启动脚本里xorg的端口号是否xorg的进程端口号一致另外看了一下， 启动应该是是卡在检测如下三个文件上：/run/user/0 这个目录本来是没有的，是我手动创建的

编写Playbook批量二进制部署Docker   二进制方式部署的Docker，可以离线完成，不要求网络，并且对系统的适配性较好。vi example.yaml- hosts: docker   vars:  remote_user: root  gather_facts: false  tasks:  - name: 分发并解压docker二进制包    unarchive: src=files/docker-18.09.6.tgz dest=/tmp   - name: 移动docker二进制文件    shell: mv /tmp/docker/* /usr/bin  - name: 分发service文件    copy: src=files/docker.service dest=/usr/lib/systemd/system/  - name: 启动docker并设置开机启动    systemd: name=docker state=restarted enabled=yes daemon_reload=yes  - name: 查看状态    shell: docker info    register: docker   - debug: var=docker.stdout_lines#ansible-playbook example.yaml -k

与监控实体主机一样，首先需要在被监控端安装采集器cAdvisor选一台安装了docker的主机：Docker部署cAdvisor：docker run -d \--volume=/:/rootfs:ro \--volume=/var/run:/var/run:ro \--volume=/sys:/sys:ro \--volume=/var/lib/docker/:/var/lib/docker:ro \--volume=/dev/disk/:/dev/disk:ro \--publish=8080:8080 \--detach=true \--name=cadvisor \google/cadvisor:latest使用浏览器http://EIP:8080访问：配置prometheus的数据源：[root@ecs-0720 prometheus]# vi prometheus.yml - job_name: "docker"    static_configs:      - targets:["114.115.168.136:8080"][root@ecs-0720 prometheus]# kill -HUP 7155grafana中再import一个模板193：

一、操作系统和软件版本介绍1.操作系统为openEuler 20.03 (LTS-SP1)   可用如下命令查询：[root@1ocalhost ~]# cat /etc/os-release [root@1ocalhost ~]# uname -i二.docker安装  下载软件rpm包wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-17.12.1.ce-1.el7.centos.x86_64.rpm 用yum命令安装[root@1ocalhost ~]# yum install docker-ce-17.12.1.ce-1.el7.centos.x86_64.rpm  加入自启动[root@1ocalhost ~]# systemctl enable docker 启动docker[root@1ocalhost ~]# systemctl start docker [root@1ocalhost ~]# docker run hello-world三.开启远程访问  查询状态[root@1ocalhost ~]# systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-08-18 14:30:54 CST; 3min 21s ago Docs: https://docs.docker.com Main PID: 39341 (dockerd) Tasks: 19 Memory: 28.7M CGroup: /system.slice/docker.service ├─39341 /usr/bin/dockerd └─39347 docker-containerd --config /var/run/docker/containerd/containerd.toml Aug 18 14:30:53 1ocalhost dockerd[39341]: time="2021-08-18T14:30:53.976077406+08:00" level=info msg="L> Aug 18 14:30:54 1ocalhost dockerd[39341]: time="2021-08-18T14:30:54.043802823+08:00" level=info msg="D> Aug 18 14:30:54 1ocalhost dockerd[39341]: time="2021-08-18T14:30:54.070649796+08:00" level=info msg="L> Aug 18 14:30:54 1ocalhost dockerd[39341]: time="2021-08-18T14:30:54.105805696+08:00" level=info msg="D> Aug 18 14:30:54 1ocalhost dockerd[39341]: time="2021-08-18T14:30:54.105846846+08:00" level=info msg="D> Aug 18 14:30:54 1ocalhost dockerd[39341]: time="2021-08-18T14:30:54.110040371+08:00" level=info msg="A> Aug 18 14:30:54 1ocalhost systemd[1]: Started Docker Application Container Engine. Aug 18 14:31:05 1ocalhost dockerd[39341]: time="2021-08-18T14:31:05+08:00" level=info msg="shim docker> Aug 18 14:31:05 1ocalhost dockerd[39341]: time="2021-08-18T14:31:05+08:00" level=info msg="shim reaped> Aug 18 14:31:05 1ocalhost dockerd[39341]: time="2021-08-18T14:31:05.974762303+08:00" level=info msg="i> lines 1-21/21 (END) 开启远程端口，允许远程访问[root@1ocalhost ~]# vi /usr/lib/systemd/system/docker.service   刷新配置重启docker[root@1ocalhost ~]# systemctl daemon-reload [root@1ocalhost ~]# systemctl restart docker测试[root@1ocalhost ~]# curl http://localhost:2375/version [root@1ocalhost ~]# curl http://localhost:2375/info