关于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 对文件权限进行统一 和环境变量的转化对应处理 

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

docker run -e CLI_EXEC_UID 

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