在之前的介绍中,我们知道镜像是 Docker 的三大组件之一。 Docker 运行容器前需要本地存在对应的镜像,如果本地不存在该镜像,Docker 会从镜像仓库 下载该镜像。
之前提到过,Docker Hub 上有大量的高质量的镜像可以用,这里我们就说一下怎么获取这些 镜像。
从 Docker 镜像仓库获取镜像的命令是 docker pull
。其命令格式为:
docker pull [选项] [Docker Registry 地址[:端口号]/]上面的命令中没有给出 Docker 镜像仓库地址,因此将会从 Docker Hub 获取镜像。仓库名[:标签]
具体的选项可以通过 docker pull --help
命令看到。
例如:
$ docker pull ubuntu:16.04
16.04: Pulling from library/ubuntu
bf5d46315322: Pull complete
9f13e0ac480c: Pull complete
e8988b5b3097: Pull complete
40af181810e7: Pull complete
e6f7c7e5c03e: Pull complete
Digest: sha256:147913621d9cdea08853f6ba9116c2e27a3ceffecf3b492983ae97c3d643fbbe
Status: Downloaded newer image for ubuntu:16.0
上面的命令中没有给出 Docker 镜像仓库地址,因此将会从 Docker Hub 获取镜像。
而镜像名 称是 ubuntu:16.04 ,因此将会获取官方镜像 library/ubuntu 仓库中标签为 16.04 的镜像。
从下载过程中可以看到我们之前提及的分层存储的概念,镜像是由多层存储所构成。下载也是一层层的去下载,并非单一文件。下载过程中给出了每一层的 ID 的前 12 位。并且下载结 束后,给出该镜像完整的 sha256 的摘要,以确保下载一致性。
如果从 Docker Hub 下载镜像非常缓慢,可以参照 镜像加速 一节配置加速器。
运行:
有了镜像后,我们就能够以这个镜像为基础启动并运行一个容器。以上面的 ubuntu:16.04 为 例,如果我们打算启动里面的 bash 并且进行交互式操作的话,可以执行下面的命令。
$ docker run -it --rm \
ubuntu:16.04 \
bash
root@e7009c6ce357:/# cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.4 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.4 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
docker run
就是运行容器的命令,具体格式我们会在 容器 一节进行详细讲解,我们这里简要的说明一下上面用到的参数。
-it
:这是两个参数,一个是 -i :交互式操作,一个是 -t 终端。我们这里打算进入 bash 执行一些命令并查看返回结果,因此我们需要交互式终端。--rm
:这个参数是说容器退出后随之将其删除。默认情况下,为了排障需求,退出的容 器并不会立即删除,除非手动 docker rm 。我们这里只是随便执行个命令,看看结果, 不需要排障和保留结果,因此使用 --rm 可以避免浪费空间。ubuntu:16.04
:这是指用 ubuntu:16.04 镜像为基础来启动容器。bash
:放在镜像名后的是命令,这里我们希望有个交互式 Shell,因此用的是 bash 。进入容器后,我们可以在 Shell 下操作,执行任何所需的命令。这里,我们执行了 cat /etc/os-release ,这是 Linux 常用的查看当前系统版本的命令,从返回的结果可以看到容器 内是 Ubuntu 16.04.4 LTS 系统。
最后可以通过exit
退出容器。
要想列出已经下载下来的镜像,可以使用 docker image ls
命令。
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest 5f515359c7f8 5 days ago 183 MB
nginx latest 05a60462f8ba 5 days ago 181 MB
mongo 3.2 fe9198c04d62 5 days ago 342 MB
<none> <none> 00285df0df87 5 days ago 342 MB
ubuntu 16.04 f753707788c5 4 weeks ago 127 MB
ubuntu latest f753707788c5 4 weeks ago 127 MB
ubuntu 14.04 1e0c3dd64ccd 4 weeks ago 188 MB
列表包含了 仓库名
、 标签
、 镜像 ID
、 创建时间
以及 所占用的空间
。
其中仓库名、标签在之前的基础概念章节已经介绍过了。
镜像 ID 则是镜像的唯一标识,一个 镜像可以对应多个标签(也就是版本)。因此,在上面的例子中,我们可以看到 ubuntu:16.04 和 ubuntu:latest 拥有相同的 ID,因为它们对应的是同一个镜像。
如果仔细观察,会注意到,这里标识的所占用空间和在 Docker Hub 上看到的镜像大小不同。 比如, ubuntu:16.04 镜像大小,在这里是 127 MB ,但是在 Docker Hub 显示的却是 50 MB 。
这是因为 Docker Hub 中显示的体积是压缩后的体积。在镜像下载和上传过程中镜像是 保持着压缩状态的,因此 Docker Hub 所显示的大小是网络传输中更关心的流量大小。而 docker image ls
显示的是镜像下载到本地后,展开的大小,准确说,是展开后的各层所占空间的总和,因为镜像到本地后,查看空间的时候,更关心的是本地磁盘空间占用的大小。
另外一个需要注意的问题是, docker image ls
列表中的镜像体积总和并非是所有镜像实际硬盘消耗。由于 Docker 镜像是多层存储结构,并且可以继承、复用,因此不同镜像可能会因为 使用相同的基础镜像,从而拥有共同的层。由于 Docker 使用 分层存储(Union FS),相同的层只需要保 存一份即可,因此实际镜像硬盘占用空间很可能要比这个列表镜像大小的总和要小的多。
你可以通过以下命令来便捷的查看镜像、容器、数据卷所占用的空间。
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAI MABLE
Images 24 0 1.992GB 1.992GB (100%)
Containers 1 0 62.82MB 62.82MB (100%)
Local Volumes 9 0 652.2MB 652.2MB (100%)
Build Cache 0B 0B
上面的镜像列表中,还可以看到一个特殊的镜像,这个镜像既没有仓库名,也没有标签,均 为 <none>
:
<none> <none> 00285df0df87 5 days ago 342 MB
这个镜像原本是有镜像名和标签的,原来为 mongo:3.2
,随着官方镜像维护,发布了新版本 后,重新 docker pull mongo:3.2
时, mongo:3.2
这个镜像名被转移到了新下载的镜像身 上,而旧的镜像上的这个名称则被取消,从而成为了 <none>
。除了 docker pull
可能导致 这种情况, docker build
也同样可以导致这种现象。
由于新旧镜像同名,旧镜像名称被取消,从而出现仓库名、标签均为<none>
的镜像。这类无标签镜像也被称为虚悬镜像 (dangling image) ,可以用下面的命令专门显示这类镜像:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 00285df0df87 5 days ago 342 MB
一般来说,虚悬镜像已经失去了存在的价值,是可以随意删除的,可以用下面的命令删除。
$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
....
为了加速镜像构建、重复利用资源,Docker 会利用 中间层镜像。所以在使用一段时间后,可能会看到一些依赖的中间层镜像。默认的docker image ls
列表中只会显示顶层镜像,如果 希望显示包括中间层镜像在内的所有镜像的话,需要加 -a
参数。
$ docker image ls -a
REPOSITORY TAG IMAGE ID CREATED SIZE
bannerstudioblog0.1 latest 9f2070cdcccf 4 months ago 1.19GB
<none> <none> fde0dda57bd8 4 months ago 1.19GB
<none> <none> c1d6969dac38 4 months ago 1.19GB
<none> <none> 3259bedf1c23 4 months ago 941MB
<none> <none> 624dbf7d7d15 4 months ago 941MB
<none> <none> a59da3e50d84 8 months ago 1.19GB
blog 1.0 49c0867d1034 8 months ago 1.19GB
<none> <none> 3d90f69e5bbf 8 months ago 1.19GB
<none> <none> fc8359346240 8 months ago 941MB
<none> <none> 1013dd8cbbda 8 months ago 941MB
bannerblog 1.0 d56fe6bfb15d 12 months ago 1.19GB
<none> <none> 59013b16731b 12 months ago 1.19GB
<none> <none> 6d1d6db01a93 12 months ago 1.19GB
<none> <none> 35a790a2bce7 12 months ago 992MB
<none> <none> 7168e72c7905 15 months ago 1.17GB
beego-blog 0.1 024d19f072db 15 months ago 1.17GB
<none> <none> e6ae2d10a2fb 15 months ago 1.17GB
<none> <none> cdb0c5741207 15 months ago 962MB
<none> <none> f61bbad8b9bc 15 months ago 941MB
<none> <none> 2bec8d75d139 15 months ago 941MB
golang latest 276895edf967 19 months ago 941MB
mysql latest 3218b38490ce 19 months ago 516MB
centos 7 eeb6ee3f44bd 22 months ago 204MB
b3log/solo latest 4afbc7964f83 23 months ago 144MB
elasticsearch 7.12.0 9337ed510a0c 2 years ago 830MB
这样会看到很多无标签的镜像,与之前的虚悬镜像不同,这些无标签的镜像很多都是中间层镜像,是其它镜像所依赖的镜像。这些无标签镜像不应该删除,否则会导致上层镜像因为依赖丢失而出错。实际上,这些镜像也没必要删除,因为之前说过,相同的层只会存一遍,而 这些镜像是别的镜像的依赖,因此并不会因为它们被列出来而多存了一份,无论如何你也会 需要它们。只要删除那些依赖它们的镜像后,这些依赖的中间层镜像也会被连带删除。
不加任何参数的情况下, docker image ls
会列出所有顶级镜像,但是有时候我们只希望列出部分镜像。
docker image ls
有好几个参数可以帮助做到这个事情。
除此以外, docker image ls
还支持强大的过滤器参数 --filter ,或者简写 -f 。之前我们 已经看到了使用过滤器来列出虚悬镜像的用法(docker image ls -f dangling=true
),它还有更多的用法。
比如,我们希望看到在 mongo:3.2 之后建立的镜像,可以用下面的命令:
$ docker image ls -f since=mongo:3.2
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest 5f515359c7f8 5 days ago 183 MB
nginx latest 05a60462f8ba 5 days ago 181 MB
想查看某个位置之前的镜像也可以,只需要把 since 换成 before 即可。
此外,如果镜像构建时,定义了 LABEL
,还可以通过 LABEL 来过滤。
$ docker image ls -f label=com.example.version=0.1
默认情况下, docker image ls
会输出一个完整的表格,但是我们并非所有时候都会需要这些内容。比如,刚才删除虚悬镜像的时候,我们需要利用 docker image ls
把所有的虚悬镜像 的 ID 列出来,然后才可以交给 docker image rm
命令作为参数来删除指定的这些镜像,这个时候就用到了 -q 参数。
$ docker image ls -q
5f515359c7f8
05a60462f8ba
fe9198c04d62
00285df0df87
f753707788c5
f753707788c5
1e0c3dd64ccd
--filter
配合 -q
产生出指定范围的 ID 列表,然后送给另一个 docker 命令作为参数,从而针对这组实体成批的进行某种操作的做法 在 Docker 命令行使用过程中非常常见,不仅仅是镜像,将来我们会在各个命令中看到这类搭配以完成很强大的功能。因此每次在文档看到过滤器后,可以多注意一下它们的用法。
另外一些时候,我们可能只是对表格的结构不满意,希望自己组织列;或者不希望有标题,这样方便其它程序解析结果等,这就用到了 Go 的模板语法。
比如,下面的命令会直接列出镜像结果,并且只包含镜像ID和仓库名和标签:
$ docker image ls --format "{{.ID}}: {{.Repository}}:{{.Tag}}"
9f2070cdcccf: bannerstudioblog0.1:latest
49c0867d1034: blog:1.0
d56fe6bfb15d: bannerblog:1.0
024d19f072db: beego-blog:0.1
276895edf967: golang:latest
3218b38490ce: mysql:latest
eeb6ee3f44bd: centos:7
4afbc7964f83: b3log/solo:latest
9337ed510a0c: elasticsearch:7.12.0
或者打算以表格等距显示,并且有标题行,和默认一样,不过自己定义列:
$ docker image ls --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}"
IMAGE ID REPOSITORY TAG
9f2070cdcccf bannerstudioblog0.1 latest
49c0867d1034 blog 1.0
d56fe6bfb15d bannerblog 1.0
024d19f072db beego-blog 0.1
276895edf967 golang latest
3218b38490ce mysql latest
eeb6ee3f44bd centos 7
4afbc7964f83 b3log/solo latest
9337ed510a0c elasticsearch 7.12.0
如果要删除本地的镜像,可以使用 docker image rm
命令,其格式为:
$ docker image rm [选项] <镜像1> [<镜像2> ...]
其中, <镜像>
可以是 镜像短 ID 、 镜像长 ID 、 镜像名 或者 镜像摘要 。
比如我们有这么一些镜像:
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
centos latest 0584b3d2cf6d 3 weeks ago 196.5 MB
redis alpine 501ad78535f0 3 weeks ago 21.03 MB
docker latest cf693ec9b5c7 3 weeks ago 105.1 MB
nginx latest e43d811ce2f4 5 weeks ago 181.5 MB
我们可以用镜像的完整 ID,也称为 长 ID ,来删除镜像。
使用脚本的时候可能会用长 ID,但 是人工输入就太累了,所以更多的时候是用 短 ID 来删除镜像。
docker image ls 默认列出 的就已经是短 ID 了,一般取前3个字符以上,只要足够区分于别的镜像就可以了。
$ docker image rm 501
Untagged: redis:alpine
Untagged: redis@sha256:f1ed3708f538b537eb9c2a7dd50dc90a706f7debd7e1196c9264edeea521a86
d
Deleted: sha256:501ad78535f015d88872e13fa87a828425117e3d28075d0c117932b05bf189b7
Deleted: sha256:96167737e29ca8e9d74982ef2a0dda76ed7b430da55e321c071f0dbff8c2899b
Deleted: sha256:32770d1dcf835f192cafd6b9263b7b597a1778a403a109e2cc2ee866f74adf23
Deleted: sha256:127227698ad74a5846ff5153475e03439d96d4b1c7f2a449c7a826ef74a2d2fa
Deleted: sha256:1333ecc582459bac54e1437335c0816bc17634e131ea0cc48daa27d32c75eab3
Deleted: sha256:4fc455b921edf9c4aea207c51ab39b10b06540c8b4825ba57b3feed1668fa7c7
我们也可以用 镜像名
,也就是 <仓库名>:<标签>
,来删除镜像。
$ docker image rm centos
Untagged: centos:latest
Untagged: centos@sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d36
6c
Deleted: sha256:0584b3d2cf6d235ee310cf14b54667d889887b838d3f3d3033acd70fc3c48b8a
Deleted: sha256:97ca462ad9eeae25941546209454496e1d66749d53dfa2ee32bf1faabd239d38
当然,更精确的是使用 镜像摘要
删除镜像。
$ docker image ls --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
node slim sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228 6e0c4c8e3913 3 weeks ago 214 MB
$ docker image rm node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
Untagged: node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
如果观察上面这几个命令的运行输出信息的话,你会注意到删除行为分为两类,一类是 Untagged
,另一类是 Deleted
。我们之前介绍过,镜像的唯一标识是其 ID 和摘要,而一个 镜像可以有多个标签。
因此当我们使用上面命令删除镜像的时候,实际上是在要求删除某个标签的镜像。
所以首先 需要做的是将满足我们要求的所有镜像标签都取消,这就是我们看到的 Untagged
的信息。
因为一个镜像可以对应多个标签,因此当我们删除了所指定的标签后,可能还有别的标签指向了这个镜像,如果是这种情况,那么 Delete
行为就不会发生。所以并非所有的 docker rmi
都会产生删除镜像的行为,有可能仅仅是取消了某个标签而已。当该镜像所有的标签都被取消了,该镜像很可能会失去了存在的意义,因此会触发删除行为。
镜像是多层存储结构,因此在删除的时候也是从上层向基础层方向依次进行判断删除。 镜像的多层结构让镜像复用变动非常容易,因此很有可能 某个其它镜像 正依赖于 当前镜像的某一层。这种情况,依旧不会触发删除该层的行为。直到没有任何层依赖当前层时,才会真实的删除当前层。
这就是为什么,有时候会奇怪,为什么明明没有别的标签指向这个镜像, 但是它还是存在的原因,也是为什么有时候会发现所删除的层数和自己 docker pull
看到的 层数不一样的原因。(没理解)
除了镜像依赖以外,还需要注意的是容器对镜像的依赖。如果有用这个镜像启动的容器存在 (即使容器没有运行),那么同样不可以删除这个镜像。之前讲过,容器是以镜像为基础,再加一层容器存储层,组成这样的多层存储结构去运行的。因此该镜像如果被这个容器所依赖的,那么删除必然会导致故障。如果这些容器是不需要的,应该先将它们删除,然后再来删除镜像。
像其它可以承接多个实体的命令一样,可以使用 docker image ls -q
来配合使用 docker image rm
,这样可以成批的删除希望删除的镜像。我们在列出镜像章节介绍过很多过滤镜像列表的方式都可以拿过来使用。
比如,我们需要删除所有仓库名为 redis
的镜像:
$ docker image rm $(docker image ls -q redis)
或者删除所有在 mongo:3.2 之前的镜像:
$ docker image rm $(docker image ls -q -filter before=mongo:3.2)
充分利用你的想象力和 Linux 命令行的强大,你可以完成很多非常赞的功能。
注意:
docker commit
命令除了学习之外,还有一些特殊的应用场合,比如被入侵后保存现 场等。但是,不要使用docker commit
定制镜像,定制镜像应该使用Dockerfile
来完成。如果你想要定制镜像请查看Dockerfile。
镜像是容器的基础,每次执行 docker run
的时候都会指定哪个镜像作为容器运行的基础。
在之前的例子中,我们所使用的都是来自于 Docker Hub
的镜像。直接使用这些镜像是可以满足一定的需求,而当这些镜像无法直接满足需求时,我们就需要定制这些镜像。接下来的几节就将讲解如何定制镜像。
回顾一下之前学到的知识,镜像是多层存储,每一层是在前一层的基础上进行的修改; 而容器同样也是多层存储,是在以镜像为基础层,在其基础上加一层作为容器运行时的存储层。
现在以定制一个 Web 服务器为例子,来讲解镜像是如何构建的。
$ docker run --rm --name webserver -d -p 80:80 nginx
-p
: 指定端口映射,格式为:主机(宿主)端口:容器端口。-d
: 后台运行容器,并返回容器ID;--name=""
: 为容器指定一个名称;这条命令会用 nginx 镜像启动一个容器,命名为 webserver
,并且映射了 80
端口,这样我们可以用浏览器去访问这个 nginx 服务器(http://主机ip 即可)。
直接用浏览器访问的话,我们会看到默认的 Nginx 欢迎页面。
现在,假设我们非常不喜欢这个欢迎页面,我们希望改成欢迎 Docker 的文字,我们可以使用 docker exec
命令进入容器,修改其内容。
$ docker exec -it webserver bash
root@1323f3676fc3:/# echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
root@1323f3676fc3:/# exit
我们以交互式终端方式进入 webserver 容器,并执行了 bash 命令,也就是获得一个可操作的Shell。
然后,我们用 <<h1>Hello, Docker!</h1>
覆盖了 /usr/share/nginx/html/index.html
的内容。
现在我们再刷新浏览器的话,会发现内容被改变了。
我们修改了容器的文件,也就是改动了容器的存储层。我们可以通过 docker diff 命令看到 具体的改动。
$ docker diff webserver
C /root
A /root/.bash_history
C /var
C /var/cache
C /var/cache/nginx
A /var/cache/nginx/fastcgi_temp
A /var/cache/nginx/proxy_temp
A /var/cache/nginx/scgi_temp
A /var/cache/nginx/uwsgi_temp
A /var/cache/nginx/client_temp
C /run
A /run/nginx.pid
C /etc
C /etc/nginx
C /etc/nginx/conf.d
C /etc/nginx/conf.d/default.conf
C /usr
C /usr/share
C /usr/share/nginx
C /usr/share/nginx/html
C /usr/share/nginx/html/index.html
现在我们定制好了变化,我们希望能将其保存下来形成镜像。
要知道,当我们运行一个容器的时候(如果不使用卷的话),我们做的任何文件修改都会被记录于容器存储层里。而 Docker 提供了一个 docker commit
命令,可以将容器的存储层保存下来成为镜像。换句话说,就是在原有镜像的基础上,再叠加上容器的存储层,并构成新的镜像。以后我们运行这个新镜像的时候,就会拥有原有容器最后的文件变化。
docker commit
的语法格式为:
$ docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]
我们可以用下面的命令将容器保存为镜像:
$ docker commit --author 'hyy' --message '修改了默认网页' webserver nginx:v2
sha256:07e33465974800ce65751acc279adc6ed2dc5ed4e0838f8b86f0c87aa1795214
--author
:是指定修改的作者--message
:则是记录本次修改的内容和 git
版本控制相似,不过这里这些信息可以省略留空。
我们可以在 docker image ls
中看到这个新定制的镜像。
docker image ls nginx
我们还可以用 docker history
具体查看镜像内的历史记录,如果比较 nginx:latest 的历史 记录,我们会发现新增了我们刚刚提交的这一层。
$ docker history ngigx:v2
IMAGE CREATED CREATED BY SIZE COMMENT
07e334659748 54 seconds ago nginx -g daemon off; 95 B 修改了默认网页
...
新的镜像定制好后,我们可以来运行这个镜像。
$ docker run --name webserver2 -d -p 81:80 nginx:v2
访问 http://主机ip:81 就可以看到刚才修改后的页面了。
至此,我们第一次完成了定制镜像,使用的是 docker commit 命令,手动操作给旧的镜像添 加了新的一层,形成新的镜像,对镜像多层存储应该有了更直观的感觉。
使用 docker commit 命令虽然可以比较直观的帮助理解镜像分层存储的概念,但是实际环境 中并不会这样使用。
首先,如果仔细观察之前的 docker diff webserver
的结果,你会发现除了真正想要修改的 /usr/share/nginx/html/index.html
文件外,由于命令的执行,还有很多文件被改动或添加了。
这还仅仅是最简单的操作,如果是安装软件包、编译构建,那会有大量的无关内容被添 加进来,如果不小心清理,将会导致镜像极为臃肿。
此外,使用 docker commit
意味着所有对镜像的操作都是黑箱操作,生成的镜像也被称为黑 箱镜像,换句话说,就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像,别人根本无从得知。而且,即使是这个制作镜像的人,过一段时间后也无法记清具体在操作的。虽然 docker diff
或许可以告诉得到一些线索,但是远远不到可以确保生成一致镜像的地步。 这种黑箱镜像的维护工作是非常痛苦的。
而且,回顾之前提及的镜像所使用的分层存储的概念,除当前层外,之前的每一层都是不会发生改变的,换句话说,任何修改的结果仅仅是 在当前层进行标记、添加、修改,而不会改动上一层。如果使用 docker commit 制作镜像,以及后期修改的话,每一次修改都会让镜像 更加臃肿一次,所删除的上一层的东西并不会丢失,会一直如影随形的跟着这个镜像,即使 根本无法访问到。这会让镜像更加臃肿。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。