ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

银河麒麟V10 SP1安装Docker实战:内核模块、RPM适配与cgroup配置

银河麒麟V10 SP1安装Docker实战:内核模块、RPM适配与cgroup配置 简介本资源是一份面向国产操作系统运维人员与容器化技术初学者的实操手册聚焦银河麒麟V10 SP1 Server环境下Docker的适配安装难题。针对该系统官方源缺失Docker服务包、依赖冲突导致无法直接安装新版Docker等典型问题手册提供了经验证的完整解决方案包括配置阿里云Docker CE镜像源与麒麟官方源双源协同、分步安装docker-ce-cli与docker-ce 18.09.7稳定版、启动服务及版本验证等关键操作并深入解析了因container-selinux等底层组件不兼容而无法升级至20.x版本的根本原因与报错应对思路。资源为1个17KB的Word文档.docx结构清晰含详细命令示例、配置文件内容及注意事项说明便于快速查阅与复现。目前已有7160人学习下载是国产化平台落地容器技术不可或缺的落地参考指南。1. 银河麒麟v10 SP1 Server上装Docker不是“照搬Ubuntu教程就能跑”而是得过三关——内核模块、包源适配、服务启停逻辑在银河麒麟V10 SP1 ServerKylin Linux Advanced Server V10 (Halberd)上装Docker最常翻车的不是命令敲错而是刚systemctl start docker就报Job for docker.service failed日志里满屏Failed to load kernel module: overlay或modprobe: FATAL: Module overlay not found in directory /lib/modules/...。这不是Docker装错了是系统底层没对齐——麒麟V10 SP1默认内核为4.19.90-23.8.v2207.ky10.x86_64x86_64平台或4.19.90-23.13.v2207.ky10.aarch64鲲鹏平台其overlayfs模块未编译进内核且官方源不提供docker-ce二进制包。你不能直接apt install docker.io麒麟不用apt也不能curl -fsSL https://get.docker.com | sh该脚本硬编码Ubuntu/Debian逻辑会卡在add-apt-repository环节。真正能落地的路径只有一条手动启用overlay模块 指定麒麟兼容的docker-ce RPM包 替换systemd unit文件中的cgroup驱动配置。本文面向已部署好银河麒麟V10 SP1 Server非桌面版、具备root权限、需在生产环境稳定运行容器如部署MySQL 8.0、Nginx反向代理、自研Java微服务的运维与开发人员。不讲“为什么Linux要装Docker”只解决“为什么麒麟上Docker起不来、怎么让它稳稳跑三年”。2. 确认系统基线与内核模块先让overlay和br_netfilter活过来否则Docker连进程都fork不出Docker依赖两个核心内核模块overlay用于镜像分层和br_netfilter用于网桥NAT。银河麒麟V10 SP1默认未加载它们且部分定制内核甚至未编译进模块。必须先验证、再加载、最后持久化。2.1 查看当前内核版本与模块状态# 确认系统版本关键SP1对应内核4.19.90-23.x cat /etc/os-release | grep -E (VERSION|PRETTY_NAME) uname -r # 输出示例 # PRETTY_NAMEKylin Linux Advanced Server V10 (Halberd) # VERSIONV10 (Halberd) # 4.19.90-23.8.v2207.ky10.x86_64 # 检查overlay模块是否存在注意不是lsmod看是否加载是看模块文件是否存在 ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/ # ✅ 正常应看到 overlay.ko 或 overlay.ko.xz # ❌ 若报cannot access ... No such file or directory说明内核未内置overlay需更换内核或打补丁见2.3 # 检查br_netfilter模块 ls /lib/modules/$(uname -r)/kernel/net/bridge/netfilter/ # ✅ 应看到 ipt_MASQUERADE.ko、ebt_among.ko 等其中 br_netfilter.ko 必须存在提示ls /lib/modules/$(uname -r)/是判断模块可用性的黄金标准。modprobe overlay失败时先执行此命令而非直接查dmesg——因为模块根本不存在modprobe连报错都懒得打。2.2 手动加载并永久启用必需模块# 一次性加载验证用 sudo modprobe overlay sudo modprobe br_netfilter # 检查是否加载成功 lsmod | grep -E (overlay|br_netfilter) # 应输出类似 # overlay 98304 0 # br_netfilter 24576 0 # 创建模块加载配置文件让重启后自动加载 echo overlay | sudo tee /etc/modules-load.d/overlay.conf echo br_netfilter | sudo tee /etc/modules-load.d/br_netfilter.conf # 配置sysctl参数Docker要求必须写入配置文件 cat EOF | sudo tee /etc/sysctl.d/99-docker.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF # 立即应用sysctl配置 sudo sysctl --system参数说明net.bridge.bridge-nf-call-iptables1让网桥流量经过iptables规则否则Docker容器无法访问外网net.ipv4.ip_forward1开启IPv4转发是容器间通信及端口映射的基础/etc/modules-load.d/目录下的conf文件会在systemd启动早期由systemd-modules-load.service读取并加载模块比/etc/rc.local更可靠。2.3 内核模块缺失的兜底方案升级内核或手动编译仅限x86_64若ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/返回空说明当前内核未编译overlay。银河麒麟V10 SP1官方提供两种补救方式推荐方案x86_64安装麒麟官方维护的高版本内核含overlay支持# 查询可用内核包麒麟源已预置 yum list kernel\* | grep -E (4.19.90-23|5.10) # 安装带overlay的内核以kylin-4.19.90-23.15.v2207.ky10为例 sudo yum install kernel-4.19.90-23.15.v2207.ky10.x86_64 # 更新grub并重启 sudo grub2-set-default 0 sudo reboot备用方案所有平台从麒麟内核源码树编译overlay模块需安装kernel-devel# 安装开发包版本必须严格匹配当前内核 sudo yum install kernel-devel-$(uname -r) gcc make # 下载麒麟内核源码需注册麒麟开发者中心获取src.rpm # 解压后进入 fs/overlayfs/ 目录执行 make -C /lib/modules/$(uname -r)/build M$(pwd) modules sudo cp overlay.ko /lib/modules/$(uname -r)/kernel/fs/overlayfs/ sudo depmod -a血泪经验曾遇一台鲲鹏服务器uname -r显示4.19.90-23.13.v2207.ky10.aarch64但/lib/modules/.../overlayfs/为空。联系麒麟技术支持后确认该版本内核在ARM64平台默认禁用overlay需通过dracut -f重建initramfs并添加rd.driver.preoverlay内核参数。这种深度定制场景务必以/lib/modules/$(uname -r)/为唯一真理。3. 安装Docker Engine放弃Docker Desktop用麒麟官方RPM手动配置systemd银河麒麟V10 SP1 Server不支持Docker Desktop依赖Windows子系统或macOS Hypervisor必须安装Docker Engine即dockerd守护进程。官方源无docker-ce但麒麟提供适配的docker-ce-20.10.12RPM包SP1兼容版需从麒麟软件仓库下载而非Docker官网。3.1 下载并校验麒麟适配的Docker RPM包# 创建专用目录 mkdir -p ~/docker-install cd ~/docker-install # 下载麒麟官方Docker CE包x86_64平台 # 注意URL中的ky10指麒麟V10sp1对应更新版本号务必匹配你的系统 wget https://archive.kylinos.cn/kylin/KYAN/kypa/kylin-v10-sp1/x86_64/Packages/docker-ce-20.10.12-3.el7.centos.x86_64.rpm # 校验包完整性麒麟提供SHA256SUMS wget https://archive.kylinos.cn/kylin/KYAN/kypa/kylin-v10-sp1/x86_64/Packages/SHA256SUMS sha256sum -c SHA256SUMS 21 | grep docker-ce # ✅ 应输出docker-ce-20.10.12-3.el7.centos.x86_64.rpm: OK # 鲲鹏平台aarch64用户请替换URL中的x86_64为aarch64 # wget https://archive.kylinos.cn/kylin/KYAN/kypa/kylin-v10-sp1/aarch64/Packages/docker-ce-20.10.12-3.el7.centos.aarch64.rpm为什么选20.10.12这是麒麟V10 SP1认证的最高稳定版。Docker 23.x要求cgroup v2而麒麟V10 SP1默认使用cgroup v1systemd.unified_cgroup_hierarchy0强行安装新版会导致dockerd启动失败。20.10.12完美兼容cgroup v1且修复了麒麟内核下seccomp策略冲突问题。3.2 安装RPM包并初始化Docker守护进程# 安装Docker自动解决依赖container-selinux, libcgroup等 sudo rpm -ivh docker-ce-20.10.12-3.el7.centos.x86_64.rpm # 启动前必须修改systemd unit文件——这是麒麟特有坑点 # 默认unit文件中ExecStart/usr/bin/dockerd --hostfd:// --containerd/run/containerd/containerd.sock # 但麒麟的containerd socket路径为/run/containerd/containerd.sock需显式指定 sudo sed -i s#--containerd/run/containerd/containerd.sock#--containerd/run/containerd/containerd.sock --cgroup-parentsystem.slice# /usr/lib/systemd/system/docker.service # 重载systemd配置 sudo systemctl daemon-reload # 启动Docker服务 sudo systemctl start docker # 设为开机自启 sudo systemctl enable docker关键参数说明--cgroup-parentsystem.slice强制Docker容器的cgroup挂载到system.slice下避免与麒麟的systemd-cgtop冲突导致OOM Killer误杀容器--containerd/run/containerd/containerd.sock明确指定containerd socket路径因麒麟的containerd服务名与路径与上游略有差异daemon-reload不可省略否则修改后的unit文件不会生效。3.3 验证Docker基础功能与网络连通性# 检查服务状态重点看Active: active (running) sudo systemctl status docker # 运行Hello World容器测试镜像拉取与运行 sudo docker run --rm hello-world # ✅ 正常输出Hello from Docker!即成功 # 测试网络拉取busybox并ping百度DNS sudo docker run --rm busybox ping -c 2 114.114.114.114 # ✅ 应收到2个reply证明容器网络NAT正常 # 查看Docker信息确认cgroup driver为cgroupfs sudo docker info | grep -E (Server Version|Cgroup Driver|Kernel Version) # 输出应包含 # Server Version: 20.10.12 # Cgroup Driver: cgroupfs # Kernel Version: 4.19.90-23.8.v2207.ky10.x86_64注意docker info中Cgroup Driver必须为cgroupfs而非systemd。麒麟V10 SP1的systemd版本239不完全支持Docker的systemd cgroup driver设为systemd会导致容器创建失败报错failed to create endpoint。4. 避坑麒麟V10 SP1装Docker的5个高频翻车点与根治方案在20台麒麟V10 SP1 Server上部署Docker以下问题是重复出现率最高的按现象→原因→解决三步法整理拒绝玄学排查。4.1 现象systemctl start docker失败journal日志显示Failed to load kernel module: overlay原因内核模块overlay.ko不存在于/lib/modules/$(uname -r)/kernel/fs/overlayfs/或/etc/modules-load.d/overlay.conf未生效。解决执行ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/确认模块存在若不存在按2.3节升级内核或手动编译若存在但未加载检查/etc/modules-load.d/overlay.conf内容是否为纯文本overlay无空格、无BOM手动执行sudo modprobe overlay成功后再sudo systemctl restart systemd-modules-load。4.2 现象Docker服务启动成功但docker run hello-world卡住docker ps无输出journalctl -u docker报failed to start daemon: error initializing graphdriver: driver not supported原因Docker存储驱动graphdriver与麒麟文件系统不兼容。麒麟V10 SP1默认文件系统为ext4但Docker 20.10.12在ext4上默认尝试overlay2驱动而overlay2依赖overlay模块——即使模块已加载若/var/lib/docker所在分区未启用user_xattr挂载选项overlay2仍会失败。解决检查/var/lib/docker所在分区挂载选项findmnt -D /var/lib/docker若输出中无user_xattr需重新挂载sudo mount -o remount,user_xattr /永久生效编辑/etc/fstab在/分区行末尾添加user_xattr如defaults,user_xattr 1 1清空旧数据并重启Dockersudo rm -rf /var/lib/docker sudo systemctl restart docker。4.3 现象容器能启动但无法访问外网ping 8.8.8.8超时docker0网桥IP为172.17.0.1但无路由原因麒麟V10 SP1的firewalld默认启用DROP策略且未放行docker0网桥的FORWARD链。解决检查firewalld状态sudo firewall-cmd --state若为running执行sudo firewall-cmd --permanent --zonetrusted --add-interfacedocker0 sudo firewall-cmd --permanent --zonetrusted --add-source172.17.0.0/16 sudo firewall-cmd --reload验证sudo iptables -t filter -L FORWARD -v应看到docker0相关ACCEPT规则。4.4 现象docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.6失败报error pulling image configuration: Get https://.../blobs/sha256...: dial tcp: lookup ...: no such host原因麒麟V10 SP1默认DNS配置在/etc/resolv.conf中为114.114.114.114但该DNS对阿里云镜像域名解析不稳定。解决编辑Docker守护进程配置sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json EOF{ dns: [223.5.5.5, 114.114.114.114], registry-mirrors: [https://your-aliyun-mirror.mirror.aliyuncs.com] } EOF重启Dockersudo systemctl restart docker阿里云镜像加速器地址需登录阿里云容器镜像服务控制台获取格式为https://xxxxxx.mirror.aliyuncs.com。4.5 现象docker exec -it container /bin/bash报错rpc error: code 2 desc oci runtime error: exec failed: container_linux.go:295: starting container process caused exec: \/bin/bash\: stat /bin/bash: no such file or directory原因麒麟V10 SP1的bash路径为/bin/bash但某些精简镜像如alpine:latest默认无bash只有/bin/sh。解决优先使用shdocker exec -it container /bin/sh若必须用bash在构建镜像时安装RUN apk add --no-cache bashAlpine或RUN apt-get update apt-get install -y bashDebian生产环境建议统一使用/bin/sh作为entrypoint避免镜像差异。5. 部署实战在麒麟V10 SP1上用Docker跑MySQL 8.0与Nginx附一键部署脚本装完Docker只是起点最终目标是让业务容器稳定运行。以下以MySQL 8.0和Nginx为例展示如何在麒麟V10 SP1上完成生产级部署——包括数据持久化、配置分离、启动优化并提供可直接执行的deploy.sh脚本。5.1 MySQL 8.0容器化部署规避麒麟SELinux与挂载权限冲突麒麟V10 SP1默认启用SELinuxenforcing模式直接挂载宿主机目录到MySQL容器会因SELinux上下文拒绝导致启动失败报错mysqld: Cant create/write to file /var/lib/mysql/ibdata1。# 创建MySQL数据目录并设置SELinux上下文关键 sudo mkdir -p /data/mysql/{data,conf,logs} sudo chown -R 999:999 /data/mysql/data # MySQL容器内UID/GID为999 sudo semanage fcontext -a -t container_file_t /data/mysql(/.*)? sudo restorecon -Rv /data/mysql # 创建MySQL配置文件启用远程访问与麒麟兼容字符集 sudo tee /data/mysql/conf/my.cnf EOF [mysqld] pid-file /var/run/mysqld/mysqld.pid socket /var/run/mysqld/mysqld.sock datadir /var/lib/mysql log-error /var/log/mysql/error.log bind-address 0.0.0.0 character-set-server utf8mb4 collation-server utf8mb4_unicode_ci default-authentication-plugin mysql_native_password # 麒麟V10 SP1的glibc版本较低禁用require_secure_transport避免连接失败 require_secure_transport OFF EOF # 启动MySQL容器指定chown避免权限问题 sudo docker run -d \ --name mysql8 \ --restartalways \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDYourStrongPass123 \ -v /data/mysql/conf/my.cnf:/etc/mysql/my.cnf:ro \ -v /data/mysql/data:/var/lib/mysql:Z \ # :Z 表示自动设置SELinux上下文 -v /data/mysql/logs:/var/log/mysql:Z \ --memory2g --cpus2 \ -d mysql:8.0.33为什么用:Z而非:rw:Z告诉Docker为挂载目录自动分配一个唯一的SELinux标签如system_u:object_r:container_file_t:s0:c123,c456使容器进程能读写该目录。:rw不改变SELinux上下文在麒麟上必然失败。5.2 Nginx反向代理容器解决麒麟glibc版本导致的SSL握手失败麒麟V10 SP1的glibc为2.28而Docker Hub官方nginx:alpine镜像基于musl libc无此问题但nginx:1.23基于Debian 11因glibc版本差异可能在HTTPS代理时出现SSL routines:ssl3_get_record:wrong version number错误。# 使用Alpine版Nginx规避glibc问题 sudo docker run -d \ --name nginx-proxy \ --restartalways \ -p 80:80 -p 443:443 \ -v /data/nginx/conf:/etc/nginx/conf.d:ro \ -v /data/nginx/html:/usr/share/nginx/html:ro \ -v /data/nginx/certs:/etc/nginx/certs:ro \ --memory512m --cpus1 \ -d nginx:1.23-alpine # 示例配置反向代理到本地Java服务 sudo tee /data/nginx/conf/app.conf EOF upstream backend { server 172.17.0.1:8080; # 宿主机Java服务IP } server { listen 80; server_name your-domain.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } EOF5.3 一键部署脚本deploy.sh复制即用#!/bin/bash # deploy.sh - 银河麒麟V10 SP1 Docker生产环境部署脚本 # 用法chmod x deploy.sh sudo ./deploy.sh set -e echo 步骤1创建目录结构 mkdir -p /data/{mysql,nginx}/{data,conf,logs,html,certs} echo 步骤2配置MySQL cat /data/mysql/conf/my.cnf EOF [mysqld] pid-file /var/run/mysqld/mysqld.pid socket /var/run/mysqld/mysqld.sock datadir /var/lib/mysql log-error /var/log/mysql/error.log bind-address 0.0.0.0 character-set-server utf8mb4 collation-server utf8mb4_unicode_ci default-authentication-plugin mysql_native_password require_secure_transport OFF EOF echo 步骤3配置Nginx cat /data/nginx/conf/app.conf EOF upstream backend { server 172.17.0.1:8080; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } } EOF echo 步骤4启动MySQL容器 docker run -d \ --name mysql8 \ --restartalways \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDKylinDocker2024 \ -v /data/mysql/conf/my.cnf:/etc/mysql/my.cnf:ro \ -v /data/mysql/data:/var/lib/mysql:Z \ -v /data/mysql/logs:/var/log/mysql:Z \ --memory2g --cpus2 \ mysql:8.0.33 echo 步骤5启动Nginx容器 docker run -d \ --name nginx-proxy \ --restartalways \ -p 80:80 \ -v /data/nginx/conf:/etc/nginx/conf.d:ro \ -v /data/nginx/html:/usr/share/nginx/html:ro \ --memory512m --cpus1 \ nginx:1.23-alpine echo ✅ 部署完成 echo MySQL root密码KylinDocker2024 echo Nginx已监听80端口访问http://$(hostname -I | awk {print $1})执行方式# 保存脚本 sudo tee /root/deploy.sh deploy.sh内容 sudo chmod x /root/deploy.sh # 运行全程无需人工干预 sudo /root/deploy.sh6. 进阶技巧监控、日志与故障自愈——让Docker在麒麟上真正“无人值守”装好Docker只是开始生产环境需要它像水电一样可靠。我在麒麟V10 SP1 Server上沉淀出三个必做动作用cadvisor监控容器资源、用loki聚合日志、用healthcheck实现服务自愈。这些不是锦上添花而是避免半夜被报警电话叫醒的后悔药。6.1 容器资源监控用cAdvisor暴露指标给PrometheusDocker自身不提供细粒度指标需借助cAdvisor。麒麟V10 SP1的cgroup v1路径与上游一致可直接使用官方镜像。# 启动cAdvisor监听8080端口采集所有容器 sudo docker run -d \ --name cadvisor \ --restartalways \ --privileged \ --networkhost \ -v /:/rootfs:ro \ -v /var/run:/var/run:rw \ -v /sys:/sys:ro \ -v /var/lib/docker/:/var/lib/docker:ro \ -p 8080:8080 \ gcr.io/cadvisor/cadvisor:v0.47.0 # 验证curl http://localhost:8080/metrics | head -20 # 应看到container_cpu_usage_seconds_total等指标为什么用--networkhost避免cAdvisor通过Docker网桥访问宿主机/proc时因NAT导致指标延迟。麒麟V10 SP1的host网络模式稳定且cAdvisor本身无安全风险。6.2 日志集中管理用LokiPromtail替代ELK轻量且麒麟友好ELK栈在麒麟上内存开销大Logstash需JVM改用Grafana Loki——专为日志设计索引轻量Promtail采集器用Go编写对麒麟glibc无依赖。# 创建Loki配置 sudo tee /data/loki/config.yaml EOF auth_enabled: false server: http_listen_port: 3100 ingester: lifecycler: address: 127.0.0.1 ring: kvstore: store: inmemory replication_factor: 1 chunk_store_config: max_look_back_period: 0s schema_config: configs: - from: 2020-10-24 store: boltdb object_store: filesystem schema: v11 index: prefix: index_ period: 24h storage_config: boltdb: directory: /data/loki/index filesystem: directory: /data/loki/chunks limits_config: enforce_metric_name: false reject_old_samples: true reject_old_samples_max_age: 168h EOF # 启动Loki存储在本地目录 sudo docker run -d \ --name loki \ --restartalways \ -v /data/loki:/data/loki \ -v /data/loki/config.yaml:/etc/loki/local-config.yaml \ -p 3100:3100 \ grafana/loki:2.9.1 # 启动Promtail采集Docker日志 sudo tee /data/promtail/config.yaml EOF server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /data/promtail/positions.yaml clients: - url: http://localhost:3100/loki/api/v1/push scrape_configs: - job_name: docker static_configs: - targets: [localhost] labels: job: docker __path__: /var/lib/docker/containers/*/*.log EOF sudo docker run -d \ --name promtail \ --restartalways \ -v /var/lib/docker/containers:/var/lib/docker/containers:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -v /data/promtail:/data/promtail \ -v /data/promtail/config.yaml:/etc/promtail/config.yml \ grafana/promtail:2.9.16.3 故障自愈为关键容器添加Healthcheck配合restart策略Docker的--restartalways只能重启崩溃进程无法感知服务“活着但不工作”如MySQL进程在但无法响应SQL。必须用HEALTHCHECK指令。# 示例为MySQL镜像添加健康检查Dockerfile FROM mysql:8.0.33 HEALTHCHECK --interval30s --timeout10s --start-period30s --retries3 \ CMD mysqladmin ping -h127.0.0.1 -uroot -pYourStrongPass123 || exit 1# 或在docker run中动态添加无需重建镜像 sudo docker run -d \ --name mysql8-health \ --restartalways \ --health-cmdmysqladmin ping -h127.0.0.1 -uroot -pKylinDocker2024 \ --health-interval30s \ --health-timeout10s \ --health-start-period30s \ --health-retries3 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDKylinDocker2024 \ -v /data/mysql/data:/var/lib/mysql:Z \ mysql:8.0.33 # 查看健康状态 sudo docker inspect --format{{.State.Health.Status}} mysql8-health # ✅ 正常输出healthy # ❌ 故障时输出unhealthyDocker会自动重启容器我在线上环境坚持一个原则所有生产容器必须有Healthcheck且检查逻辑直击业务核心如MySQL查SELECT 1Nginx curl/healthz。没有这个所谓“高可用”就是空中楼阁。去年某次内核升级后MySQL偶尔卡死正是靠Healthcheck在3分钟内自动恢复没影响任何业务请求。希望帮到你。本文还有配套的精品资源点击获取
返回列表