4. 自动化运维与CI/CD管道面试：CodePipeline、Jenkins、GitHub Actions集成

面试问答卡片

考察点：Webhook配置、S3源替换、分支过滤、环境映射

回答框架：
1. 连接方式：GitHub通过CodeStar连接或OAuth App。
2. 触发配置：Pipeline中Source阶段选择GitHub（v2连接），使用Event type=Push，分支模式如main / release/* 。
3. 多分支映射：利用管道变量 #{SourceVariables.BranchName} 动态传递到部署阶段，区分dev/staging/prod环境。

简短示例（80字）：
在某电商项目中，我配置了两个Pipeline：一个监听main分支自动部署生产，另一个监听feature/*分支部署到staging环境。通过在CodeBuild中注入BRANCH_NAME环境变量，分别选择ECS服务集群。

可能追问：
1. 如何避免feature分支频繁提交导致staging部署队列阻塞？
2. CodePipeline的并行执行限制与排队策略怎么处理？
3. 如果GitHub Webhook失败，如何手动重触发？

避坑提醒：不要只说“用Webhook”，要说明CodePipeline v2连接支持筛选路径和分支；注意GitHub App安装权限需要仓库admin。

考察点：Jenkins凭据管理、IAM角色 vs AccessKey、插件选型

回答框架：
1. 首选方式：Jenkins节点使用IAM Instance Profile（EC2 Agent自带角色），AWS CLI/ SDK自动继承。
2. 若需跨账户或本地Jenkins：使用Jenkins Credentials Binding插件，存储AWS Access Key/Secret（加密）。
3. 更安全方案：使用AWS Secrets Manager插件动态获取临时凭据，Pipeline中调用 withAWS 块。

简短示例（90字）：
在金融客户迁移项目中，Jenkins Master部署在IDC，无法使用实例角色。我配置了Credentials Binding中AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY，并利用KMS加密。Pipeline中引用withCredentials([[$class:'AmazonWebServicesCredentialsBinding']])，确保Secret不出日志。

可能追问：
1. JenkinsPipeline中如何轮换AccessKey而不中断部署？
2. 如果使用OIDC方式（GitHub Actions自有），Jenkins是否有类似方案？
3. 凭据泄露后如何快速吊销？

避坑提醒：严禁将AccessKey硬编码在Jenkinsfile中；不要忽略Jenkins Master本身的凭据加密配置（使用JCEKS）。

考察点：OIDC身份认证、Actions缓存、Matrix策略、ECS任务定义更新

回答框架：
1. 身份认证：配置AWS IAM OIDC Provider信任GitHub Actions，使用 aws-actions/configure-aws-credentials@v2 获取临时凭证。
2. 构建推送：docker/build-push-action@v4 设置cache-from/cache-to（S3或GH cache）。
3. 部署：aws-actions/amazon-ecs-deploy-task-definition@v1 生成新任务定义并更新服务，指定forceNewDeployment。

简短示例（100字）：
我设计了一个GitHub Actions Workflow，当tag推送到v*.*.*时执行：1) 使用OIDC获取临时凭证；2) 构建多架构镜像并推送到ECR；3) 调用render-task-definition替换镜像标签；4) 执行ECS滚动更新。整个流程5分钟完成，缓存层缩短构建时间40%。

可能追问：
1. 如何使用Matrix策略同时构建多个微服务？
2. ECS部署如何验证服务健康再切换流量？
3. OIDC Provider的audience怎么配置才安全？

避坑提醒：
• 不要在Actions里明文写AWS Secret Key；OIDC是唯一推荐方案。
• 注意ECS服务部署默认只更新任务定义，需显式设置forceNewDeployment=true；否则需要手动stop task。

③ 项目案例模板

④ 大厂模拟面试

候选人回答（普通答案）：我会尽量利用Docker缓存，把不常变动的依赖层放在前面，这样后续构建就不需要重复下载了。

优秀答案：在CodeBuild中，我会把--cache-from指向ECR中最近成功构建的镜像，同时使用本地缓存目录挂载到/root/.docker/cache。对于Jenkins，我会在Jenkinsfile中显式使用docker buildx --cache-to=type=registry，让多个分支共享同一缓存。对于GitHub Actions，我会配置docker/build-push-action的cache-from/cache-to，选择S3后端。

专家答案：我会从三个层面回答：
1. 策略层：区分“缓存层”与“业务层”。基础镜像、系统包、npm/python依赖作为固定缓存层；业务代码变动的层放在最后。
2. 工具层：在CodeBuild中启用本地缓存（Local Cache）并将/root/.m2//root/.npm//var/cache/apt等目录映射到构建环境的SSD卷，同时利用S3存储layer cache。
3. 度量层：构建完成后自动上报CloudWatch指标（构建时长、缓存命中率），设置告警：若缓存命中率<70%则触发告警分析原因。曾经某个服务因为依赖锁文件更改太频繁导致缓存命中率下降到30%，我通过将锁文件固化到一个独立层并设置PR流程来限制变更频率。

面试官追问: 如果一台构建Agent缓存满了，导致新构建失败怎么处理？

建议回答框架：
• 自动清理策略（如LRU淘汰或按构建ID删除）
• 使用外部缓存存储（S3/Redis）而非本地磁盘
• 设置构建前磁盘空间检查，不足则触发缓存清理Job