使用Bazel rules_oci构建Python镜像后Docker运行文件不存在问题排查

1. 架构与动态依赖检查 #

• 本地执行file parser_bin查看二进制架构（如x86_64、arm64），再通过docker run -it --entrypoint /bin/sh <your-image>进入容器，执行file /parser/parser_bin对比架构是否一致。若本地构建架构与容器运行架构不匹配（比如M1 Mac构建arm64镜像却在x86_64机器上运行），会触发此类错误。
• 本地执行ldd parser_bin查看动态依赖库，在容器内同样执行ldd /parser/parser_bin，检查容器环境是否缺失依赖。比如Python二进制依赖的libpython.so可能未被打包进镜像，或容器基础镜像不含对应库。

2. 文件权限与路径验证 #

• 进入容器后执行ls -l /parser/parser_bin，确认文件是否具备可执行权限（即权限位包含x）。若缺少执行权限，执行chmod +x /parser/parser_bin后重试。
• 核对rules_oci配置中files字段的复制路径是否正确，确保Bazel构建产物被放到镜像内的/parser目录下，而非其他路径。

3. Bazel Python构建配置检查 #

• 确认py_binary规则是否启用了zip_safe = False，若为True，生成的是zip包而非可执行二进制，直接执行会报错。
• 检查py_runtime配置是否使用了静态编译的Python解释器，若依赖本地动态链接的Python，镜像内无对应环境会导致执行失败。

4. OCI镜像元数据校验 #

• 使用crane config <your-image>或skopeo inspect docker-daemon:<your-image>查看镜像的Entrypoint和Cmd字段，确认入口路径是否完全匹配/parser/parser_bin，避免拼写错误或路径格式问题（比如相对路径误用）。

• Podman：命令与Docker高度兼容，无需守护进程，直接执行podman run <your-image>即可运行容器，支持OCI标准镜像。
• containerd：通过ctr工具操作，先导入镜像：ctr images import <image-tar-path>，再运行容器：ctr run --rm <image-reference> <container-name>，适合底层容器管理场景。
• runc：OCI官方参考运行时，需先将镜像导出为OCI bundle（可通过oci-runtime-tools generate生成配置），再执行runc run <container-id>启动容器，适合调试OCI规范细节。
• Kubernetes：将镜像推送到容器 registry 后，通过编写Pod/Deployment YAML配置，直接在K8s集群中部署运行，原生支持OCI镜像格式。

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