Kylin V10 ARM架构下Docker镜像下载与容器部署实战指南

1. 项目概述与需求拆解

1.1 这个项目到底在解决什么问题

先说背景。很多团队在国产化替代路上都会碰到一个很实际的问题：手头有一批基于ARM架构的国产服务器，系统装的是Kylin V10，想要在上面跑容器化应用，结果去Docker Hub上拉镜像，要么架构对不上，要么拉到的是x86版本，跑起来直接报exec format error。这种坑，踩过的人都懂。

那这个“kylinV10 arm docker镜像下载”的项目，核心就是解决三件事：第一，搞清楚Kylin V10 ARM版到底该怎么用Docker；第二，找到能在这个系统上正常运行的容器镜像；第三，把镜像下载、导入、运行这一整套流程跑通，让应用能稳定落地。

很多人会误以为这就是“拉个镜像”这么简单，但实际上里面藏着一堆细节。比如Kylin V10的版本差异、ARM架构下镜像的兼容性、Docker和Podman的选择、镜像源的可达性、离线环境的处理方式，每一项都能单独写一篇排坑指南。我们这篇文章就是要把这些点全部摊开来讲，让无论是刚接触国产系统的同学，还是已经在生产环境里摸爬滚打的运维老手，都能直接照着操作。

1.2 适合谁看，能拿到什么

这篇文章主要面向三类人。

第一类是正在做国产化适配的开发者，手上有Kylin V10 ARM服务器，想把现有的微服务或中间件容器化部署上去，但不知道该从哪里找镜像、怎么处理架构差异。

第二类是运维工程师，需要在内网环境或离线环境下搭建容器运行环境，需要提前把镜像准备好，或者搭一个私有的镜像仓库供集群使用。

第三类是技术选型阶段的架构师，在评估国产化技术栈时，需要确认Kylin V10 ARM环境下Docker生态是否成熟、有哪些坑、是否值得投入人力去做适配。

读完这篇文章，你能获得一套完整的操作路径：从确认硬件和系统版本，到安装和配置容器引擎，再到下载、导入、运行一个ARM架构镜像，最后还有常见问题的排查方法。整个过程都是我实际跑过之后整理出来的，不是抄官方文档，也不是凭空想象。

1.3 先说结论：这套方案稳不稳

我先给个结论，省得大家心里没底。Kylin V10 ARM架构下用Docker跑容器，是完全可行的。官方仓库里有专门针对ARM架构的镜像，常见的基础镜像如CentOS、Ubuntu、openEuler也都有ARM64版本，关键是要在拉取时明确指定平台参数，或者在本地做好架构验证。

另外一点很重要：Kylin V10本身基于CentOS技术路线发展而来，和CentOS 7/8的兼容性很好，所以很多CentOS生态的镜像可以直接用，但也有一些软件包依赖了特定内核特性，需要逐个验证。整体上，这个项目不需要从零造轮子，而是要把“选对镜像 + 正确导入 + 验证可运行”这个链路走通，我下面会一步步拆开讲。

2. 环境勘测与方案选型思路

2.1 先别急着装Docker，看清楚硬件和系统版本

很多人在这个项目上翻车，第一个原因就是没搞清楚自己的环境到底是什么。Kylin V10并不是只有一个版本，它分为桌面版和服务器版，还可能有不同的SP小版本。虽然大多数场景下Docker的安装方式差不多，但不同内核版本对容器运行时的支持有细微差异，特别是在老版本内核上跑新版本Docker，可能会遇到存储驱动不兼容、iptables规则异常等问题。

所以动手之前，我习惯先执行三步检查。

第一步，确认CPU架构。在终端里运行：

bash复制uname -m

输出如果是aarch64，说明是ARM 64位架构，这个就是我们项目的前提条件。如果输出是x86_64，那整篇文章的很多操作就不太适用了，你的场景其实是另一套逻辑。

第二步，确认系统版本。运行：

bash复制cat /etc/kylin-release

我这里实际环境输出的是Kylin V10 SP1，内核版本是4.19.90-24.4.v2101.ky10.aarch64。不同SP版本在软件源配置和内核参数上会有细微差别，但整体操作思路一致。

第三步，确认是否有残留的旧版本容器引擎。Kylin V10默认可能自带了一个旧版docker或者podman，如果直接装新版docker，端口、存储目录、systemd服务可能会冲突。

bash复制which docker
which podman
systemctl status docker

如果发现已经有旧版本，建议先停掉服务并卸载干净，再开始我们的安装流程。这一步很多人会跳过，结果后面启动容器时遇到各种诡异问题，排查半天发现是旧配置文件在捣鬼。

2.2 Docker和Podman怎么选

Kylin V10的软件源里其实同时有docker和podman，官方默认推荐的是podman，因为它在无守护进程、安全性、兼容OCI标准方面有优势。但如果你以前的工作流都是基于docker命令行习惯的，比如习惯了docker-compose编排、习惯了docker exec进入容器，那直接用Docker会更顺手。

我个人的选择是：生产环境稳定优先，用社区版Docker。原因有三点。第一，Docker生态成熟，不管是在线拉取还是离线导入，参考资料多，遇到问题容易搜到解决方案。第二，Kylin V10 ARM版的Docker适配已经做得比较完善，装了就能用，不需要额外配置复杂的权限和映射。第三，大多数团队现有的CI/CD脚本都是围绕Docker写的，换podman虽然命令兼容大部分，但还是会碰到一些边缘差异，没必要增加维护成本。

当然，如果你的环境对安全要求特别高，或者不允许常驻守护进程，那Podman是你更好的选择。我这篇文章以Docker为主线，但后面会提到Podman的兼容操作。

2.3 镜像从哪来：官方仓库还是第三方源

这是整个项目最关键的一步。Kylin V10 ARM环境可以直接访问互联网的话，优先从官方仓库拉取镜像，这是最稳妥的方案。但需要注意，Docker Hub上并非所有镜像都提供了ARM版本。比如有些个人维护的镜像只编译了amd64，你拉下来跑就会报exec format error。

为了避免这种问题，有几个经验可以分享。

第一，基础镜像优先选择官方镜像。比如ubuntu、centos、alpine、openEuler、kylin，这些主流镜像都有arm64版本，拉取时docker会自动匹配当前架构。第二，如果是从第三方仓库拉取，比如一些国产软件镜像，最好先看一下镜像的manifest文件，确认是否包含linux/arm64这个平台。第三，Kylin官方也维护了一个容器镜像仓库，里面提供了很多适配好Kylin V10的镜像，这个在第五节会展开讲。

另外，还有一类特殊场景是内网离线环境。如果服务器不能访问外网，就需要在能联网的机器上先把镜像拉下来，导出成tar包，再拷贝到目标机器上通过docker load导入。这个过程有版本差异、架构差异、压缩格式等多个坑，我后面会用一整节来演示。

2.4 架构差异：为什么x86镜像不能在ARM上跑

这个项目里最绕不开的基础概念就是CPU架构。我用一个生活化的类比来解释。

你有一台ARM服务器，相当于一个说中文的人；你从Docker Hub拉一个x86镜像，相当于拿到一本英文书。这个人不是看不懂，而是压根没法用中文的语法去朗读英文书，因为底层指令集完全不同。

CPU架构决定了机器能执行的机器码指令集合。x86_64和aarch64是两种完全不同的指令集，容器镜像里包含了编译好的二进制文件，这些文件是特定架构的，换一个架构就无法执行。虽然容器技术看起来是跨环境的，但它跨的是操作系统和软件环境，跨不了CPU指令集这个物理层。

那怎么确认一个镜像是否支持ARM架构呢？如果你在ARM机器上直接拉镜像，Docker会根据节点的系统架构自动选择匹配的镜像版本，但前提是镜像的manifest里有arm64的条目。如果你在x86机器上为ARM准备镜像，则需要显式指定--platform linux/arm64，否则默认拉下来的还是x86版本。

3. 在Kylin V10 ARM上完整安装Docker引擎

3.1 离线环境怎么处理依赖包

如果你的服务器能上网，那直接配置软件源安装就行，很简单。但很多国产化服务器是部署在内网机房的，无法访问互联网。这时候就需要在能联网的环境中下载好依赖包和docker rpm包，再拷贝进去安装。

这里有个很重要的细节：一定要在ARM架构的机器上下载依赖。如果你拿一台x86的电脑去下载rpm包，下载下来的docker-ce虽然文件名一样，但架构不对，装不上。正确做法是，在ARM机器上配置软件源后，用yumdownloader工具把所有依赖包下载到一个目录，再拷贝到离线环境。

具体操作我建议这样走。

首先，在一台能联网的Kylin V10 ARM机器上，配置好官方源，然后创建一个目录来存放所有rpm包：

bash复制mkdir /root/docker-rpms
yumdownloader --resolve --destdir=/root/docker-rpms docker-ce docker-ce-cli containerd.io docker-compose-plugin

--resolve参数非常关键，它会把所有依赖包一并下载下来，避免离线安装时缺依赖。如果你用的发行版没有yumdownloader，需要先安装yum-utils：

bash复制yum install -y yum-utils

下载完后，把整个/root/docker-rpms目录打包，拷贝到离线服务器上，然后执行：

bash复制cd /root/docker-rpms
rpm -ivh *.rpm

这一步常见的问题是有多个版本的相同依赖包，比如container-selinux出现两个版本，rpm会报冲突。解决办法是用rpm -Uvh *.rpm --force强制升级，但不到万不得已不要用--force，因为可能破坏系统其他组件的依赖关系。

3.2 在线安装：两行命令快速搞定

如果是能联网的环境，安装其实很快。Kylin V10的软件源中集成了docker相关的包，但版本可能不是最新的。为了获取更新的版本和更好的ARM支持，我一般直接用阿里云镜像站或者docker官方源来安装。

先配置docker的yum源，这里以阿里云源为例：

bash复制yum install -y yum-utils
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

注意，这个repo文件里默认的baseurl是x86_64的，我们需要检查一下是否支持aarch64。新版本的docker-ce.repo里通常已经包含aarch64的路径，如果找不到，可以手动修改repo文件，把$basearch自动替换成aarch64。

然后检查软件源里的包列表：

bash复制yum list docker-ce --showduplicates

如果能看到docker-ce的多个版本，说明源配置成功。接下来直接安装：

bash复制yum install -y docker-ce docker-ce-cli containerd.io

安装完成后，先不要急着启动。建议先调整一下Docker的配置，特别是存储驱动和日志参数，具体配置我放在3.4节。启动服务并设置开机自启：

bash复制systemctl enable --now docker
docker version

如果docker version能够正常输出Client和Server的版本信息，说明daemon已经正常运行。这里有个容易踩的坑：如果只显示Client版本，而Server部分报错，多半是daemon启动失败，需要去看systemctl status docker的具体报错。

3.3 环境初始化：存储驱动、日志和镜像仓库地址

Docker装好后，默认配置不一定最适合Kylin V10 ARM。我建议创建一个配置文件，提前把关键参数都设置好。

创建/etc/docker/daemon.json，内容如下：

json复制{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "registry-mirrors": [
    "https://docker.m.daocloud.io"
  ]
}

重点解释三个参数。

native.cgroupdriver=systemd：Kylin V10的init系统是systemd，Docker默认的cgroup driver是cgroupfs。如果之后要对接Kubernetes，kubelet会要求使用systemd作为cgroup driver，提前统一配置能避免后续冲突。

storage-driver：overlay2是当前Linux环境下的首选存储驱动，性能好，稳定性高。如果默认环境不支持overlay2，Docker启动时会报错，可以在文件里改为vfs，但vfs性能较差，不建议生产使用。

registry-mirrors：这是镜像加速地址。在国内访问Docker Hub经常超时，配置一个加速器能明显提升拉取速度。不同加速器的稳定性有波动，我这里写了一个常见的，建议多用两个备用。

配置完之后，重启Docker：

bash复制systemctl restart docker
docker info

在docker info输出中，检查Storage Driver: overlay2和Cgroup Driver: systemd，确认配置都生效了再继续。

3.4 网络与防火墙问题

在很多服务器环境里，Docker容器启动后，外部访问不到容器端口。这个问题通常和firewalld或者systemctl的iptables规则有关。

Kylin V10默认启用了firewalld。如果容器需要对外提供服务，需要在防火墙里放行对应的端口。比如要暴露容器的8080端口，执行：

bash复制firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

但有时候明明放行了端口还是访问不到，这时候就要检查Docker的iptables规则是否被firewalld覆盖了。有一个简单粗暴的办法，就是直接禁用firewalld，让Docker自己管理iptables链：

bash复制systemctl disable --now firewalld

这个方案适合内部测试环境。生产环境建议按照实际端口逐个放行，不要直接关闭防火墙，因为可能影响其他服务的合规要求。

另外，如果系统还装了nftables，Docker和nftables之间的兼容性有时会有问题。遇到这种情况，建议统一使用iptables-nft，或者调整nftables规则放行Docker的网桥流量。

4. 下载ARM架构Docker镜像的实操细节

4.1 在线拉取时如何确保用到arm64版本

这是很多人最迷惑的地方：为什么我在ARM机器上拉镜像，拉下来的还是跑不了？

原因在于Docker的拉取策略。当你执行docker pull ubuntu:latest时，如果没有显式指定平台，Docker会根据执行拉取操作的主机架构来自动选择匹配的变体。如果你的机器是aarch64，拉到的一般就是arm64版本。但有的镜像只提供了amd64版本，Docker也会拉取成功，因为它不做强制架构校验，只有在你运行容器的时候才会因为无法执行而报错。

所以，为了万无一失，我建议在拉取时显式指定平台参数：

bash复制docker pull --platform linux/arm64 ubuntu:20.04

这样即使你的机器是x86架构（比如为ARM机器准备镜像），也能强制拉取ARM版本。

拉取下来后，可以用docker image inspect来验证一下镜像架构：

bash复制docker image inspect ubuntu:20.04 | jq '.[0].Architecture'

输出应该是arm64。如果输出的不是arm64，说明拉取镜像时并没有按ARM架构下载，需要删掉重新指定平台拉取。

4.2 最稳的镜像源：Kylin官方的容器仓库

除了Docker Hub，Kylin官方也提供了容器镜像仓库，里面的镜像针对Kylin V10做了适配，比如kylinsoft、kylin-server等基础镜像，在兼容性和稳定性上更有保障。这个仓库的地址在ARM服务器上可以直接访问，拉取方式和普通Docker Hub一样。

以拉取Kylin基础镜像为例：

bash复制docker pull kylinsoft/kylin-server:v10

拉取成功后，运行一个简单的容器测试：

bash复制docker run -it --rm kylinsoft/kylin-server:v10 /bin/bash

进入到容器内部后，执行cat /etc/kylin-release，能看到Kylin的版本信息，说明容器能够正常使用系统级资源。

这里有人会问：既然Kylin V10是基于CentOS的，那我直接用CentOS镜像不就行了吗？理论上是可以的，但实际会有一些小问题。比如有些基础工具链的版本差异、软件源配置指向不同、部分内核模块在容器内不可用等。用Kylin官方镜像可以少踩这些坑，尤其是如果你后续要在容器里编译和运行与国产化相关的软件包，官方镜像的兼容性会好很多。

4.3 离线下载与导入的完整流程

很多生产环境不允许直接访问外网，所以离线下载是必须掌握的技能。整个流程分三步：在一台能联网的机器上拉取镜像，导出成tar文件；把tar文件拷贝到目标机器；在目标机器上导入并运行。

先看第一步，在联网的ARM机器上拉取并导出：

bash复制docker pull --platform linux/arm64 ubuntu:20.04
docker save -o ubuntu-20.04-arm64.tar ubuntu:20.04

docker save -o会把镜像的所有层和元数据打包成一个tar文件，这个文件比镜像实际大小要大一点，因为包含了完整的layer信息和manifest。如果你要跨机器传输，推荐先用gzip压缩：

bash复制gzip ubuntu-20.04-arm64.tar

你会得到一个ubuntu-20.04-arm64.tar.gz，通常能压缩掉30%到50%的体积。然后把压缩包拷贝到目标服务器，执行：

bash复制gunzip ubuntu-20.04-arm64.tar.gz
docker load -i ubuntu-20.04-arm64.tar

docker load会把镜像导入到本地镜像库中。导入后，用docker images确认镜像是否存在，然后用docker run测试运行。

这个流程有几个关键点需要提醒。第一，docker save和docker export完全不同，save保留镜像的历史和元数据，适合后续load后继续用这个镜像创建容器；而export是把运行中的容器导出成文件系统快照，导入后不再是镜像，不能保留CMD和ENTRYPOINT等信息。第二，一定要确认导出和导入机器的架构一致，否则导入后虽然能load，但运行时会报错。第三，tar包里的镜像如果带有私有仓库的tag，比如myrepo.com/ubuntu:20.04，导入后tag还是带域名的，重新打一个本地tag会更方便。

本地重新打tag操作：

bash复制docker tag myrepo.com/ubuntu:20.04 ubuntu:20.04

这样后续使用就不用带那一长串前缀了。

4.4 镜像验证：不能只看能run，还要看能不能用

很多人在ARM镜像上下载上栽跟头，不是镜像不能用，而是容器能启动但软件运行报错。比如在ARM环境下用某些原生x86编译的软件，容器能启动，但一执行./app就提示cannot execute binary file: Exec format error。

所以验证一个镜像是否真正可用，不能只停在docker run这一步，还要进入容器内部，执行实际的应用命令。

举一个我常用的验证清单：

1. 基础环境是否正常：cat /etc/os-release。
2. 能否执行系统命令：which curl、which gcc。
3. 能否安装软件包：apt update && apt install -y vim（不同系统软件包管理器不同）。
4. 能否运行CPU密集型命令：执行一个简单的nproc、lscpu，看看容器内的CPU数量和架构是否正确。

如果这些都正常，说明镜像整体可用。如果你要做的是交叉编译或者涉及底层指令集的操作，还需要进一步验证指定软件是否在镜像里有ARM版本，因为有些软件发布时只提供了x86二进制，比如某些闭源的SDK、数据库客户端，这些需要单独去查官方支持列表。

5. 实操案例：从零部署一个ARM版Nginx容器

5.1 选镜像和准备目录

为了更贴近实际使用，我以一个非常常见的场景来演示：在Kylin V10 ARM服务器上，用Docker跑一个Nginx容器，并让外部主机访问到它的默认页面。

首先，确定使用官方nginx镜像，并指定ARM平台：

bash复制docker pull --platform linux/arm64 nginx:1.24-alpine

选择alpine版本有几个好处：镜像体积小，只有几十MB；安全漏洞少；启动速度快。生产环境如果要部署Nginx，alpine是首选。

然后，在宿主机上准备一个目录，用来存放Nginx的配置文件和静态资源。我习惯把配置和网页内容都挂载到宿主机上，这样改配置不用重新构建镜像：

bash复制mkdir -p /data/nginx/{conf,html}
cd /data/nginx

在html目录下创建一个最简单的index.html：

html复制<!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>Kylin ARM Nginx</title></head>
<body>
<h1>Nginx is running on Kylin V10 ARM64</h1>
</body>
</html>

5.2 启动容器的参数说明

启动容器的命令如下：

bash复制docker run -d \
  --name kylin-nginx \
  -p 8080:80 \
  -v /data/nginx/html:/usr/share/nginx/html:ro \
  -v /data/nginx/conf:/etc/nginx/conf.d:ro \
  --restart=always \
  nginx:1.24-alpine

逐项解释一下这些参数，因为很多新手不理解挂载和端口映射的关系。

-d：后台运行容器，不阻塞当前终端。

--name kylin-nginx：给容器起一个可识别的名字，后续用docker logs kylin-nginx查看日志时比较直观。

-p 8080:80：把宿主机的8080端口映射到容器的80端口。这样外部访问http://服务器IP:8080时，请求会转发到容器内的Nginx端口。

-v /data/nginx/html:/usr/share/nginx/html:ro：把宿主机上的html目录挂载到容器内Nginx的默认网页目录，ro表示只读，防止容器内部误改文件。这样做的好处是以后改网页内容，直接改宿主机的文件，容器无需重启。

-v /data/nginx/conf:/etc/nginx/conf.d:ro：同理，把宿主的配置目录挂载到容器的扩展配置目录。Nginx主配置文件一般不会动，扩展配置可以按站点添加。

--restart=always：容器异常退出时自动重启。如果服务器重启了，Docker服务启动后也会自动启动这个容器。这一点对于生产环境的服务稳定性来说很重要。

启动后，用docker ps查看容器状态，应该能看到Up状态。再访问一次页面验证：

bash复制curl http://127.0.0.1:8080

如果能看到我们预设的那行Nginx is running on Kylin V10 ARM64，说明整个链路已经跑通了。

5.3 提交修改后的镜像

日常使用中，我们经常会在容器里做一些临时调整，比如安装额外的工具、改配置文件等。如果后续想把这些修改固化成一个新镜像，可以用docker commit。

但我要提醒一下，docker commit不是生产环境推荐的做法，因为它会丢失构建历史，镜像不透明，难以复现。更好的做法是用Dockerfile定义好所有步骤，重新构建。不过在某些快速验证场景下，commit确实方便。

举个例子，在刚才的Nginx容器里安装curl：

bash复制docker exec -it kylin-nginx apk add curl
docker commit kylin-nginx mynginx:with-curl

这样mynginx:with-curl就包含已经装好的curl。但如果你后续要用docker compose或k8s来管理，这种临时镜像会导致环境不可控，建议还是用Dockerfile来构建。

6. 常见问题与排查技巧实录

6.1 容器启动报“exec format error”怎么办

这个问题可以说是ARM容器场景中最常见、最典型的一个。报错信息通常是：

text复制standard_init_linux.go:228: exec user process caused: exec format error

含义是容器启动时执行那个二进制文件，但当前系统的CPU架构不认这个文件的指令集。排查思路分三步。

第一步，确认宿主机的架构：

bash复制uname -m

第二步，确认镜像的架构：

bash复制docker image inspect <镜像名> | grep Architecture

如果宿主机是aarch64，而镜像的Architecture是amd64，那这个镜像就是错了。需要删除镜像，重新拉取arm64版本。

第三步，检查镜像入口文件是否正常。有时候镜像本身是arm64的，但入口脚本或二进制是损坏的，也会报同样的错误。可以尝试覆盖入口文件启动看看：

bash复制docker run -it --entrypoint /bin/sh <镜像名>

如果能进入shell，说明镜像基本结构没问题，问题可能出在默认入口的二进制文件上。

6.2 镜像拉取慢或者超时

在内网或国内网络环境下，拉取Docker Hub上的镜像经常卡住。几个常用方法，按优先级排序。

第一，配置镜像加速器，我前面已经在daemon.json里写了一个。第二，使用代理加速，但这种方式在合规性和安全性上有风险，我不建议在缺乏必要基础设施时贸然尝试。第三，从其他源拉取替代镜像。

以nginx为例，如果Docker Hub超时，可以尝试从阿里云容器镜像服务找nginx，或者用腾讯云、华为云的镜像仓库。这些云厂商一般都做了arm64的支持，拉取速度也比较快。

还有一个技巧：如果只是测试，可以缩小镜像体积，用alpine版本，小镜像拉起来会快很多。生产环境也是一样，尽量用slim或alpine标签，减少带宽占用和启动时间。

6.3 Docker服务启动失败，排查日志的姿势

安装好Docker以后，systemctl start docker报错，这种情况多出现在离线安装或配置不当的情况下。排查的第一步是看服务状态：

bash复制systemctl status docker -l

-l参数很重要，避免日志被截断。然后看daemon日志：

bash复制journalctl -u docker --no-pager -n 100

常见的报错有几种：第一种是overlay2存储驱动不支持，可以临时改为vfs测试；第二种是iptables相关错误，多半是内核模块缺失或防火墙冲突，检查iptables -L能否正常执行；第三种是containerd版本和docker版本不匹配，离线安装时容易碰到，需要检查rpm包是否都来自同一个版本源。

我之前遇到过一种情况：systemctl start docker能启动，但一运行容器就出现mount权限错误，后来检查发现是SELinux处于enforcing模式。如果内网环境对安全要求不高，在保证策略合规的前提下，可以临时执行setenforce 0验证是否和SELinux有关。

6.4 排查速查表

我整理一个表，方便大家对照排查：

6.5 几个在实际工作中很管用的小操作

最后分享几个我常用的小操作，虽然不涉及复杂技术，但很能节约时间。

一键清理不再使用的镜像和容器：

bash复制docker system prune -a -f

注意这个命令会删除所有未运行的容器和未使用的镜像，如果有需要保留的镜像，先确认再执行。

查看容器内进程：

bash复制docker top <容器名>

在宿主机上直接查看容器占用的资源：

bash复制docker stats

这个命令适合长驻查看容器的CPU和内存使用率，定位容器资源瓶颈。

导出容器内部文件到宿主机，比如我在调试Nginx配置时经常需要把容器里的日志拷贝出来：

bash复制docker cp <容器名>:/var/log/nginx/access.log ./access.log

这些命令虽然基础，但实际运维过程中使用频率非常高，建议都熟练掌握。

7. 写在最后的一些个人经验

这个项目做到现在，我自己最大的体会是：国产化环境下，技术本身并不难，难的是那些“默认值和理想化假设”不成立的地方。比如你以为Docker Hub上的镜像都有ARM版本，结果实际拉下来跑不了；你以为离线环境只要把tar包拷过去就完事，结果忘了架构检查，白忙一场。每一步看起来都不复杂，但组合起来就能耗尽耐心。

如果让我总结三个最重要的经验，就是：第一，动手之前先确认架构和版本，所有后续操作的根基都在这里；第二，尽量选择官方或适配过的镜像，不要让应用从编译阶段开始就处在“试试看”的状态；第三，别把在线环境的一套照搬到离线环境，导出、传输、导入、验证，每一步都要有独立的确认动作。

后续如果大家要做更复杂的集群部署，可以考虑在Kylin V10 ARM上再部署一个私有的Harbor镜像仓库，把提前拉取好的镜像统一管理，这样各个节点就不用都去公网拉取，既解决了重复下载的问题，也便于内网环境的镜像版本控制。这个方向我后续也会继续整理，先把当前的基础流程跑顺，再逐步扩展。