如何在AWS实例非使用时段管理docker-compose服务启停

针对仅每日9:00-18:00存在使用需求、其余时段无流量调用的docker-compose编排服务，以下是3类可直接落地的启停管理方案，均适配AWS实例的运行环境：

方案1：实例原生 crontab 定时任务（轻量首选） #

适用单实例、无复杂编排依赖的部署场景，零额外组件引入，维护成本最低。
具体操作步骤：

• 编写独立启停脚本，存放于固定绝对路径（例：/opt/scripts/compose-manage.sh），避免定时任务环境下的路径漂移问题，脚本参考如下：

#!/bin/bash
# 替换为自身compose文件所在的绝对路径
COMPOSE_DEPLOY_DIR="/opt/app/your-compose-project"
ACTION=$1
OPERATION_LOG="/var/log/compose-manage.log"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] 触发$ACTION动作" >> $OPERATION_LOG
cd $COMPOSE_DEPLOY_DIR

if [ "$ACTION" = "start" ]; then
    # 兼容新版docker的compose插件语法
    docker compose up -d >> $OPERATION_LOG 2>&1
elif [ "$ACTION" = "stop" ]; then
    docker compose down >> $OPERATION_LOG 2>&1
fi

• 给脚本赋予可执行权限：chmod +x /opt/scripts/compose-manage.sh
• 解决常见环境问题：crontab默认环境变量不包含docker命令路径，可在脚本开头补充docker命令的绝对路径（通过which docker查询获取），避免定时任务执行失败。
• 配置定时规则：执行crontab -e添加两行调度逻辑，预留5分钟缓冲时间避免流量截断：
  • 每日8:55预启动服务：5 8 * * * /opt/scripts/compose-manage.sh start
  • 每日18:05停服收尾：5 18 * * * /opt/scripts/compose-manage.sh stop
• AWS专属适配：提前在CloudWatch告警配置中，将非使用时段的实例、容器状态告警设置为静默窗口，避免正常停服触发无效告警。

方案2：Systemd Timer 定时调度（高稳定性场景） #

适用对执行可靠性、可观测性有要求的生产类部署，相比crontab支持失败自动重试、执行状态可直接通过系统工具查询。
具体操作步骤：

• 将启停动作封装为独立的systemd服务单元，以启动动作为例，创建/etc/systemd/system/compose-start.service：

[Unit]
Description=Start target docker compose service
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
WorkingDirectory=/opt/app/your-compose-project
ExecStart=/usr/bin/docker compose up -d
# 执行失败自动重试2次，间隔60秒
Restart=on-failure
RestartSec=60

• 同逻辑创建停服对应的compose-stop.service，将ExecStart值替换为/usr/bin/docker compose down即可。
• 为每个服务单元创建对应的timer调度规则，以启动动作为例，创建/etc/systemd/system/compose-start.timer：

[Unit]
Description=Daily trigger for starting compose service

[Timer]
# 每日9点整触发启动
OnCalendar=*-*-* 09:00:00
# 若实例启动时错过了定时任务，10分钟内自动补执行
Persistent=true

[Install]
WantedBy=timers.target

• 同逻辑创建停服的timer规则，将OnCalendar调整为每日18:00触发。
• 启用调度规则：执行systemctl daemon-reload && systemctl enable --now compose-start.timer compose-stop.timer，后续可通过systemctl list-timers直接查看上次执行结果、下次触发时间，排查问题无需翻查零散日志。

方案3：AWS 原生调度联动（成本最优场景） #

适用非使用时段整台实例无其他任务运行的场景，可联动AWS原生能力实现实例级的启停调度，相比仅停止容器的方案能进一步降低整台实例的计算成本。
具体实现逻辑：

• 通过EventBridge配置定时规则，分别绑定EC2实例的Start、Stop API操作，匹配每日9点开机、18点关机的时间需求。
• 配置实例的User Data开机自动执行逻辑：实例启动完成后自动在compose部署目录执行docker compose up -d，无需在实例内部维护额外的定时任务。
• 成本注意项：若实例关联了固定弹性IP，需确认IP在实例停机状态下的计费规则，避免产生非必要的公网资源成本。

选型参考 #

• 内部测试类、低要求部署：优先选crontab方案，配置效率最高。
• 面向内部用户的稳定服务：选systemd timer方案，可靠性和可观测性更强。
• 非使用时段实例无其他负载：选AWS原生调度方案，资源成本最低。

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