运维-- 云计算与 CI/CD

前言更多运维相关知识蓝队技能学习_其实防守也摸鱼的博客-CSDN博客持续更新ing~介绍如果说前面的监控和日志是运维的“眼睛”那云计算和 CI/CD 就是运维的“双手”和“高速公路”。它们彻底改变了我们管理服务器和发布软件的方式。☁️ 云计算告别“买服务器”拥抱“租算力”在云时代之前上线一个应用需要经历一个漫长的流程申请预算 - 采购物理机 - 机房上架 - 安装系统 - 配置网络。这个过程动辄需要几周甚至几个月。云计算的出现把这一切变成了像“用水用电”一样简单。你只需要在阿里云、AWS 这样的云平台网页上点几下鼠标或者敲几行命令几分钟内就能获得一台配置好的服务器。作为云运维你的工作重心从“修硬件”变成了“管资源”。核心工作主要包括计算资源 (ECS/EC2)管理云上的虚拟机。你需要知道如何创建、配置、启动、停止这些实例以及如何根据业务流量设置弹性伸缩比如双十一流量暴增时自动增加服务器流量低谷时自动减少从而节省成本。网络规划 (VPC)在云上构建一个隔离的、属于你自己的私有网络环境。你需要规划子网、配置路由表和安全组云上的防火墙确保你的服务器安全且能互相通信。存储与数据库 (OSS/RDS)管理云盘、对象存储用来存图片、视频等大文件以及云数据库。云平台会帮你搞定数据库的备份、主从高可用等底层运维工作让你能更专注于业务。安全与监控 (RAM/CloudMonitor)管理用户的访问权限谁能操作哪些资源并利用云平台自带的监控工具查看资源的使用情况。一句话总结云计算让你不再为硬件故障发愁而是专注于如何更高效、更安全、更省钱地使用云上的资源。 CI/CD打通开发与运维的“自动化高速公路”有了云服务器发布软件的速度变快了但流程本身可能还是很痛苦。在没有 CI/CD 的传统模式下开发写完代码后需要手动打包然后找运维申请上线。运维拿到代码包再手动登录服务器执行一系列复杂的命令来部署。这个过程不仅慢而且极易出错比如漏掉一个配置文件、敲错一个命令。CI/CD持续集成/持续交付就是为了解决这个问题而生的。它是一条自动化的“高速公路”让代码从开发人员的电脑一路畅通无阻地跑到生产环境的服务器上。它主要分为两个阶段 CI持续集成代码的“自动质检员”CI 的核心思想是开发人员应该频繁地比如每天把代码合并到主干分支。每次合并都会自动触发一个流程自动拉取代码从 Git 仓库如 GitLab、GitHub拉取最新的代码。自动编译构建把代码编译成可执行的程序或 Docker 镜像。自动运行测试运行单元测试、代码质量扫描等确保新代码没有引入 Bug。如果任何一步失败系统会立刻通知开发人员“你提交的代码有问题请修改” 这样就能在问题刚产生时就发现并修复而不是等到上线后才爆炸。 CD持续交付/部署应用的“自动快递员”当代码通过了 CI 的“质检”后就会进入 CD 阶段。持续交付 (Continuous Delivery)自动将通过测试的代码部署到测试环境或预发布环境。最后一步发布到生产环境通常需要运维人员点击一个“批准”按钮以保证风险可控。持续部署 (Continuous Deployment)更进一步的自动化。只要代码通过了所有测试就会全自动地发布到生产环境完全不需要人工干预。实现 CI/CD 的常用工具Jenkins老牌且功能极其强大的开源工具插件生态非常丰富几乎能对接任何系统。GitLab CI / GitHub Actions与代码仓库深度集成配置简单通常只需在代码库里写一个 YAML 配置文件是目前非常流行的选择。 它们是如何协同工作的在实际的现代企业里云计算和 CI/CD 是紧密结合的开发提交代码开发人员将新功能代码提交到 GitLab 仓库。触发流水线GitLab 仓库检测到新代码自动触发 CI/CD 流水线比如 Jenkins 或 GitLab CI。CI 阶段流水线自动拉取代码进行编译、打包比如打包成一个 Docker 镜像并运行自动化测试。CD 阶段测试通过后流水线自动将这个 Docker 镜像推送到镜像仓库然后调用 Kubernetes (K8s) 的接口将新版本的容器自动部署到云上的 K8s 集群中。上线完成整个过程可能只需要几分钟用户就访问到了最新的功能。一句话总结CI/CD 实现了软件交付的自动化而云计算提供了弹性的运行环境。两者结合让软件发布变得像发朋友圈一样简单、快速、可靠。到这里整个现代运维的核心知识体系Linux基础 - 自动化与容器 - 监控日志 - 云与CI/CD咱们就全部打通了实战既然前面已经体验过 Docker 和 Ansible 的“手感”了那咱们就趁热打铁直接写一个最简单的 CI/CD 流水线。为了让你最快上手我们使用目前最流行、且与代码仓库深度集成的GitHub Actions。它不需要你额外安装任何复杂的软件只要有一个 GitHub 账号在网页上点几下就能跑起来。我们将模拟一个最经典的场景当开发人员把代码推送到 GitHub 后系统自动拉取代码、运行测试最后自动把应用部署到云服务器上。️ 准备工作打通 GitHub 与云服务器的“安全通道”在让 GitHub 自动帮你部署代码之前必须先赋予它登录你服务器的权限。我们通常使用 SSH 密钥来实现免密登录。在云服务器上生成密钥对登录到你的云服务器执行以下命令生成一对 SSH 密钥ssh-keygen -t ed25519 -C github-actions(一路回车即可。这会在~/.ssh/目录下生成两个文件id_ed25519是私钥id_ed25519.pub是公钥)将公钥加入服务器的授权列表cat ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys(解释这相当于把一把“备用钥匙”交给了 GitHub让它以后能合法登录)在 GitHub 仓库配置 Secrets保管机密信息回到你的 GitHub 项目页面进入Settings-Secrets and variables-Actions。点击New repository secret添加以下几个变量SERVER_HOST你的云服务器公网 IP。SERVER_USER服务器登录用户名比如root或ubuntu。SERVER_SSH_KEY把刚才在服务器上生成的私钥(id_ed25519文件里的全部内容) 复制粘贴进来。 编写流水线“剧本”在 GitHub 中CI/CD 的配置文件是一个 YAML 文件。在你的项目根目录下创建这样一个文件路径.github/workflows/deploy.yml。把下面这段“剧本”复制进去name: Auto Deploy Pipeline # 1. 触发条件当代码推送到 main 分支时自动触发这条流水线 on: push: branches: [ main ] jobs: # 2. 定义一个名为 Test 的任务 Test: runs-on: ubuntu-latest steps: - name: Checkout Code uses: actions/checkoutv4 # 官方动作拉取你的代码 - name: Run Tests run: | echo 正在自动运行单元测试... # 这里可以写 pytest、npm test 等真实的测试命令 echo 测试通过 # 3. 定义一个名为 Deploy 的任务必须在 Test 成功后才能执行 Deploy: needs: Test runs-on: ubuntu-latest steps: - name: Deploy to Server via SSH uses: appleboy/ssh-actionmaster # 使用第三方开源动作通过 SSH 连接服务器 with: host: ${{ secrets.SERVER_HOST }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SERVER_SSH_KEY }} script: | echo 成功登录云服务器开始自动部署... # 这里可以写拉取 Docker 镜像、重启服务、执行 Ansible 脚本等真实部署命令 echo 部署完成应用已上线 见证奇迹代码自动跑起来提交代码把这个.github文件夹和里面的代码提交并推送到你的 GitHub 仓库的main分支。查看运行过程打开你的 GitHub 仓库页面点击顶部的Actions标签页。你会看到一个绿色的圆点在转动这就是你的流水线正在运行查看日志点击进去你能清晰地看到两个阶段第一个阶段Test自动拉取了代码并打印了“测试通过”。第二个阶段Deploy自动通过 SSH 登录了你的云服务器并打印了“部署完成”。整个过程不到一分钟完全不需要人工干预 总结流水线是如何串联起所有知识的通过这个极简的流水线你会发现之前学过的知识全都串联起来了开发人员提交了包含Docker配置的代码。CI/CD 流水线自动接管运行测试保证质量。测试通过后流水线通过 SSH 登录到云上的Linux 服务器。在服务器上执行命令可能还会调用Ansible来更新配置或者重启K8s集群里的容器。最后Prometheus和ELK默默接管继续监控和记录新上线应用的健康状态。这就是现代 DevOps 的魅力用代码管理一切让机器去做机器擅长的事让人去解决更有创造力的问题。