Docker容器运行时报GLIBC_2.27 not found错误咨询

报错的核心诱因是启动容器时的全量系统库挂载操作直接破坏了容器内部的依赖版本匹配关系：

• 你使用的基础镜像tensorflow/tensorflow:1.12.0-devel-py3基于Ubuntu 16.04构建，系统内置的GLIBC版本最高为2.23，不提供GLIBC_2.27符号。
• 启动命令中-v /usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu、-v /usr/lib/i386-linux-gnu:/usr/lib/i386-linux-gnu两个参数，会把宿主机的系统库目录整个挂载覆盖到容器内对应路径。如果你的宿主机是Ubuntu 18.04及以上版本，目录内的libapt-pkg.so.5.0是基于GLIBC 2.27编译的，运行时会去找容器内/lib/x86_64-linux-gnu/libc.so.6里的对应符号，版本不匹配就触发报错。
• 镜像构建阶段不会加载docker run指定的任何挂载参数，容器内文件系统完全隔离，apt调用的都是镜像内置的版本匹配的依赖库，自然不会触发该错误。

注意：全量挂载宿主机/usr/lib目录属于高危错误操作，除了apt之外，容器内所有依赖系统库的程序都可能出现随机的版本冲突、崩溃问题。

• 直接删除启动命令中上述两个全量挂载系统库的参数，从根源上避免容器内部系统库被宿主机文件覆盖。
• 你挂载这两个目录大概率是为了解决容器内运行PyCharm等GUI程序的依赖缺失问题，不要用整目录覆盖的方式解决：如果确实需要个别宿主机上的动态库，仅挂载缺失的单个so文件到容器内的非系统路径（比如/opt/ext_libs），启动容器时通过-e LD_LIBRARY_PATH=/opt/ext_libs:$LD_LIBRARY_PATH将该路径加入库搜索路径即可。
• 更稳妥的GUI依赖解决方式是在Dockerfile构建阶段，直接通过apt安装GUI程序需要的所有依赖包，容器内源安装的库和自身系统版本完全匹配，不会出现GLIBC版本冲突问题。比如运行PyCharm常规需要的依赖可以在构建时安装：libxext6 libxrender1 libxtst6 libxi6 libxrandr2 libfreetype6 fontconfig

内容的提问来源于stack exchange，提问作者feelfree