文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载90DaysOfDevOps 第三天2022 路线图以应用为核心视角把 DevOps 生命周期拆解为「开发 → 测试 → 集成 → 部署 → 监控」五个阶段并强调这是一个周而复始的闭环。本文将完整继承该文档的核心脉络并结合当前仓库中真实存在的 CI/CD 流水线、容器化配置、Kubernetes 编排清单与 Elastic Stack 监控栈等源码佐证帮助你理解一个应用从需求诞生、编码提交、自动测试、部署上线到持续监控与成本治理的完整旅程以及 DevOps 工程师在这条链路上应当扮演的角色。DevOps 生命周期以应用为核心的持续循环在接下来数周的学习中「持续开发Continuous Development、持续测试Continuous Testing、持续部署Continuous Deployment、持续监控Continuous Monitoring」这些词汇会被反复提及。如果你正朝着 DevOps 工程师岗位发展可重复性repeatability将是你必须习惯的工作常态——同一个流程会被一次次执行而每次循环后的持续改进constant enhancement则是让这份工作始终保持有趣、有挑战性的关键。本次课程的核心是站在**应用Application**的角度从零开始追踪它从启动到结束、再回到起点的高层视图开发(Development) → 测试(Testing) → 集成(Integration/CI) → 部署(Deployment) → 监控(Monitoring) ↑ ↓ └──────────────── 反馈与改进闭环 ←──────┘下面逐一深入每个阶段并结合仓库中的真实文件佐证其落地方式。阶段一开发Development——需求、编码与版本控制以一个全新应用为起点初始阶段一切尚未创建。作为开发者你首先需要与客户或终端用户讨论需求requirements形成应用的计划与需求清单然后据此从零编写应用。本阶段的工具需求极简只需要选择你习惯的 IDE集成开发环境以及希望用来编写应用的编程语言。仓库本身就是一个多语言混合示例——例如 2022/Days/Go 目录下存放着 Go 语言的学习代码而 CI/CD 示例则涉及 Java/Maven 与 shell 脚本这说明应用可以用任何语言编写语言选择取决于业务场景与团队技术栈。从源码结构看可以得出两个对 DevOps 工程师至关重要的结论DevOps 工程师通常不是需求方案或业务代码的作者——那是熟练的开发者的工作。但 DevOps 工程师最好具备阅读部分代码的能力这样才能为应用做出最优的基础设施决策例如这段代码是 CPU 密集还是 IO 密集需要怎样的内存与存储规格。代码必须纳入版本控制系统Version Control System维护这正是后续课程将重点展开的Git。一个项目几乎不可能只有一名开发者最佳实践要求使用**代码仓库code repository**来存储与协作——可以是私有或公开、自托管或云端托管业界常见的是 GitHub、GitLab 这类平台。这些内容也会在后续Git专题中详细覆盖。阶段二测试Testing——用容器压低测试环境的成本进入这一阶段时我们已拥有需求清单应用也正在开发中。此时需要确保代码在所有可用环境尤其是所选编程语言相关的运行时环境中都经过测试。这一阶段的核心价值有两层QA 负责测试与缺陷发现。如今越来越普遍的做法是用容器container模拟测试环境——相比搭建物理或云基础设施容器可以整体降低测试环境的成本开销。测试自动化是必然趋势。这一阶段大概率会作为下一环节「持续集成Continuous Integration」的一部分被自动化。原文特别点明了一个对比让数十、数百乃至数千名 QA 工程师手工测试与把测试自动化相比差距不言而喻。测试自动化能把工程师从「反复测试 bug」中解放出来让他们专注于栈内其他更有价值的开发工作从而比采用瀑布方法论waterfall methodology的传统软件发布更快地交付更多功能——传统瀑布式发布恰恰最容易卡在 bug 测试环节。仓库中的 Dockerfile 是容器化环境的一个直观示例它基于ubuntu:18.04官方镜像构建安装 nginx 与 curl并通过groupadd/useradd创建非 root 的basicuser用户最后用USER basicuser切换运行身份。这段配置体现了测试/运行环境容器化的两个要点镜像可复现同一 Dockerfile 永远构建出相同基线环境与最小权限运行不推荐以 root 运行应用进程这正是容器能低成本、安全地替代物理/云测试基础设施的原因。阶段三集成Integration / CI——生命周期的心脏集成Integration在 DevOps 生命周期中处于核心枢纽地位它要求开发者更频繁地提交源代码变更——可以按天、也可以按周。每次提交应用都能自动进入自动化测试阶段从而在进入下一阶段之前尽早发现潜在问题或 bug。这就是「持续集成Continuous Integration」的核心机制提交频率越高问题暴露越早修复成本越低。仓库中的 Jenkinsfile 是 CI 阶段落地形态的完整示例其流水线清晰复现了「提交 → 构建 → 测试 → 产物」的链条Clone Repository 阶段git url: https://github.com/MichaelCade/Jenkins-HelloWorld.git拉取源码对应「频繁提交」的源头Build Image 阶段在maven:3.8.1-jdk-8容器内执行构建并以echo Tests passed作为自动化测试占位——即每次提交后自动跑一遍测试Test Image / Build Hello World App 阶段在gcr.io/kaniko-project/executor:debug容器内调用/kaniko/executor --context \pwd --destination michaelcade1/helloworld:1.0用 kaniko 在 Kubernetes Pod 中直接构建并推送应用镜像。这份流水线的技术细节值得注意podTemplate声明了一个包含 maven 与 kaniko 两个容器的 Podmaven 负责编译测试、kaniko 负责镜像构建且通过kaniko-secret挂载到/kaniko/.docker的 docker 凭据 secret实现免认证推送。它印证了 CI 阶段的典型形态每次代码变更自动触发构建与测试问题在进入部署环节前就被拦截。此外原文还给了一个务实的提醒如果你的企业不开发应用而是从软件厂商购买现成的off-the-shelf软件也不必担心——很多公司都这么做。此时前三个阶段主要由软件厂商负责但你仍然应该采纳第四阶段部署因为它能让现成软件的部署更快、更高效。而且掌握这套知识的价值不只在于今天今天你或许在买现成软件明天、以后、乃至下一份工作呢阶段四部署Deployment——配置管理、IaC 与容器编排的用武之地应用已经构建完成、并且针对终端用户需求完成了测试接下来就要部署到生产服务器供终端用户使用。原文明确指出这是整个生命周期中极其有趣、也是剩余 86 天课程将不断深潜的领域。为什么部署如此复杂因为不同的应用需要不同的硬件与配置。正是这一需求催生了 DevOps 生命周期中两个关键支柱应用配置管理Application Configuration Management保证应用在各环境开发/测试/生产中的配置可声明、可追溯、可重放基础设施即代码Infrastructure as Code, IaC用代码来描述、版本化并自动编排基础设施替代手工配置服务器。仓库中 2022/Days/IaC 目录下的 Terraform 文件.tf、.tfvars正是这一主题的实操样本后续课程会展开详解。在部署形态上应用可能被容器化containerised也可能直接运行在虚拟机VM上当容器规模变大就需要引入Kubernetes这样的平台来编排orchestrating容器确保终端用户始终获得你期望的状态desired state。仓库中的 nginx-stateless-demo.yaml 是 Kubernetes 声明式部署的完整示例只用一份 YAML 就描述了三个对象Namespacenginx将应用资源隔离在独立命名空间内Deploymentnginx-deployment声明replicas: 1、镜像nginx、容器端口containerPort: 80——这体现「期望状态」Kubernetes 负责让实际运行副本数始终向声明值收敛Servicenginx-service通过selector关联到带app: nginx标签的 Pod暴露 TCP80端口供访问。这一示例直观展示了原文所述「Kubernetes 编排容器并维护期望状态」的实现原理开发者只需声明目标状态几个副本、什么镜像、暴露哪个端口集群的控制器会持续调和reconcile实际状态与声明状态。阶段五监控Monitoring——性能、可靠性、成本与反馈闭环到这里应用运行速度已经很快了我们持续为应用加入新特性与功能测试确保「没有偷偷混入的捣乱 buggremlins」应用运行在能持续维持所需配置与性能的环境中。但这一切还不够——我们必须确认终端用户真正获得了他们需要的体验。本阶段的核心任务包括持续监控应用性能Application Performance只有持续观测性能指标开发者才能对后续版本的功能增强做出更明智的决策更好地服务终端用户收集反馈闭环feedback wheel捕捉「已实现的功能」与「终端用户希望如何改进」之间的差距可靠性Reliability是关键词归根结底我们希望应用在需要时随时可用。这自然延伸到其他应被持续监控的领域——可观测性observability、安全security与数据管理data management其反馈可以持续用于增强、更新与发布应用。仓库中 2022/Days/Monitoring/Elastic Stack 目录提供了一套完整、可直接运行的 ELK/Elastic Stack 监控栈正是本阶段技术的落地样板几个关键配置文件足以说明可观测性的组成部分docker-compose.yaml以setup一次性服务初始化 Elasticsearch 内部用户再编排elasticsearch数据存储暴露9200/9300、kibana可视化等服务的启动顺序与网络elasticsearch/config/elasticsearch.yml声明集群名docker-cluster、监听地址0.0.0.0并开启 X-Pack 安全xpack.security.enabled: true——说明监控数据的存储层同样需要身份与访问控制kibana/config/kibana.yml配置 Kibana 服务名、监听地址与 Elasticsearch 地址http://elasticsearch:9200并通过kibana_system用户凭据认证logstash/pipeline/logstash.conf定义日志采集管道——input同时监听 Beats5044端口与 TCP5000端口output写入 Elasticsearchelasticsearch:9200extensions/metricbeat/config/metricbeat.yml通过 docker 模块以 10 秒周期采集容器cpu、memory、diskio、network等指标正是「持续监控应用性能」的指标来源。这套配置表明可观测性的实现路径是metricbeat/filebeat 采集指标与日志 → logstash 过滤与转发 → Elasticsearch 存储索引 → Kibana 可视化与告警形成完整的「采集—传输—存储—展示」链路。FinOps成本也是需要持续监控的指标社区成员尤其是 _ediri提出了一个常被忽视但同样重要的观点FinOps 团队也应参与这个持续过程。应用和数据总在某个地方运行与存储——当资源需求发生变化时必须持续监控成本确保云账单不会因此产生巨大的财务压力。这给监控阶段的启示是除了 CPU、内存、延迟等技术指标云成本Cloud Cost同样是一种需要「可观测」的运营指标成本治理FinOps与性能监控应并行运作。DevOps 不是头衔而是一种流程与文化原文在此处专门澄清了一个常见的认知误区虽然业界存在大量挂着「DevOps Engineer」头衔的岗位但这并不是给 DevOps 流程定位的理想方式。与社区同行交流后的共识是DevOps Engineer 这个头衔不应该是任何人的职业终点。真正值得推广的是任何岗位都应该采纳这里所讲的 DevOps 流程与文化。DevOps 应当被应用到许多不同的职位中例如云原生工程师 / 架构师Cloud-Native Engineer/Architect虚拟化管理员Virtualisation Admin云架构师 / 云工程师Cloud Architect/Engineer基础设施管理员Infrastructure Admin等等。上文之所以用「DevOps Engineer」作为叙述载体只是为了突出上述所有职位以及更多都会用到 DevOps 这套流程与范围。对学习者而言这意味着一份重要的心态转变不要把「DevOps」当成岗位说明书而应把它当作一套贯穿职业角色的工程文化与方法论。资源与下一步本系列 Readme 文件定位为学习工具始终欢迎补充资源。原文档给出的建议是完整观看以下主题的配套视频并结合正文文字吸收理解——内容包括持续开发Continuous Development原视频聚焦制造业但其精益lean文化可以很好地与 DevOps 对照学习持续测试Continuous Testing来自 IBM 的讲解持续集成Continuous Integration来自 IBM 的讲解持续监控Continuous Monitoring理解监控环节的完整脉络FinOps Foundation 的 FinOps 入门介绍了解成本治理这一新兴领域《凤凰项目》The Phoenix Project一本关于 IT、DevOps 与帮助企业取胜的小说适合作为延伸阅读非免费资源。如果你已经坚持到这里应该能够判断这片领域是否是你想去的地方了。下一站我们将继续深入生命周期的更多细节——第 4 天版本控制与 Git 专题。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐在 SkyPilot Kubernetes Pod 内启用 DockerDinD 与 Rootless BuildKit 完整指南在 SkyPilot Kubernetes Pod 内启用 DockerDinD 与 Rootless BuildKit 完整指南 SkyPilot 在 Ku文档/教程90DaysOfDevOps 第 5 天DevOps 应用生命周期全解析——从规划到监控的持续循环90DaysOfDevOps 第 5 天DevOps 应用生命周期全解析——从规划到监控的持续循环 导读 本文是 90DaysOfDevOps 学习路线20文档/教程90DaysOfDevOps 第 3 天以应用为中心的 DevOps 生命周期全景解析90DaysOfDevOps 第 3 天以应用为中心的 DevOps 生命周期全景解析 本篇文章基于 90DaysOfDevOps 仓库 2022/es/Da文档/教程上一篇first-contributions前端技术栈现代Web开发应用指南下一篇如何快速掌握计算神经科学NeuroMatch Academy课程完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考