docker相关知识和优化

关于dockerfile常用命令对比

CMD RUN ENTRYPOINT

RUN是构建时运行的命令

CMD ENTRYPOINT是运行时执行的命令 不同点在于 docker run 的参数 会直接替换CMD里命令

而 ENTRYPOINT 是直接追加在命令后 所以对于不想影响格式 固定执行的命令 使用 ENTRYPOINT

再通过ENTRYPOINT / CMD执行脚本文件 sh时要注意使用 exec格式的写法 shell格式的写法 防止传入docker run 后续的执行命令无效

比如：

docker run --name ... npm run build

dockerfile内部ENTRYPOINT .sh 直接使用shell写法 会将命令处理为 /bin/sh -c 脚本.sh 内部脚本$@获取后续执行命令为空

如果直接使用exec写法 ENTRYPOINT [.sh] 则会自动传入$@ (推荐写法)

或者 写shell格式的时候 额外处理 显示的生命传入的执行命令 ENTRYPOINT .sh "$@"

传入环境变量的注意点：

兜底处理：

# 定义默认变量（可被-e覆盖） ENV APP_FILE=build.js ENV NODE_PATH=/var/lib/jenkins/nodejs16 # 复制脚本+赋权 COPY start.sh /usr/local/bin/ RUN chmod +x /usr/local/bin/start.sh # ✅ exec格式：脚本直接继承容器环境变量 ENTRYPOINT ["start.sh"]

#!/bin/bash set -e # 出错立即退出 # ========== 1. 验证变量是否接收（调试用）========== echo "📌 容器全局环境变量：" env | grep -E "APP_FILE|NODE_PATH" # 能看到-e传递的变量，证明未失效 # ========== 2. 变量兜底（防止未传）========== APP_FILE=${APP_FILE:-build.js} NODE_PATH=${NODE_PATH:-/var/lib/jenkins/nodejs16} # ========== 3. 执行核心命令（exec保证信号传递）========== exec $NODE_PATH/bin/node $NODE_PATH/$APP_FILE

关于容器间的网络通信：

最近进一步学习docker容器间的网络通信发现除了上面的容器端口映射到宿主机 然后进行外部访问 还可以通过添加到自定义网络即自定义bridge 进行容器间的网络访问 具体如下：

docker create network [net1] //这里的net1是指自定义网络的名字

docker run --name [contianer1] --network net1

docker run --name [contianer2] --network net1

假如contianer1为前端项目 container2为后端服务项目的容器名称 在前端项目的nginx配置中 直接通过

proxy_pass http://[contianer2]

通过容器名称直接进行容器间的自定义网络通信，这样的好处是 比容器端口映射到宿主机 进行端口和端口之间的访问相应要快的多

docker 网络通信

host模式 即容器和宿主机在同一个网络环境 不需要-p 端口映射 但是端口资源有限 会造成资源抢占

bridge模式 可以通过-p端口映射 或者 docker inspect <容器名> 获取ipadress 在nginx 里配置proxy_pass到后端ip

实际操作中的坑点：

1. 当环境为多用户环境时有可能因为docker内外的用户 uid/gid不一致 导致denied permission 权限错误 可以使用gosu进行权限降级注意传入的 -e变量 兜底处理

RUN cat > /usr/local/bin/ci-entrypoint.sh << 'EOF'

#!/bin/sh set -euo pipefail CLI_EXEC_UID= {CLI_EXEC_UID:-0} CLI_EXEC_GID={CLI_EXEC_GID:-0} mkdir -p /app && chown -R {CLI_EXEC_UID}:{CLI_EXEC_GID} /app || true

exec gosu {CLI_EXEC_UID}:{CLI_EXEC_GID} env "$@" EOF

RUN chmod +x /usr/local/bin/ci-entrypoint.sh

在镜像里增加脚本运行 EXTRYPOINT 对文件权限进行统一 和环境变量的转化对应处理 降权的目的是为了不影响容器运行（1.-v 绑定时 文件同步所以需要在容器内给文件运行时赋予宿主机相同的文件权限默认root权限但是对于不同环境上操作 文件的操作权限可能不一致 直接docker run -e 指定运行的权限2.对于nginx 默认80端口 需要root权限，但是文件权限可能不是root ,需要开始使用root 运行nginx 时 gosu降权到普通用户权限说白了都是为了解决 -v文件挂载 但是容器内外的权限不统一）

（题外话 关于sh脚本的编写：可以使用echo + >/>> >是完全覆盖文件内容 >>是增加内容 用于逐行增加 或者'EOF' ...脚本内容......EOF 推荐EOF可读性更好）

docker run -e CLI_EXEC_UID

脚本里$@是完整接收docker run 外部参数传给env防止多个参数造成格式混乱

2.对于依赖的漂移 （这个不属于镜像范畴但是需要注意管控）

再dockerfile内安装依赖 生产环境直接npm ci --no-dry 对依赖版本和package.json进行检测 如果不对应则报错退出

本地为了方便开发调试可以开放到 npm i --no save (不更新package.json -lock.json)但是需要对commit 进行commitlint 使用husky pre-commit钩子前 npm ci --no-dry防止开发者提交错乱版本 如果需要npm update 则 git diff 获取变更文件 校验 如果有package.json commitmessage需要特别格式说明 其他关于多平台兼容问题可详见笔者另外一篇

参考内容：

https://cloud.tencent.com/developer/article/2383395

https://www.cnblogs.com/evakang/p/10407330.html