在openEuler系统构建高可用Python离线部署方案：从依赖打包到环境验证

1. 为什么需要Python离线部署方案

最近接手了一个金融行业的项目，客户要求所有系统必须运行在完全隔离的内网环境中。第一次听到这个需求时，我心想："这不就是装个Python环境吗？能有多难？"结果在实际操作中踩了不少坑。比如有一次，我自信满满地把开发机上的包直接拷贝到生产环境，结果因为GLIBC版本不兼容导致整个项目无法启动，差点耽误了上线时间。

在openEuler系统上进行Python离线部署，最大的挑战在于依赖完整性和环境一致性。与常见的Ubuntu或CentOS不同，openEuler作为国产操作系统，在软件包管理和系统库依赖上有自己的特点。特别是在金融、政务等对安全性要求高的领域，服务器通常不允许连接外网，这就要求我们必须构建一套完整的离线部署方案。

我总结了下，一个健壮的离线部署方案需要解决三个核心问题：

• 依赖打包：如何完整收集所有Python包及其系统依赖
• 环境隔离：如何确保不同项目之间的依赖不冲突
• 验证机制：如何快速验证部署后的环境是否符合预期

2. 完整依赖打包实战

2.1 精准收集Python依赖

在联网环境下，我习惯使用这个命令来收集项目依赖：

mkdir -p ./offline_packages pip download -r requirements.txt \ --destdir ./offline_packages \ --platform manylinux2014_x86_64 \ --python-version 3.8 \ --only-binary=:all:

这里有几个关键参数需要注意：

• --platform：必须与目标系统架构一致，openEuler通常使用manylinux2014_x86_64
• --python-version：指定目标环境的Python版本
• --only-binary：强制下载二进制wheel包，避免源码编译问题

有次我漏掉了--only-binary参数，结果在离线环境安装时卡在了编译环节，因为生产机没有安装gcc等编译工具链。

2.2 处理系统级依赖

Python包经常会依赖系统库，比如常见的libssl、libffi等。在openEuler上，我推荐先用这个命令检查可能需要的系统包：

yum install -y gcc gcc-c++ make openssl-devel bzip2-devel libffi-devel zlib-devel

如果遇到类似"libcrypto.so.1.1: cannot open shared object file"这样的错误，可以用这个命令查找对应的rpm包：

yum provides */libcrypto.so.1.1

建议在有网络的环境提前下载这些系统依赖：

mkdir -p ./system_packages yumdownloader --destdir ./system_packages openssl-libs libffi

3. 构建高可用部署包

3.1 标准化打包流程

我习惯把项目结构组织成这样：

project_deploy/ ├── bin/ # 启动脚本 ├── conf/ # 配置文件 ├── packages/ # Python依赖 ├── system/ # 系统依赖 ├── requirements.txt └── install.sh # 安装脚本

打包时使用这个命令确保权限和软链接正确处理：

tar -czvf deploy.tar.gz \ --owner=root \ --group=root \ --transform 's,^,deploy/,' \ project_deploy/

3.2 智能安装脚本编写

这是我常用的install.sh模板：

#!/bin/bash # 安装系统依赖 if [ -d "./system" ]; then rpm -ivh ./system/*.rpm --nodeps --force fi # 创建虚拟环境 python -m venv /opt/project/venv source /opt/project/venv/bin/activate # 安装Python依赖 pip install --no-index --find-links=./packages -r requirements.txt # 设置环境变量 echo "export PROJECT_HOME=$(pwd)" >> /etc/profile.d/project.sh

记得给脚本添加执行权限：

chmod +x install.sh

4. 部署验证与排错

4.1 环境一致性检查

我开发了一个验证脚本check_env.py：

import sys import ssl import sqlite3 def check_versions(): print(f"Python: {sys.version}") print(f"OpenSSL: {ssl.OPENSSL_VERSION}") def check_imports(): try: import numpy import pandas print("All imports successful") except ImportError as e: print(f"Import failed: {e}") if __name__ == "__main__": check_versions() check_imports()

4.2 常见问题解决方案

GLIBC版本问题：

# 查看当前版本 ldd --version # 解决方案： # 1. 在低版本环境中重新打包 # 2. 使用静态链接的二进制包

架构不匹配：

# 确认系统架构 uname -m # 重新打包时指定正确平台 pip download --platform manylinux2014_aarch64 ...

虚拟环境激活失败：

# 检查venv是否完整 ls -l venv/bin/python # 重建虚拟环境 python -m venv --clear venv

5. 进阶优化技巧

5.1 使用Docker构建离线镜像

虽然openEuler环境可能不允许直接使用Docker，但可以在开发机预先构建测试镜像：

FROM openeuler/openeuler:22.03 COPY deploy.tar.gz /tmp RUN tar -xzvf /tmp/deploy.tar.gz -C /opt && \ /opt/deploy/install.sh CMD ["/opt/deploy/bin/start.sh"]

5.2 依赖缓存策略

我习惯在本地维护一个离线包缓存仓库：

# 创建本地仓库目录结构 mkdir -p /opt/pypi/packages mkdir -p /opt/pypi/index # 使用pip2pi生成索引 pip2tgz /opt/pypi/packages -r requirements.txt dir2pi /opt/pypi/packages # 在离线环境使用 pip install --index-url=file:///opt/pypi/index/simple ...

5.3 性能监控集成

在部署脚本中加入健康检查：

# 在install.sh末尾添加 cat <<EOF > /etc/cron.d/project_check */5 * * * * root /opt/project/venv/bin/python /opt/project/bin/healthcheck.py EOF

健康检查脚本示例：

# healthcheck.py import psutil import requests def check_resources(): if psutil.cpu_percent() > 90: raise RuntimeError("CPU usage too high") if psutil.virtual_memory().percent > 90: raise RuntimeError("Memory usage too high") if __name__ == "__main__": check_resources() # 添加其他自定义检查