Docker将slim镜像构建的依赖复制到alpine时拷贝/usr/local/bin失败问题

问题核心原因 #

• 两个基础镜像使用的C标准库不兼容：python:3.8.7-slim 是Debian系镜像，使用GNU C库（glibc），而python:3.8.7-alpine3.13使用的是轻量化的musl libc，二者的API和ABI完全不互通，基于glibc编译的二进制文件无法在仅安装musl的系统中直接运行。
• 当你复制整个/usr/local/bin目录到Alpine镜像时，会直接覆盖Alpine原生的、基于musl编译的Python二进制文件，替换为builder阶段slim镜像中基于glibc编译的Python二进制，运行时就会出现找不到依赖库、无法执行的报错。
• 你单独复制celery、pytest文件可以正常运行的原因是：这两个文件本质是Python脚本，头部的shebang会调用系统默认的python解释器，你没有覆盖Alpine原生的Python，所以实际执行时用的是Alpine自带的、适配musl的Python解释器，自然可以正常运行。

能不能直接复制整个/usr/local/bin目录 #

默认情况下不行，如果你一定要这么做，需要给Alpine镜像额外安装glibc兼容层，但这会大幅增加镜像体积，完全失去了使用Alpine镜像的轻量化优势，非常不推荐。

优化建议 #

• 最稳妥的方案是两个构建阶段使用同系列基础镜像：要么都用slim系，要么都用alpine系，避免跨libc的兼容问题。
• 如果你坚持要保留slim构建+alpine运行的模式，就保持当前逐个复制所需Python可执行脚本的做法，不要覆盖Alpine原生的Python解释器。
• 额外注意：你当前复制的/usr/local/lib/python3.8/site-packages目录中如果包含C语言编译的扩展包，这些扩展也是基于glibc编译的，在Alpine中运行时大概率也会出现兼容报错，如果遇到这类问题，要么切换同系镜像，要么在Alpine阶段重新编译对应依赖。

内容的提问来源于stack exchange，提问作者Альберт Александров