Shell脚本如何配置容器发布策略

wen 实用脚本 2026-07-15 1

Shell脚本驱动容器发布策略：自动化部署与灰度发布实战指南

目录导读

容器发布策略的核心挑战：环境一致性、版本控制与流量切换
Shell脚本在CI/CD中的角色：从镜像构建到健康检查的闭环
配置容器发布策略的5个关键Shell片段
- 1 灰度发布比例控制（k8s权重更新）
- 2 回滚版本自动选择（基于git tag）
- 3 滚动更新速率调节（sleep与liveness探测）
- 4 蓝绿环境切换（DNS切换与负载均衡）
- 5 健康检查与自动回滚（curl+crontab组合）
实战问答
- Q1：如何用Shell脚本实现k8s Deployment的渐进式灰度发布？
- Q2：如何通过Shell脚本在Docker Compose中配置容器的蓝绿部署？
SEO优化建议：结构化的代码块、关键词密度控制与内部链接

为什么要用Shell脚本管理容器发布策略？

容器化应用的发布策略通常涉及版本控制、流量分配、健康检查、回滚机制等复杂环节，虽然Kubernetes、Docker Swarm等编排工具提供了声明式配置（如Deployment的strategy字段），但在多环境（开发/测试/生产）、动态资源（如按需扩缩容）或遗留系统（如基于docker-compose的栈）中，Shell脚本依然是最灵活、最底层的执行层。

Shell脚本如何配置容器发布策略

场景示例：通过一个简单的Shell脚本，你可以实现“当新镜像构建成功后，先升级10%的生产Pod，等待5分钟观察错误率，再决定是否全量推送”，这个逻辑如果用K8s原生API写成YAML+Operator，反而显得臃肿。

Shell脚本配置容器发布策略的核心要素

1 镜像版本与标签管理

# 从CI环境变量获取版本号
IMAGE_TAG=${CI_COMMIT_TAG:-$CI_COMMIT_SHORT_SHA}
IMAGE_NAME="registry.example.com/myapp:${IMAGE_TAG}"
# 检查镜像是否存在（避免推错）
if ! docker manifest inspect ${IMAGE_NAME} > /dev/null 2>&1; then
    echo "错误：镜像 ${IMAGE_NAME} 不存在，请先构建推送"
    exit 1
fi

2 发布策略的三种典型模式

模式	适用场景	Shell脚本控制点
滚动更新	无状态服务、水平扩展	`kubectl set image` + `--record` + 间隔sleep
蓝绿部署	有状态服务、需要零停机	切换Service selector的两个标签版本
灰度/金丝雀	高风险变更、用户分流	调整Deployment的`maxSurge`/`maxUnavailable`权重

实战：5个Shell脚本片段实现容器发布策略

1 灰度发布比例控制（基于K8s权重）

#!/bin/bash
# 金丝雀发布：逐步将10%流量切向新版本
DEPLOY_NAME="myapp"
NAMESPACE="production"
NEW_VERSION="v2.1"
# Step1: 创建新版本ReplicaSet（但Service不关联）
kubectl set image deployment/${DEPLOY_NAME} \
    myapp=registry.example.com/myapp:${NEW_VERSION} \
    --record -n ${NAMESPACE}
# Step2: 修改Service的selector权重（假设有两个标签：version: old 和 version: canary）
kubectl patch service ${DEPLOY_NAME}-svc -p \
    '{"spec":{"selector":{"version":"canary"}}}' \
    -n ${NAMESPACE}
# Step3: 10分钟后检查错误率（假设Prometheus已集成）
sleep 600
if curl -s "http://monitor.example.com/api/v1/query?query=error_rate" | grep -q ">0.5"; then
    echo "错误率升高，触发回滚"
    bash rollback.sh   # 调用回滚脚本
else
    # 全量切换
    kubectl patch service ${DEPLOY_NAME}-svc -p \
        '{"spec":{"selector":{"version":"stable"}}}' \
        -n ${NAMESPACE}
fi

2 基于Git Tag的智能回滚

# 获取最近3个稳定版本
STABLE_TAGS=$(git tag --list 'v*' --sort=-version:refname | head -n 3)
LATEST_STABLE="${STABLE_TAGS%% *}"
if [ "$(kubectl rollout history deployment/myapp -n prod | grep failed)" != "" ]; then
    echo "检测到发布失败，回滚至：${LATEST_STABLE}"
    kubectl rollout undo deployment/myapp --to-revision=${LATEST_STABLE} -n prod
fi

3 滚动更新速率控制（避免雪崩）

# 分批升级：每次升级2个Pod，间隔30秒
for pod in $(kubectl get pods -l app=myapp -o jsonpath='{.items[*].metadata.name}'); do
    kubectl set image pod/$pod myapp=registry.example.com/myapp:${NEW_VERSION}
    if [ $? -eq 0 ]; then
        echo "已升级：$pod"
        sleep 30  # 等待健康检查通过
    else
        echo "失败，终止滚动"
        exit 1
    fi
done

4 蓝绿环境切换（DNS/负载均衡）

# 假设使用Nginx反向代理配置
BLUE_PORT=3000
GREEN_PORT=3001
# 部署绿色版本
docker-compose -f docker-compose.green.yml up -d
# 健康检查（等待5秒）
sleep 5
if curl -f http://localhost:${GREEN_PORT}/health; then
    # 切换Nginx upstream
    echo "切换到绿色环境"
    sed -i "s/server localhost:${BLUE_PORT}/server localhost:${GREEN_PORT}/g" /etc/nginx/conf.d/myapp.conf
    nginx -s reload
else
    echo "绿色环境健康检查失败，保留蓝色"
    exit 1
fi

5 健康检查与自动回滚（Crontab触发）

# 每5分钟检查一次Pod状态（crontab -e 添加）
*/5 * * * * /usr/local/bin/health_check.sh
# health_check.sh内容：
PODS=$(kubectl get pods -l app=myapp -o json | jq '.items[].status.conditions[] | select(.type=="Ready") | .status')
FAIL_COUNT=$(echo $PODS | grep -c "False")
if [ $FAIL_COUNT -gt 2 ]; then
    echo "【告警】超过2个Pod不可用，自动回滚"
    kubectl rollout undo deployment/myapp -n prod
    curl -X POST -d "rollback=true" https://hooks.slack.com/services/xxxxx
fi

问答环节

Q1：如何用Shell脚本实现K8s Deployment的渐进式灰度发布？
A1：核心思路是修改Deployment的strategy.rollingUpdate.maxSurge和maxUnavailable参数，逐步调整新副本集的比例，示例：

# 初始：只允许10%额外Pod
kubectl patch deployment myapp -p \
    '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":"10%","maxUnavailable":"10%"}}}}'
# 升级镜像后，通过scale命令手动触发渐进
for i in $(seq 10 20 100); do
    kubectl scale deployment myapp --replicas=10   # 假设总副本10个
    kubectl set image deployment/myapp *=registry.example.com/myapp:new
    sleep 120
    if curl -s http://myapp.monitor/metrics | grep "error_rate > 0.1"; then
        break   # 错误率超阈值则停止
    fi
done

Q2：如何通过Shell脚本在Docker Compose中配置蓝绿部署？
A2：利用Docker Compose的scale命令和网络别名控制，示例脚本：

# 启动蓝版本
docker-compose -f docker-compose.blue.yml up -d
# 启动绿版本（修改端口映射）
sed -i 's/80:80/81:80/g' docker-compose.green.yml
docker-compose -f docker-compose.green.yml up -d
# 通过Nginx反向代理切换
if curl http://localhost:81/health; then
    iptables -t nat -R PREROUTING 1 -p tcp --dport 80 -j DNAT --to-destination 172.20.0.2:81
    echo "流量已切至绿色环境"
    docker-compose -f docker-compose.blue.yml down   # 关闭蓝色
fi

SEO优化与搜索引擎排名要点

关键词布局、H1-H3标签、首段、Q&A部分均出现“Shell脚本”“容器发布策略”“灰度发布”“滚动更新”等关键词（密度约2%-3%）。
结构化数据：使用目录（锚点链接）、代码块（<pre>标签标注语言）、表格（Markdown转HTML时保留表格语义）。
内部链接：在“健康检查”章节自然链接到“容器监控最佳实践”主题（假设站内存在，此处模拟为/monitor-container-health）。
外链价值：引用Docker官方文档（docs.docker.com）、Kubernetes官方手册（kubernetes.io），但避免过多低质量站点。
可读性：每段不超过4行，代码块需有注释解释关键参数，问答部分突出用户搜索意图（如“怎么做灰度发布”）。

Shell脚本在容器发布策略中扮演着“乐高积木”的角色——将K8s/Docker的抽象命令组合成具体的业务逻辑，无论是简单的kubectl set image，还是复杂的金丝雀发布权重计算，通过变量封装、条件判断和定时检查，均可实现生产级发布流程，建议结合CI/CD工具（如Jenkins、GitLab CI）将上述脚本参数化,形成可复用的发布库。