DevOps 学习路径：从版本控制到可观测与供应链
使用方式
DevOps 不是某一个工具，而是一条从提交到运行的流水线。这条路径按“协作 → 构建 → 交付 → 治理”推进，每阶段只保留最必要的页面。
四个阶段按依赖顺序排列，每个阶段建议留 3–4 小时：
- 先读：按顺序读页面，重点理解每一步产出什么、失败会影响谁。
- 再做：在本地或测试集群完成任务，不要直接操作生产流水线。
- 后测：回答过关问题，能画出从 commit 到用户请求的完整路径才算过关。
工具会换，流水线的约束不会变：可重复、可审计、可回滚、可观测。
阶段一：Git 与协作
目标：让每次变更都经过版本控制、评审、自动检查和可追溯的版本号。
阅读顺序：
- git — 分支、提交、合并、rebase 和 reflog，先保证不丢代码。
- gitlab-ci —
.gitlab-ci.yml 的阶段、变量、缓存和制品。
- github-actions — workflow、job、runner 和权限模型。
- gitlab-runner — runner 的注册、执行器和并发限制。
- pre-commit — 在提交前拦截格式、密钥和明显错误。
- commitlint — 提交信息规范，为自动生成版本号做准备。
- semantic-release — 根据提交类型自动决定版本和发布。
- release-please — 用 PR 维护变更日志和版本号。
- act — 本地运行 GitHub Actions，缩短调试回路。
- git-cheatsheet — 常用 Git 操作速查。
动手任务：建一个练习仓库，配置提交前检查和一条至少包含 lint、test、build 的流水线，并用 act 在本地跑一遍。
git init devops-lab && cd devops-lab
git config user.name demo && git config user.email demo@example.com
printf 'print("ok")\n' > app.py
git add app.py && git commit -m 'feat: add app entrypoint'
act -j build --dryrun
git log --oneline --decorate -5
过关标准：
- 能解释为什么流水线要用不可变的提交 SHA，而不是只依赖分支名。
- 知道 CI 变量和密钥应该放在哪里，什么情况下会被日志打印出来。
- 能说清 pre-commit、CI、发布流水线三者的职责边界。
阶段二：构建与制品
目标：把一个提交构建成可验证、可签名、可复现的镜像或制品，并推送到受控仓库。
阅读顺序：
- docker — 镜像分层、容器生命周期和基础命令。
- docker-buildx — 多平台构建、缓存导出和构建器实例。
- buildah — 不依赖 daemon 的镜像构建，适合 CI。
- kaniko — 在 Kubernetes Pod 内构建镜像。
- harbor — 私有仓库、复制、扫描和保留策略。
- oras — 用 OCI 制品保存 SBOM、签名和配置。
- crane — 查看和复制镜像，不落地完整镜像。
- regctl — 直接操作 registry API 里的 manifest 和 digest。
- dive — 检查镜像每层内容和浪费的空间。
- hadolint — Dockerfile 静态检查。
动手任务：写一个多阶段 Dockerfile，用 hadolint 检查，构建多平台镜像，推送到本地 registry，并确认 digest 和层大小。
docker buildx create --use --name lab
hadolint Dockerfile
docker buildx build --platform linux/amd64,linux/arm64 -t localhost:5000/demo:1.0 --push .
docker buildx imagetools inspect localhost:5000/demo:1.0
dive localhost:5000/demo:1.0
过关标准：
- 能解释 tag 可以覆盖而 digest 不可变，发布和回滚应该引用哪一个。
- 知道多阶段构建如何减少最终镜像体积，以及缓存为什么在 CI 里经常失效。
- 能说明构建环境为什么要固定基础镜像和工具版本。
阶段三：部署与交付
目标：把制品以可审计的方式部署到多个环境，支持渐进发布和快速回滚。
阅读顺序：
- helm — Chart、values、模板和 release 状态。
- kustomize — 用 base 和 overlay 表达环境差异。
- argocd — GitOps 同步、健康检查和漂移纠正。
- argo-rollouts — 金丝雀、蓝绿和自动回滚。
- flux — 控制器式 GitOps 和镜像自动更新。
- helmfile — 多个 Helm release 的声明式编排。
- argo-workflows — 用工作流编排构建和发布步骤。
- tekton — Kubernetes 原生的 Pipeline 和 Task。
- tkn — Tekton 命令行，查看 PipelineRun 和日志。
- argocd-cheatsheet — Argo CD 常用操作速查。
动手任务：把一个应用用 Helm 打包，用 Kustomize 管理 dev/prod 差异，交给 Argo CD 同步，再用 Argo Rollouts 做一次金丝雀发布。
helm create demo
helm lint demo
kubectl apply -k overlays/dev
argocd app sync demo-dev
kubectl argo rollouts get rollout demo --watch
过关标准：
- 能说清 Helm 和 Kustomize 各自解决什么问题，什么时候会一起用。
- 知道 GitOps 中“集群漂移”如何被发现和纠正，以及它不能解决什么。
- 能描述一次失败发布从告警到回滚的完整路径。
阶段四：IaC、可观测与供应链
目标：基础设施可重复创建，运行状态可观测，制品来源和构建过程可验证。
阅读顺序：
- terraform — 资源声明、state、plan 和模块。
- ansible-playbook — 无 agent 的配置管理、幂等和 handler。
- prometheus — 指标采集、PromQL 和告警规则。
- grafana — 看板、数据源和告警可视化。
- loki — 按标签索引日志，控制成本和查询范围。
- trivy — 镜像、文件系统和 IaC 的漏洞与配置扫描。
- cosign — 镜像签名、验证和密钥管理。
- slsa-verifier — 校验构建来源和 SLSA provenance。
- backstage — 服务目录、模板和开发者门户。
- in-toto — 供应链各步骤的签名与策略验证。
动手任务：用 Terraform 创建测试命名空间，用 Ansible 配置一台测试机，接入 Prometheus 指标和 Loki 日志，再对镜像做扫描、签名和来源校验。
terraform init && terraform plan && terraform apply
ansible-playbook -i inventory site.yml --check
trivy image --severity HIGH,CRITICAL localhost:5000/demo:1.0
cosign sign --key cosign.key localhost:5000/demo:1.0
cosign verify --key cosign.pub localhost:5000/demo:1.0
过关标准：
- 能解释 Terraform state 的作用、锁的必要性和漂移的处理方式。
- 知道指标、日志、追踪各自回答什么问题，不能互相替代。
- 能说清签名、SBOM、provenance 三者在供应链里分别证明什么。
- 知道生产变更前如何用 plan 或
--check 预演影响范围。
常见误区
- 把 DevOps 等同于“上 CI/CD 工具”，却没有人对流水线失败负责。
- 每个环境重新构建一次镜像，导致测试过的制品和生产运行的制品不一致。
- 发布只改
latest tag，回滚时找不到当时的具体版本。
- 把密钥写进 CI 变量后到处复用，不轮换也不限制权限。
- GitOps 只看同步成功，不看应用健康和数据迁移。
- 可观测性只做看板，没有告警分级、SLO 和排障入口。
- 供应链只做漏洞扫描，不验证构建来源和签名。
读完自测
合上页面，先回答，再展开对照。
- 为什么要求“构建一次，晋升多次”？在每个环境重新构建会带来什么问题？
- GitOps 中 Git 是唯一事实来源，那么集群里手工修改的配置会怎样？
- 镜像签名、SBOM 和 provenance 分别能回答什么问题？
答案
- 重新构建会引入不同的基础镜像、依赖版本和构建缓存，导致测试通过的制品和生产运行的制品不是同一个。构建一次并用 digest 晋升，能保证测试对象就是发布对象，回滚也只是切换回上一个 digest。
- 控制器会持续比较期望状态和实际状态，手工修改会被下一次同步覆盖；如果启用了自动同步，漂移会在很短时间内被纠正。紧急手工修改必须回写到 Git，否则不可审计也不可复现。
- SBOM 回答“制品里包含哪些组件和版本”；签名回答“这个制品由谁签署、是否被篡改”；provenance 回答“它由哪个仓库、哪次提交、哪条流水线、用什么步骤构建”。三者结合才能建立从源码到运行的信任链。
相关条目