Shell脚本如何配置容器恢复策略

wen 实用脚本 2026-07-15 3

Shell脚本如何配置容器恢复策略：自动化高可用架构实战指南

Shell脚本如何配置容器恢复策略

目录导读

容器恢复策略的核心概念
- 为什么需要自动化恢复？
- Shell脚本在容器编排中的角色
前置条件与工具准备
- Docker/Singularity环境
- 健康检查工具（curl、docker inspect）
脚本核心实现：健康检测与自动重启
- 基于状态码的监测逻辑
- 资源耗尽时的回退机制
高级策略：数据持久化与日志恢复
- 卷挂载与快照恢复
- 日志切割与异常告警
常见问题与问答
- Q：如何避免脚本陷入死循环？
- Q：容器重启后IP变化怎么办？
性能优化与安全建议
- 限制重启频率（指数退避算法）
- 最小权限原则的脚本实现

Shell脚本如何配置容器恢复策略

容器恢复策略的核心概念

在微服务架构中,容器崩溃或资源泄漏是不可避免的。人工重启显然无法满足高可用需求，因此我们需要通过Shell脚本实现自动化恢复策略，核心思想是：

监测：定期检查容器状态（运行中、健康检查通过）。
决策：根据失败原因（进程崩溃、挂载卷丢失、内存溢出）触发不同恢复动作。
执行：重启容器，同时保留关键数据（例如数据库的持久化卷）。

Shell脚本的优势在于零依赖、易于定制，尤其适合没有Kubernetes等编排工具的环境。

前置条件与工具准备

在编写脚本前,确保系统具备：

容器运行时：Docker或Podman（本文以Docker为例）。
健康检查端点：容器内应用需暴露HTTP或自定义健康接口（/health）。
工具安装：curl、jq（可选，用于JSON解析）、systemctl（如果管理宿主机服务）。

示例：创建一个测试容器（Nginx）并用docker命令启动：

docker run -d --name web-server -p 8080:80 nginx:latest

脚本核心实现：健康检测与自动重启

以下是一个基础恢复脚本（recover.sh），它每30秒检查容器是否存活：

#!/bin/bash
CONTAINER_NAME="web-server"
MAX_RETRIES=5
RETRY_INTERVAL=30
# 健康检查函数
check_health() {
    local HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health)
    if [ "$HTTP_CODE" -ne 200 ]; then
        return 1  # 不健康
    fi
    return 0
}
# 主循环
while true; do
    if ! check_health; then
        echo "[$(date)] 容器 $CONTAINER_NAME 不健康，尝试重启..."
        docker restart $CONTAINER_NAME 2>&1
        if [ $? -eq 0 ]; then
            echo "[$(date)] 重启成功，等待30秒后再次检查"
        else
            echo "[$(date)] 重启失败，可能是容器不存在或资源不足"
        fi
    fi
    sleep 30
done

关键点：

使用docker restart而非docker start，因为前者会保留容器的IP和网络配置。
增加日志时间戳,便于追溯问题。

高级策略：数据持久化与日志恢复

1 卷挂载与快照恢复

对于数据库容器（如MySQL），重启时需确保数据不丢失，脚本应备份卷挂载点：

VOLUME_PATH="/var/lib/docker/volumes/mysql-data/_data"
BACKUP_PATH="/backup/$(date +%Y%m%d_%H%M%S)_mysql"
# 在容器重启前备份
if ! check_health; then
    # 备份当前数据（假设容器挂载该卷）
    tar -czf "$BACKUP_PATH.tar.gz" -C "$VOLUME_PATH" .
    echo "[$(date)] 数据备份至 $BACKUP_PATH.tar.gz"
    docker restart $CONTAINER_NAME
fi

2 日志切割与异常告警

使用logrotate或脚本内建切割，避免日志撑爆磁盘：

LOG_FILE="/var/log/container/app.log"
MAX_LOG_SIZE=100M
if [ $(stat -c%s "$LOG_FILE") -gt $MAX_LOG_SIZE ]; then
    mv "$LOG_FILE" "$LOG_FILE.$(date +%s)"
    touch "$LOG_FILE"
    # 触发容器重启以重新加载日志配置（可选）
    docker exec $CONTAINER_NAME kill -USR1 1
fi

常见问题与问答

Q1：如何避免脚本陷入死循环（尤其是容器频繁重启时）？

A：采用指数退避算法，每次重启失败后，等待时间按指数增长（例如2秒→4秒→8秒…），并设置最大上限（如300秒），脚本示例：

WAIT_TIME=2
MAX_WAIT=300
while true; do
    if ! check_health; then
        docker restart $CONTAINER_NAME || true
        sleep $WAIT_TIME
        WAIT_TIME=$((WAIT_TIME*2 > MAX_WAIT ? MAX_WAIT : WAIT_TIME*2))
    else
        WAIT_TIME=2  # 健康后重置等待时间
    fi
    sleep 30
done

Q2：容器重启后IP地址变化，如何动态更新其他服务配置？

A：通过Docker的网络别名（--network-alias）或使用固定IP（--ip参数），但更推荐的方式：

在脚本中调用DNS注册（如Consul、Etcd）更新服务发现。
若服务通过环境变量监听端口,重启后无需修改IP，因为容器名不会变（docker exec仍可通过名称访问）。

Q3：如何区分“容器进程崩溃”和“宿主机关机”？

A：先检查Docker守护进程是否存活：

if systemctl is-active docker --quiet; then
    # Docker正常，则检查容器状态
else
    echo "Docker守护进程已停止，无法恢复容器"
    exit 1
fi

性能优化与安全建议

1 限制重启频率

使用systemd或cron将脚本作为服务运行，避免多个进程同时检测同一容器。
在脚本头部加入flock（文件锁）防止并发：
```
exec 9>/var/lock/recover.lock
flock -w 5 9 || exit 1
```

2 最小权限原则

脚本应只包含docker命令所需权限（除非需要sudo，但推荐将用户加入docker组）。
避免在脚本中硬编码密码；使用环境变量或密钥管理工具（如Vault）。

3 集成监控告警

在脚本中增加HTTP通知（如Slack Webhook）：

curl -X POST -H "Content-type: application/json" \
  --data "{"text": "容器 $CONTAINER_NAME 已自动重启"}" \
  https://hooks.slack.com/services/xxx/yyy/zzz

通过Shell脚本配置容器恢复策略,既能避免依赖复杂编排工具，又能精准控制恢复逻辑，从基础健康检查到高级数据备份，本文提供的示例可直接集成到生产环境，记得测试三种异常场景：容器崩溃、宿主机资源枯竭、网络不可达，确保脚本在极限情况下依然可靠。

延伸阅读：若需要更强大的恢复能力（如滚动更新、自动扩缩容），可进一步研究Docker Compose的restart: always或Kubernetes的livenessProbe，但Shell脚本始终是运维工具箱中轻量而高效的工具。