Python venv虚拟环境跨设备迁移的实现

背景

我们通常会遇到想简易搬迁一台设备的python开发环境到另外一台设备的情况，但可能我们另一台设备本身的python环境包括系统环境是不可控的，这里我遇到的是从centos7搬迁python开发环境到centos6，centos7自带的python环境为2.7.5版本且一些依赖的文件库也是适配2.7.5版本及以上的，导致我们把环境搬迁到centos6的默认python2.6.6环境下时，产生了非常多的报错，以下文档内容记录我遇到的报错及解决方式，并提供一种较为完美的方式轻量级的解决环境移植问题。

python加载lib库的顺序

环境
制作python 虚拟环境设备：

• 系统版本：centos 7

• python版本：python2.7.5

移植的目标设备：

• 系统版本：centos 6

• python版本：python2.6.6

详细操作

安装virtualenv

[centos 7] # pip install virtualenv

创建python venv环境

[centos 7] # mkdir -p /opt/python_venv_test
[centos 7] # virtualenv -p /usr/bin/python2.7 --copies /opt/python_venv_test

--copies的参数意思为尽量不要为/opt/python_venv_test的文件创建软链接，如果不指定该参数，我们可以看到/opt/python_venv_test目录有些文件就是这样的：

[centos 7] # ll /opt/python_venv_test/lib64/python2.7/*
lrwxrwxrwx 1 root root   32 Apr 26 20:24 /opt/python_venv_test/lib64/python2.7/lib-dynload -> /usr/lib64/python2.7/lib-dynload
lrwxrwxrwx 1 root root   26 Apr 26 20:24 /opt/python_venv_test/lib64/python2.7/os.py -> /usr/lib64/python2.7/os.py
lrwxrwxrwx 1 root root   27 Apr 26 20:24 /opt/python_venv_test/lib64/python2.7/os.pyc -> /usr/lib64/python2.7/os.pyc
-rw-r--r-- 1 root root 6978 Apr 26 20:24 /opt/python_venv_test/lib64/python2.7/site.py

/opt/python_venv_test/lib64/python2.7/config:
total 0
lrwxrwxrwx 1 root root 36 Apr 26 20:24 Makefile -> /usr/lib64/python2.7/config/Makefile

/opt/python_venv_test/lib64/python2.7/site-packages:
total 0

可以看到很多文件直接是做了软链接到原python 环境中的lib库中的文件，如果这个时候咱们把他打包移植到另外的设备，这些文件就全部都会被清空，所以一定要加--copies这个参数。加了--copies参数之后是这样的：

[centos 7] # ll -d /opt/python_venv_test/lib64/python2.7/*
drwxr-xr-x 2 root root  4096 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/config
drwxr-xr-x 2 root root  4096 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/lib-dynload
-rw-r--r-- 1 root root 25769 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/os.py
-rw-r--r-- 1 root root 25557 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/os.pyc
drwxr-xr-x 2 root root  4096 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/site-packages
-rw-r--r-- 1 root root  6978 Apr 26 20:31 /opt/python_venv_test/lib64/python2.7/site.py

可以看到没有软链接了，那么我们这个环境就是完全独立的，这时候我们的python venv环境就已经生成了。

打包依赖的glibc库

我们的python环境为python2.7.5版本，比较推荐的是使用glibc-2.17版本，下载地址为：glibc下载地址 ，里面有各个版本的glibc文件。

为什么这里要打包依赖的glibc库呢？

我把虚拟环境目录移植到目标的centos6机器上测试了一下，如果上面的这些库文件在新的设备上没有，那么就会报错，这里我遇到的报错就是：

/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

./bin/python: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libpython2.7.so.1.0)

这两个报错都是很有可能会命中的，提示我们缺少库文件，没有办法运行python binary。

那么到底缺少哪些库文件呢？我们可以通过readelf -d /opt/python_venv_test/bin/python 命令检查python binary的依赖文件：

[centos 7] # readelf -d /opt/python_venv_test/bin/python

Dynamic section at offset 0xdd8 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libpython2.7.so.1.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4005e0
 0x000000000000000d (FINI)               0x4007a4
 0x0000000000000019 (INIT_ARRAY)         0x600dc0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x600dc8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x400298
 0x0000000000000005 (STRTAB)             0x400478
 0x0000000000000006 (SYMTAB)             0x4002f8
 0x000000000000000a (STRSZ)              218 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x601000
 0x0000000000000002 (PLTRELSZ)           48 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x4005b0
 0x0000000000000007 (RELA)               0x400598
 0x0000000000000008 (RELASZ)             24 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x400578
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x400552
 0x0000000000000000 (NULL)               0x0

我们可以在两台机器上查看一下到底有没有库文件，以及库文件产出自哪个rpm包：

目标 centos 6机器没有找到libpython2.7.so.1.0库文件， 而/lib64/libc.so.6文件版本较低，没有达到glibc-2.14版本：

[centos 6] #  whereis libpython2.7.so.1.0
libpython2.7.so.1:

[centos 6] # whereis /lib64/libc.so.6
libc.so: /lib/libc.so.6 /lib64/libc.so.6 /usr/lib64/libc.so

[centos 6] # rpm -qf /lib64/libc.so.6
glibc-2.12-1.80.el6.x86_64

我们回到centos 7机器看看，可以看到有libpython2.7.so.1.0这个文件，而且/usr/lib64/libc.so.6的版本也大于glibc-2.14版本。

[centos 7] # whereis libpython2.7.so.1.0
libpython2.7.so.1: /usr/lib64/libpython2.7.so.1.0

[centos 7] #  rpm -qf /usr/lib64/libpython2.7.so.1.0
python-libs-2.7.5-68.el7.x86_64

[centos 7] #  whereis /lib64/libc.so.6
libc.so: /usr/lib/libc.so.6 /usr/lib64/libc.so /usr/lib64/libc.so.6
[centos 7] #  rpm -qf /usr/lib64/libc.so.6
glibc-devel-2.17-260.el7_6.3.x86_64

来源：https://blog.csdn.net/jk775800/article/details/124432801