>摘要：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实现与系统其他部分隔离开的进程。**

IVS1800运行第三方算法，通过TLV格式发布事件，回传告警信息，不在docker中运行的时候，restful接口以及HoloSens_iClient都可以查询到告警记录，但是在docker中运行后，restful接口以及HoloSens_iClient都查询不到告警记录，但是1800的/opt/log/ivs_srvfs/run目录下的事件发布日志都是正常的，下面是docker创建的命令：docker run  -it \       --device=/dev/cache \       --privileged=true \       --device=/dev/davinci_manager \       --device=/dev/hisi_hdc \       --device=/dev/davinci0 \       --device=/dev/davinci1 \       --name=ivs1800app \       --log-opt max-file=2 \       --log-opt max-size=30KB \       --memory 500MB \       --cpus=0.3 \       --ulimit nofile=65535:65535 \       --net=host \       --user HwHiAiUser \       --privileged=false \       --cpuset-cpus="2,3" \       --pids-limit 100 \       --security-opt apparmor=docker-default,no-new-privileges,label=level:TopSecret \       --cap-drop NET_RAW \       -v /opt/third_algorithm_D/3rdApp/ivsapp/data:/home/3rdApp/data \       -v /opt/third_algorithm/run/ivsapp/res:/home/3rdApp/res \       -v /opt/third_algorithm/run/ivsapp/conf:/home/3rdApp/conf \       -v /opt/third_algorithm/run/ivsapp/license_lic:/home/3rdApp/license_lic \       -v /var/dlog:/var/dlog \       -v /usr/slog:/usr/slog \       -v /mnt/srvfs:/mnt/srvfs \       -v /tmp:/tmp \       ivsapp:v1.0 \       /bin/bash \       -c "/home/init_container.sh"

【问题】本人看了一些华为这边提供的文档，论坛的帖子也看了，也连接设备操作过了，但是目前本人还没有形成一套对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控制台重新创建负载，如图可见两个实例创建成功 

一、安装docker1、备份配置文件：cp -a /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak2、下载新的CentOS-Base.repo文件到/etc/yum.repos.d/目录下，执行如下命令：wget -O /etc/yum.repos.d/CentOS-Base.repo https://repo.huaweicloud.com/repository/conf/CentOS-AltArch-7.repo3、执行yum clean all清除原有yum缓存。4、执行yum makecache（刷新缓存）或者yum repolist all（查看所有配置可以使用的文件，会自动刷新缓存）。5、安装Deltarpm包（增量 RPM 套件）yum provides '*/applydeltarpm' yum install deltarpm -y6、若安装过docker，需要先删掉，之后再安装依赖:yum remove docker docker-common docker-selinux docker-engine yum install -y yum-utils device-mapper-persistent-data lvm27、下载repo文件：wget -O /etc/yum.repos.d/docker-ce.repo https://repo.huaweicloud.com/docker-ce/linux/centos/docker-ce.repo软件仓库地址替换为：sed -i 's+download.docker.com+repo.huaweicloud.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo8、更新索引文件并安装yum makecache fast yum install docker-ce docker-ce-cli containerd.io9、（可选）要安装特定版本的 Docker Engine，请在 repo 中列出可用版本，然后选择并安装：一种。列出并排序您的存储库中可用的版本。此示例按版本号对结果进行排序，从高到低，并被截断：yum list docker-ce --showduplicates | sort -r完全限定的包名称安装特定版本，即包名称 ( docker-ce) 加上从第一个冒号 ( :)开始的版本字符串（第 2 列），直到第一个连字符，由连字符 ( -)分隔。例如，docker-ce-19.03.9。yum install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io此命令会安装 Docker，但不会启动 Docker。它还会创建一个 docker组，但是，默认情况下它不会向该组添加任何用户。10、启动dockersystemctl start docker11、进入 /etc/docker，没有daemon.json文件就自己新建一个：编辑daemon.json文件加入这段代码：{ "registry-mirrors": ["https://registry.docker-cn.com"] }10、然后重启docker：systemctl restart docker.service

1、docker内使用gdb发生报错“warning: Error disabling address space randomization: Operation not permitted”2、添加--security-opt seccomp=unconfined 选项到docker run

问题现象：Atlas 500使用docker bridge模式创建网桥，系统重启后网桥丢失关键过程：1.在Atlas 500上使用docker命令创建网桥（bridge），reboot重启系统后，创建的网桥丢失；反复验证，问题复现；2.同样的操作，在Ubuntu系统下创建网桥并重启，不会丢失；3. 经确认，Atlas 500 Euler系统基于数据保护策略，重启之后会清理数据，目前系统实现机制就是如此；而Ubuntu系统机制不同于Euler，重启操作后不会清理数据；4. 因业务需要使用docker的bridge模式来实现容器之间的通信，直接在Atlas 500下创建的网桥重启会被清理，所以将创建网桥的操作固化在user_init.sh下，实现持久化配置，保证创建的网桥不会丢失；具体步骤如下：a. SSH登录Atlas 500 后台，执行命令vi /home/data/user/user_init.shb. 在脚本中添加命令：#!/bin/bash docker network create xxxc. 修改user_init.sh权限：chmod 755 /home/data/user/user_init.shd. 保存并退出，持久化配置操作完成。结论、解决方案结论：Atlas 500 Euler系统安全机制要求，重启会清理部分数据；解决方案：将docker创建网桥的操作固化在/home/data/user/user_init.sh中，以实现持久化配置、解决网桥丢失问题；Docker网络模式相关知识参阅：https://blog.csdn.net/u011541946/article/details/87826222https://www.cnblogs.com/sanduzxcvbnm/p/13370773.html

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

【功能模块】https://gitee.com/mindspore/mindspore/tree/r1.3/model_zoo/official/cv/resnet_thor【操作步骤&问题现象】1、拉取mindspore 1.3的镜像：docker pull swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.3.02、运行镜像docker run -it -v /dev/shm:/dev/shm -v /path/to/dataset:/path/to/dataset --runtime=nvidia --privileged=true swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.3.03、在8卡v100机器上训练sh run_distribute_train_gpu.sh /path/to/dataset 8【截图信息】【日志信息】（可选，上传日志内容或者附件）epoch: 32 step: 5004, loss is 2.2936077epoch: 32 step: 5004, loss is 2.403049epoch: 32 step: 5004, loss is 1.8597395epoch: 32 step: 5004, loss is 2.1784513epoch: 32 step: 5004, loss is 2.1430013epoch: 32 step: 5004, loss is 1.8287767epoch: 32 step: 5004, loss is 1.927578epoch: 32 step: 5004, loss is 1.8246645epoch time: 5372604.995 ms, per step time: 1073.662 msepoch time: 5372619.719 ms, per step time: 1073.665 msepoch time: 5372814.251 ms, per step time: 1073.704 msepoch time: 5372513.237 ms, per step time: 1073.644 msepoch time: 5372558.263 ms, per step time: 1073.653 msepoch time: 5372484.428 ms, per step time: 1073.638 msepoch time: 5372676.158 ms, per step time: 1073.676 msepoch time: 5372801.586 ms, per step time: 1073.701 ms可以看到一个epoch需要一个多小时，非常慢

你好！在容器内跑npu-smi出错，提示如下。在主机上跑是没问题的，请问是怎么回事？root@13adfe00e051:/data# npu-smi info[ERROR] DRV(230,None):2021-10-11-06:07:23.600.088 [../../../../../../../hardware/dev_platform/devhdc/hdc_core.c:500][hdc] [hdcPcieInit 500] HDC init fail, driver may not load.[ERROR] DRV(230,None):2021-10-11-06:07:33.609.358 [../../../../../../../hardware/dev_platform/devhdc/hdc_core.c:485][hdc] [hdc_phandle_get 485] HDC init, open pcie device fail. error : No such file or directory[ERROR] DRV(230,None):2021-10-11-06:07:33.609.520 [../../../../../../../hardware/dev_platform/devhdc/hdc_core.c:506][hdc] [hdcPcieInit 506] HDC init fail, get handle failed.[ERROR] DRV(230,None):2021-10-11-06:07:33.609.617 [../../../../../../../hardware/dev_platform/devhdc/hdc_core.c:558][hdc] [hdcInit 558] hdcPcieInit fail.ret (4)[ERROR] DRV(230,None):2021-10-11-06:08:37.236.258 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common.c:299][dmp] [dsmi_send_msg_rec_res 299] dev 0 DSMI recv timeout:0 recv data_len 14 recv_cnt 0 recv_success_cnt 0 send_cnt 1.[ERROR] DRV(230,None):2021-10-11-06:08:37.236.428 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common.c:300][dmp] [dsmi_send_msg_rec_res 300] send time:941586 second,62785398 nasec.[ERROR] DRV(230,None):2021-10-11-06:08:37.236.491 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common.c:301][dmp] [dsmi_send_msg_rec_res 301] recv time:0 second,0 nasec.[ERROR] DRV(230,None):2021-10-11-06:08:37.236.571 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common.c:302][dmp] [dsmi_send_msg_rec_res 302] reok time:0 second,0 nasec.[ERROR] DRV(230,None):2021-10-11-06:08:37.236.635 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common.c:303][dmp] [dsmi_send_msg_rec_res 303] tout time:941649 second,623704997 nasec.[ERROR] DRV(230,None):2021-10-11-06:08:37.236.696 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_dmp_command.c:578][dmp] [dsmi_cmd_get_board_id 578] dev(0) dsmi_send_msg_rec_res failed, ret(536871427)[ERROR] DRV(230,None):2021-10-11-06:08:37.236.754 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common_interface.c:1103][dmp] [dsmi_get_board_id 1103] dev(0) dsmi_cmd_get_board_id failed 536871427[ERROR] DRV(230,None):2021-10-11-06:08:37.236.813 [../../../../../../../../../hardware/dev_plat/dsmi/src/dsmi_common/dsmi_common_interface.c:1251][dmp] [dsmi_get_board_info 1251] dev(0) dsmi_board_id call error, ret 536871427+------------------------------------------------------------------------------+| npu-smi 20.2.0                       Version:                                |+-------------------+-----------------+----------------------------------------+| NPU     Name      | Health          | Power(W)          Temp(C)              || Chip    Device    | Bus-Id          | AICore(%)         Memory-Usage(MB)     |+===================+=================+========================================+docker 启动命令如下docker run -it --device=/dev/davinci0 \    --device=/dev/davinci_manager \    --device=/dev/davinci_mdio \    --device=/dev/log_drv \    --device=/dev/event_sched \    --device=/dev/svm0 \    --device=/dev/hi_dvpp \    --device=/dev/hi_sfc \    --device=/dev/ts_aisle \    --device=/dev/svm0 \    --device=/dev/i2c-0 \    --device=/dev/i2c-1 \    --device=/dev/i2c-2 \    -v /usr/local/sbin/npu-smi:/usr/local/sbin/npu-smi \    -v /usr/local/Ascend/:/usr/local/Ascend/ \    -v /usr/bin:/usr/bin \    -v /usr/lib:/usr/lib \    -v /usr/lib64:/usr/lib64 \    -v /usr/include:/usr/include \    -v /home/HwHiAiUser/docker-disk:/mnt \    -v /mnt:/data \    -v /sys/fs/cgroup/cpuset:/sys/fs/cgroup/cpuset \    --name video-analysis-infer2 \    mxvision-infer-arm /bin/bash

使用命令拉取镜像：sudo docker pull swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.3.0运行： docker run -it -v /dev/shm:/dev/shm --runtime=nvidia --privileged=true swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.3.0 /bin/bash报错：docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: Running hook #1:: error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: requirement error: unsatisfied condition: cuda>=11.1, please update your driver to a newer version, or use an earlier cuda container: unknown.ERRO[0000] error waiting for container: context canceled。使用docker安装mindspore1.3还需要限制cuda版本？