如何控制Docker entrypoint.sh仅在生产环境启动crontab

环境变量判断是最优实现方式 #

你提到的通过环境变量控制cron启动的思路完全可行，也是这类场景下维护成本最低的方案，核心逻辑是默认不启动cron，仅当显式传入生产环境标识时才执行cron配置与启动流程。
修改后的entrypoint.sh参考如下：

#!/bin/bash
set -e

# 匹配生产环境标识时才启动cron
if [ "$APP_ENV" = "production" ]; then
  # 写入定时任务配置
  cat > /var/www/scheduler.txt <<'EOF'
* * * * * /usr/local/bin/php /var/www/html/cron.php >> /var/log/cron.log 2>&1
EOF
  # 加载定时任务
  crontab /var/www/scheduler.txt
  # 启动cron服务
  service cron start
fi

# 所有环境均启动apache，用exec让apache成为1号进程，正确接收容器信号
exec /usr/sbin/apache2ctl -D FOREGROUND

.env文件的使用与多环境管理 #

• entrypoint.sh中读取环境变量的方式和普通shell脚本完全一致，直接通过$变量名引用即可。Docker启动容器时注入的所有环境变量，都会被入口进程直接读取，不需要额外执行source操作。
• 开发环境管理：可以直接在开发环境docker-compose.yml的服务配置中通过environment字段声明环境变量，不需要额外维护文件：

version: "3.5"
services:
  example:
    build:
      context: .
      dockerfile: ./example.Dockerfile
    image: username/example
    environment:
      - APP_ENV=development
# 其余配置保持不变

如果偏好使用.env文件，只需在开发compose文件同目录创建.env文件写入APP_ENV=development，执行docker-compose up时会自动加载该文件内的变量。

• 生产环境（Docker Swarm）管理：生产环境的变量文件单独存放，不要和开发环境混用，比如命名为.env.prod，部署stack时通过--env-file参数指定加载的变量文件即可：

docker stack deploy -c docker-compose-prod.yml --env-file ./.env.prod your_stack_name

为了避免漏传变量导致cron不启动，更稳妥的方式是直接在生产环境的docker-compose-prod.yml中写死生产环境标识：

version: '3.5'
services:
  example:
    image: username/example
    environment:
      - APP_ENV=production
    deploy:
      replicas: 3
# 其余配置保持不变

节点标签无法直接用于容器内的逻辑判断 #

Docker Swarm的节点标签（即deploy.placement.constraints中使用的标签）是Swarm调度层面的元数据，仅用于决定容器调度到哪些节点运行，不会自动注入到容器内部，入口脚本根本无法读取到节点标签的值，不能直接用来做环境判断。
如果一定要关联节点标签，需要手动将标签对应的值映射为容器环境变量传入，本质和直接传入APP_ENV的逻辑没有区别，只会增加不必要的维护成本，不推荐使用。

落地步骤 #

1. 将entrypoint.sh替换为上述带环境判断的版本，重新构建镜像并推送到DockerHub
2. 开发环境配置中不设置APP_ENV=production（或显式设置为development），启动容器时cron默认不会运行
3. 生产环境配置中显式设置APP_ENV=production，部署后cron会正常启动

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