【从零搭建聊天机器人】05 自动化运维使用 GitHub Actions 实现 CI/CD 云端自动部署写在前面欢迎来到《从零搭建聊天机器人》系列教学的第五章也是我们系统架构中最具“现代化工程师”色彩的一课在传统的日常更新中你不仅要在本地改还要连上云服务器手动执行git pull、停止老进程、再重新启动新进程……这一套操作既繁琐又容易出错。本章我们将引入现代软件开发的核心利器——CI/CD持续集成与持续部署。我们将利用GitHub Actions打造一条自动化流水线只要你在本地电脑一敲git push云端的 AWS 服务器就会自动完成代码拉取、环境更新并重启后台服务。真正实现“代码一推服务起飞”文章目录 学习目标 (Intended Learning Outcomes)01 解决痛点让机器人在云端“后台长驻”nohup 命令说明02 配置 GitHub Secrets授予自动化部署权限操作步骤03 编写 GitHub Actions 工作流 (YAML 脚本)1. 创建工作流文件2. 编写自动化剧本触发条件当有新的 commit 被 push 到 main 分支时自动触发04 触发自动部署与流水线测试05 踩坑实录自动化部署中的那些致命报错❌ 错误一Telegram API 报错 Conflict: terminated by other getUpdates request❌ 错误二Actions 日志提示 git pull: Please commit your changes or stash them❌ 错误三YAML 解析错误❌ 错误四SSH Key 解析错误 06. 深度思考题与参考答案 (Reflection Solutions) 文章摘要 学习目标 (Intended Learning Outcomes)学完本章节实验你将能够掌握以下核心技能进程管理掌握在 Linux 中使用nohup使程序在后台持久运行的方法解决“断开连接即死机”的问题。安全凭证管理掌握 GitHub Secrets 的配置实现第三方服务安全免密访问 AWS 资源。流水线搭建编写 YAML 工作流文件配置 GitHub Actions 自动化部署管道Automate deployment using GitHub Actions。异常处理掌握解决自动化部署中常见的进程冲突如 Telegram API 抢占与 Git 合并冲突问题。01 解决痛点让机器人在云端“后台长驻”GitHub Actions 和 CI/CD 简介GitHub Actions 是一个 CI/CD 平台可以自动化构建、测试和部署流水线。持续集成 (CI)每次提交都会触发自动化构建/测试以确保顺利集成。持续交付 (CD)一旦验证通过代码会自动部署到目标环境这里是 AWS EC2。工作流程组件工作流程自动化程序存储于 .github/workflows 中。事件触发条件例如提交或推送操作。任务收集在跑轮上执行的各个步骤。步骤单个任务操作或命令。动作可重复使用的命令块。运行器负责执行任务的服务器。为什么终端关闭机器人就停止回复了当你通过 SSH 连接到 EC2 时实际上是开启了一个会话Session。你在终端里运行的python chatbot.py依附于这个会话。当你直接关闭终端时Linux 会向该会话下的所有程序发送一个名叫SIGHUP挂断的死亡信号机器人自然就跟着殉情了。要让机器人 24 小时独立运行我们需要把它挂载到系统后台。nohup命令说明nohuppython chatbot.pychatbot.log21nohupNo Hang Up 的缩写意思是“忽略挂断信号”告诉系统即使关闭终端也不要杀掉这个程序。 chatbot.log因为程序跑在后台你在屏幕上将看不到任何日志了。这个指令把原本输出在屏幕上的日志全部重定向保存到一个叫chatbot.log的文件中。21将“错误信息”也一并塞进这个日志文件里。关键标志代表将其放入系统后台运行。敲下回车后终端会返回一串数字比如[1] 12345这是程序的进程 ID (PID)。现在你可以放心地直接关掉 SSH 终端窗口了拿出手机测试你会发现机器人依然坚挺在线02 配置 GitHub Secrets授予自动化部署权限现在我们要让 GitHub 帮我们自动登录 EC2 服务器并执行更新命令。这就要求 GitHub 必须知道你的服务器 IP、用户名以及那把极其私密的.pem钥匙。为了安全我们绝对不能把这些写在代码里而是要存在 GitHub 的“保险箱”——Secrets中。操作步骤打开你的 GitHub 网页进入Chatbot项目仓库。点击上方的Settings设置选项卡。在左侧边栏找到Secrets and variables➔ 选择Actions。点击绿色的New repository secret按钮我们需要依次创建三个机密变量变量 1EC2_HOSTNameEC2_HOSTSecret填入你的 EC2 公网 DNS 地址例如ec2-18-167-37-17.ap-east-1.compute.amazonaws.com变量 2EC2_USERNameEC2_USERSecret填入ec2-user变量 3EC2_SSH_KEYNameEC2_SSH_KEYSecret用本地电脑的记事本或 VS Code 打开你的.pem密钥文件将里面所有的内容包括-----BEGIN...和...END KEY-----以及所有的换行一字不落地全部复制进去。03 编写 GitHub Actions 工作流 (YAML 脚本)请打开EC2确保EC2的状态为running准备工作就绪我们要开始写指挥 GitHub Actions 干活的剧本了。1. 创建工作流文件回到你的本地电脑Windows在Chatbot项目的根目录下新建一个文件夹树用Git Bash执行代码mkdir-p.github/workflows或手动创建创建一个名为.github的文件夹 ➔ 在它里面创建一个叫workflows的文件夹然后在里面新建一个文件叫deploy.yml。最终的路径结构必须严格是.github/workflows/deploy.yml2. 编写自动化剧本用你的代码编辑器打开deploy.yml将以下内容完整复制进去。请注意YAML 文件对空格极其敏感请绝对不要乱按 Tab 键或删改缩进触发条件当有新的 commit 被 push 到 main 分支时自动触发**注意**这里的scrects的变量必须与你创建的名称一致否则在连接EC2时候会出现ssh为空等问题name:AWS EC2 Deployon:push:branches:-mainjobs:deploy:name:Deploy to EC2runs-on:ubuntu-latest# 必须指定在 ubuntu-latest 虚拟环境中运行构建steps:-name:Checkout code# 第一步拉取仓库代码uses:actions/checkoutv3-name:Setup SSH# 第二步借助社区经典的 SSH 动作组件加载我们的私钥uses:webfactory/ssh-agentv0.7.0with:ssh-private-key:${{secrets.EC2_SSH_KEY}}-name:Deploy application# 第三步通过 SSH 登录云服务器串行执行自动化部署命令run:|ssh -o StrictHostKeyCheckingno ${{ secrets.EC2_USER }}${{ secrets.EC2_HOST }} EOFecho 开始进入云端项目代码目录... cd ~/ChatBot_Telegram/Chatbot echo 拉取 GitHub 远程主分支最新代码... git pull origin main echo 激活云端虚拟环境并更新依赖清单... source venv/bin/activate pip install-r requirements.txt echo 【核心防御】安全清理旧的机器人后台进程防止多实例 Token 抢占冲突... pkill-f python chatbot.py||true echo 在虚拟环境内利用 nohup 重新在后台拉起新版机器人程序... nohup ~/ChatBot_Telegram/Chatbot/venv/bin/python chatbot.pyapp.log 21 echo 云端自动化部署结束 EOF保存文件。04 触发自动部署与流水线测试见证奇迹的时刻到了。我们现在要在本地做一点小修改并把代码推送到云端。修改代码打开你本地的chatbot.py把机器人的某些回复逻辑稍微改一下比如在回复前加上一句[云端自动化更新版]:保存文件。提交并推送在本地 Git Bash 中执行我们最熟悉的三连gitadd.gitcommit-mAdd GitHub Actions workflow for EC2 deployment#如果之前修改了requirements.txt文件请先pullgitpullgitpush origin main观看自动化演出立刻打开你的 GitHub 仓库网页点击上方的Actions选项卡。你会看到一个黄色的圆圈正在旋转这就是 GitHub 正在按照你的剧本自动登录服务器、拉取代码、杀掉旧进程并启动新版本。当圆圈变成绿色的对勾 (✅)时说明部署成功部署成功后您的聊天机器人将在 EC2 实例上运行。请使用以下命令验证在 EC2 实例中运行的聊天机器人的 Python 进程ssh-ikeypair_chatbot.pem你的pem文件名ec2-user(你的EC2 DNS)ps-ef|greppython您应该看到以下输出ec2-user372711006:02 ? 00:00:00 /home/ec2user/chatbot_comp7940/venv/bin/python chatbot.py现在立刻拿出手机给机器人发消息如果它回复了你刚刚修改的新内容恭喜你你的 CI/CD 工业级流水线已经全线贯通注意使用完毕后记得关闭EC2防止流量浪费05 踩坑实录自动化部署中的那些致命报错自动化部署虽然爽但在调试配置阶段极其容易出现以下三个让人抓狂的问题❌ 错误一Telegram API 报错Conflict: terminated by other getUpdates request报错现象通过 Actions 部署成功后机器人突然毫无反应。进入云端用cat chatbot.log查看日志发现满屏幕的Conflict: terminated by other getUpdates...红色报错。原因分析这是 Telegram 机器人的专属大坑。由于前几次测试时我们在后台启动了机器人但在执行新的部署脚本时没有把旧的进程杀掉就直接启动了新的。导致两份一样的代码在云端同时运行它们在疯狂争抢同一个 Bot Token。Telegram 官方服务器发现有两个客户端同时拉取数据就会触发安全机制直接把双方都强制踢下线。解决方案在 YAML 脚本的script部分在启动新进程之前必须加上这一行“杀手”命令pkill -f chatbot.py || true。这句命令的意思是精准狙击并杀掉所有名字里带chatbot.py的后台进程清空战场后再启动新代码。❌ 错误二Actions 日志提示git pull: Please commit your changes or stash them报错现象GitHub Actions 运行失败打红叉。点开详情日志发现卡在git pull这一步提示有未提交的更改。原因分析这是因为你在上一章中为了修复依赖问题直接在云端 EC2 里面修改过文件比如手动改过requirements.txt或config.ini导致云端的代码状态与 GitHub 上的状态发生了分叉和冲突Git 为了保护你的文件拒绝了直接覆盖。解决方案登录云端服务器进入项目目录执行强制覆盖命令让云端彻底向 GitHub 对齐gitpull(注如果你的config.ini因为被.gitignore保护而没有被影响那么上述操作不会删除你的配置文件可以放心执行。)❌ 错误三YAML 解析错误报错现象刚把代码 push 上去Actions 连跑都没跑就直接报错。原因分析YAML 格式对空格有极度严格的要求比如uses:和with:的相对位置。可能在复制粘贴时多打了一个空格或者不小心按了Tab键。解决方案强烈推荐在本地使用 VS Code 等现代编辑器它们通常会自带 YAML 语法高亮和缩进对其线检查。确保每一层级的缩进都是标准的2 个空格。❌ 错误四SSH Key 解析错误报错现象刚把代码 push 上去Actions 出现SSH错误显示ssh为空。原因分析在deploy.yml文件中没有把secrets的属性改为在github中创建的变量解决方案修改变量对应github上的变量名称然后重新push上github。 06. 深度思考题与参考答案 (Reflection Solutions)自动化部署看似神奇但本质依然是一行行脚本的执行。请结合本章的实战经历思考以下三个涉及架构、安全与排错的核心问题❓ 思考题 1CI/CD 的本质与价值题目 请用你自己的语言简述什么是 CI/CD在我们这个聊天机器人项目中GitHub Actions 具体扮演了什么角色它替我们节省了哪些传统运维中的手动操作步骤✅ 参考答案CI/CD 的本质CI持续集成指代码提交后自动进行构建和测试CD持续部署/交付指测试通过后自动将代码发布到生产服务器。它的本质是将人类枯燥、重复且易错的手动发布流程转化为由机器严格执行的自动化流水线。扮演的角色GitHub Actions 扮演了一个“不知疲倦的云端机器人运维管家”或者说“自动化脚本执行引擎”。节省的步骤它让我们告别了以下繁琐的手动闭环打开终端输入 SSH 命令及私钥登录云服务器 ➔cd 切换到项目目录 ➔手动敲 git pull 同步代码 ➔激活 Python 虚拟环境 ➔运行 pip install 检查并更新依赖 ➔查找并 kill 掉旧的机器人进程 ➔再次用 nohup 挂载新进程。现在这一切只需本地的一句 git push 即可全自动完成。❓ 思考题 2云原生时代的安全底线题目 在编写 deploy.yml 部署脚本时为什么我们绝对不能图省事直接把 EC2 的公网 IP 地址、用户名和极其私密的 .pem 密钥以明文Plaintext的形式写在 YAML 文件里配置 GitHub Secrets 的根本原理和作用是什么✅ 参考答案明文硬编码的毁灭性后果deploy.yml 文件是存放在项目代码库的 .github/workflows 目录下的它与你的业务代码一样受 Git 版本控制。如果直接写明文一旦你的仓库是公开的Public或者未来代码泄露任何人都能直接拿到你云服务器的最高控制权Root 权限。黑客可以轻易登录你的 AWS 注入勒索病毒、盗取隐私数据或利用你的算力疯狂挖矿导致你背负巨额的云服务账单。GitHub Secrets 的原理与作用GitHub Secrets 相当于一个完全脱离版本控制的“云端保险箱”。它的作用是环境变量的动态安全注入。存入 Secrets 的密钥会被高强度加密只有在 Actions 流水线运行的短暂瞬间才会被提取到内存中供脚本使用并且一旦使用完毕立即销毁。同时它会自动在所有的部署日志中将密码脱敏显示为 ***彻底斩断了密钥泄露的途径。❓ 思考题 3流水线“假阳性”排错实战题目 假设你刚 push 了一段新代码GitHub 网页端的 Actions 流水线跑完后显示了绿色的对勾✅ 部署成功但你拿出手机给 Telegram 机器人发消息它却毫无反应或者依然在回复旧版本的逻辑。请结合 Linux 后台运行机制推理一下最有可能导致这种现象的原因是什么你应该如何去排查✅ 参考答案这属于典型的**“流水线假阳性False Positive”**。Actions 显示绿勾仅仅代表 YAML 脚本里的 Bash 命令行执行完毕且没有抛出致命错误退出的状态码但这并不等同于你的 Python 业务代码成功运行了可能原因 1旧进程未被杀死端口/Token 抢占冲突。如果在 YAML 脚本里漏写了 pkill -f chatbot.py会导致新代码虽然下载了但原本在后台运行的旧进程依然存活。新进程由于与旧进程抢占同一个 Telegram API 端口或 Token 而启动失败或双双阵亡此时你调用的依然是没死透的旧机器人。可能原因 2Python 代码自身存在致命的语法错误。因为我们在 YAML 最后一行使用的是 nohup python chatbot.py chatbot.log 21 。请注意结尾的 符号它代表把程序丢到后台执行Bash 脚本一执行完这句就会立刻认为任务完成并宣告部署成功。此时如果你的 Python 代码里少写了一个括号导致瞬间崩溃Actions 是察觉不到的。排查方案立刻通过 SSH 登录 EC2 服务器进入项目目录执行 cat chatbot.log 命令查看你重定向的日志文件里面一定记录了 Python 抛出的具体报错追踪栈Traceback 文章摘要本文是《从零搭建聊天机器人》系列教程的第五章核心目标是利用GitHub Actions为部署在 AWS EC2 上的 Telegram 聊天机器人构建一套完整的CI/CD持续集成与持续部署自动化运维流水线。核心内容总结如下解决后台长驻问题通过nohup命令让机器人在 SSH 会话关闭后依然能在云端后台持久运行并解释了其原理忽略SIGHUP信号。安全凭证管理详细指导如何在 GitHub 仓库的 Secrets 中安全配置 EC2 服务器的连接信息主机、用户名、SSH 私钥避免敏感信息硬编码在代码中。构建自动化流水线提供了完整的deploy.yml工作流脚本该脚本在代码推送到main分支时自动触发执行拉取代码、更新依赖、杀死旧进程、重启新服务等一系列部署操作。实战测试与验证引导读者通过修改代码并推送触发自动化部署并通过检查 GitHub Actions 运行状态和服务器进程来验证部署是否成功。常见错误与排错总结了自动化部署中可能遇到的四大典型问题如进程冲突、Git 合并冲突、YAML 格式错误、SSH 密钥配置错误并提供了具体的解决方案和排查思路。深度思考通过三个思考题引导读者深入理解 CI/CD 的价值、GitHub Secrets 的安全原理以及如何排查“部署成功但服务未更新”的“假阳性”问题。最终成果实现“代码一推服务起飞”的自动化目标将传统繁琐的云端手动更新流程登录、拉取、重启完全自动化显著提升开发效率和部署可靠性。。
聊天机器人搭建05
【从零搭建聊天机器人】05 自动化运维使用 GitHub Actions 实现 CI/CD 云端自动部署写在前面欢迎来到《从零搭建聊天机器人》系列教学的第五章也是我们系统架构中最具“现代化工程师”色彩的一课在传统的日常更新中你不仅要在本地改还要连上云服务器手动执行git pull、停止老进程、再重新启动新进程……这一套操作既繁琐又容易出错。本章我们将引入现代软件开发的核心利器——CI/CD持续集成与持续部署。我们将利用GitHub Actions打造一条自动化流水线只要你在本地电脑一敲git push云端的 AWS 服务器就会自动完成代码拉取、环境更新并重启后台服务。真正实现“代码一推服务起飞”文章目录 学习目标 (Intended Learning Outcomes)01 解决痛点让机器人在云端“后台长驻”nohup 命令说明02 配置 GitHub Secrets授予自动化部署权限操作步骤03 编写 GitHub Actions 工作流 (YAML 脚本)1. 创建工作流文件2. 编写自动化剧本触发条件当有新的 commit 被 push 到 main 分支时自动触发04 触发自动部署与流水线测试05 踩坑实录自动化部署中的那些致命报错❌ 错误一Telegram API 报错 Conflict: terminated by other getUpdates request❌ 错误二Actions 日志提示 git pull: Please commit your changes or stash them❌ 错误三YAML 解析错误❌ 错误四SSH Key 解析错误 06. 深度思考题与参考答案 (Reflection Solutions) 文章摘要 学习目标 (Intended Learning Outcomes)学完本章节实验你将能够掌握以下核心技能进程管理掌握在 Linux 中使用nohup使程序在后台持久运行的方法解决“断开连接即死机”的问题。安全凭证管理掌握 GitHub Secrets 的配置实现第三方服务安全免密访问 AWS 资源。流水线搭建编写 YAML 工作流文件配置 GitHub Actions 自动化部署管道Automate deployment using GitHub Actions。异常处理掌握解决自动化部署中常见的进程冲突如 Telegram API 抢占与 Git 合并冲突问题。01 解决痛点让机器人在云端“后台长驻”GitHub Actions 和 CI/CD 简介GitHub Actions 是一个 CI/CD 平台可以自动化构建、测试和部署流水线。持续集成 (CI)每次提交都会触发自动化构建/测试以确保顺利集成。持续交付 (CD)一旦验证通过代码会自动部署到目标环境这里是 AWS EC2。工作流程组件工作流程自动化程序存储于 .github/workflows 中。事件触发条件例如提交或推送操作。任务收集在跑轮上执行的各个步骤。步骤单个任务操作或命令。动作可重复使用的命令块。运行器负责执行任务的服务器。为什么终端关闭机器人就停止回复了当你通过 SSH 连接到 EC2 时实际上是开启了一个会话Session。你在终端里运行的python chatbot.py依附于这个会话。当你直接关闭终端时Linux 会向该会话下的所有程序发送一个名叫SIGHUP挂断的死亡信号机器人自然就跟着殉情了。要让机器人 24 小时独立运行我们需要把它挂载到系统后台。nohup命令说明nohuppython chatbot.pychatbot.log21nohupNo Hang Up 的缩写意思是“忽略挂断信号”告诉系统即使关闭终端也不要杀掉这个程序。 chatbot.log因为程序跑在后台你在屏幕上将看不到任何日志了。这个指令把原本输出在屏幕上的日志全部重定向保存到一个叫chatbot.log的文件中。21将“错误信息”也一并塞进这个日志文件里。关键标志代表将其放入系统后台运行。敲下回车后终端会返回一串数字比如[1] 12345这是程序的进程 ID (PID)。现在你可以放心地直接关掉 SSH 终端窗口了拿出手机测试你会发现机器人依然坚挺在线02 配置 GitHub Secrets授予自动化部署权限现在我们要让 GitHub 帮我们自动登录 EC2 服务器并执行更新命令。这就要求 GitHub 必须知道你的服务器 IP、用户名以及那把极其私密的.pem钥匙。为了安全我们绝对不能把这些写在代码里而是要存在 GitHub 的“保险箱”——Secrets中。操作步骤打开你的 GitHub 网页进入Chatbot项目仓库。点击上方的Settings设置选项卡。在左侧边栏找到Secrets and variables➔ 选择Actions。点击绿色的New repository secret按钮我们需要依次创建三个机密变量变量 1EC2_HOSTNameEC2_HOSTSecret填入你的 EC2 公网 DNS 地址例如ec2-18-167-37-17.ap-east-1.compute.amazonaws.com变量 2EC2_USERNameEC2_USERSecret填入ec2-user变量 3EC2_SSH_KEYNameEC2_SSH_KEYSecret用本地电脑的记事本或 VS Code 打开你的.pem密钥文件将里面所有的内容包括-----BEGIN...和...END KEY-----以及所有的换行一字不落地全部复制进去。03 编写 GitHub Actions 工作流 (YAML 脚本)请打开EC2确保EC2的状态为running准备工作就绪我们要开始写指挥 GitHub Actions 干活的剧本了。1. 创建工作流文件回到你的本地电脑Windows在Chatbot项目的根目录下新建一个文件夹树用Git Bash执行代码mkdir-p.github/workflows或手动创建创建一个名为.github的文件夹 ➔ 在它里面创建一个叫workflows的文件夹然后在里面新建一个文件叫deploy.yml。最终的路径结构必须严格是.github/workflows/deploy.yml2. 编写自动化剧本用你的代码编辑器打开deploy.yml将以下内容完整复制进去。请注意YAML 文件对空格极其敏感请绝对不要乱按 Tab 键或删改缩进触发条件当有新的 commit 被 push 到 main 分支时自动触发**注意**这里的scrects的变量必须与你创建的名称一致否则在连接EC2时候会出现ssh为空等问题name:AWS EC2 Deployon:push:branches:-mainjobs:deploy:name:Deploy to EC2runs-on:ubuntu-latest# 必须指定在 ubuntu-latest 虚拟环境中运行构建steps:-name:Checkout code# 第一步拉取仓库代码uses:actions/checkoutv3-name:Setup SSH# 第二步借助社区经典的 SSH 动作组件加载我们的私钥uses:webfactory/ssh-agentv0.7.0with:ssh-private-key:${{secrets.EC2_SSH_KEY}}-name:Deploy application# 第三步通过 SSH 登录云服务器串行执行自动化部署命令run:|ssh -o StrictHostKeyCheckingno ${{ secrets.EC2_USER }}${{ secrets.EC2_HOST }} EOFecho 开始进入云端项目代码目录... cd ~/ChatBot_Telegram/Chatbot echo 拉取 GitHub 远程主分支最新代码... git pull origin main echo 激活云端虚拟环境并更新依赖清单... source venv/bin/activate pip install-r requirements.txt echo 【核心防御】安全清理旧的机器人后台进程防止多实例 Token 抢占冲突... pkill-f python chatbot.py||true echo 在虚拟环境内利用 nohup 重新在后台拉起新版机器人程序... nohup ~/ChatBot_Telegram/Chatbot/venv/bin/python chatbot.pyapp.log 21 echo 云端自动化部署结束 EOF保存文件。04 触发自动部署与流水线测试见证奇迹的时刻到了。我们现在要在本地做一点小修改并把代码推送到云端。修改代码打开你本地的chatbot.py把机器人的某些回复逻辑稍微改一下比如在回复前加上一句[云端自动化更新版]:保存文件。提交并推送在本地 Git Bash 中执行我们最熟悉的三连gitadd.gitcommit-mAdd GitHub Actions workflow for EC2 deployment#如果之前修改了requirements.txt文件请先pullgitpullgitpush origin main观看自动化演出立刻打开你的 GitHub 仓库网页点击上方的Actions选项卡。你会看到一个黄色的圆圈正在旋转这就是 GitHub 正在按照你的剧本自动登录服务器、拉取代码、杀掉旧进程并启动新版本。当圆圈变成绿色的对勾 (✅)时说明部署成功部署成功后您的聊天机器人将在 EC2 实例上运行。请使用以下命令验证在 EC2 实例中运行的聊天机器人的 Python 进程ssh-ikeypair_chatbot.pem你的pem文件名ec2-user(你的EC2 DNS)ps-ef|greppython您应该看到以下输出ec2-user372711006:02 ? 00:00:00 /home/ec2user/chatbot_comp7940/venv/bin/python chatbot.py现在立刻拿出手机给机器人发消息如果它回复了你刚刚修改的新内容恭喜你你的 CI/CD 工业级流水线已经全线贯通注意使用完毕后记得关闭EC2防止流量浪费05 踩坑实录自动化部署中的那些致命报错自动化部署虽然爽但在调试配置阶段极其容易出现以下三个让人抓狂的问题❌ 错误一Telegram API 报错Conflict: terminated by other getUpdates request报错现象通过 Actions 部署成功后机器人突然毫无反应。进入云端用cat chatbot.log查看日志发现满屏幕的Conflict: terminated by other getUpdates...红色报错。原因分析这是 Telegram 机器人的专属大坑。由于前几次测试时我们在后台启动了机器人但在执行新的部署脚本时没有把旧的进程杀掉就直接启动了新的。导致两份一样的代码在云端同时运行它们在疯狂争抢同一个 Bot Token。Telegram 官方服务器发现有两个客户端同时拉取数据就会触发安全机制直接把双方都强制踢下线。解决方案在 YAML 脚本的script部分在启动新进程之前必须加上这一行“杀手”命令pkill -f chatbot.py || true。这句命令的意思是精准狙击并杀掉所有名字里带chatbot.py的后台进程清空战场后再启动新代码。❌ 错误二Actions 日志提示git pull: Please commit your changes or stash them报错现象GitHub Actions 运行失败打红叉。点开详情日志发现卡在git pull这一步提示有未提交的更改。原因分析这是因为你在上一章中为了修复依赖问题直接在云端 EC2 里面修改过文件比如手动改过requirements.txt或config.ini导致云端的代码状态与 GitHub 上的状态发生了分叉和冲突Git 为了保护你的文件拒绝了直接覆盖。解决方案登录云端服务器进入项目目录执行强制覆盖命令让云端彻底向 GitHub 对齐gitpull(注如果你的config.ini因为被.gitignore保护而没有被影响那么上述操作不会删除你的配置文件可以放心执行。)❌ 错误三YAML 解析错误报错现象刚把代码 push 上去Actions 连跑都没跑就直接报错。原因分析YAML 格式对空格有极度严格的要求比如uses:和with:的相对位置。可能在复制粘贴时多打了一个空格或者不小心按了Tab键。解决方案强烈推荐在本地使用 VS Code 等现代编辑器它们通常会自带 YAML 语法高亮和缩进对其线检查。确保每一层级的缩进都是标准的2 个空格。❌ 错误四SSH Key 解析错误报错现象刚把代码 push 上去Actions 出现SSH错误显示ssh为空。原因分析在deploy.yml文件中没有把secrets的属性改为在github中创建的变量解决方案修改变量对应github上的变量名称然后重新push上github。 06. 深度思考题与参考答案 (Reflection Solutions)自动化部署看似神奇但本质依然是一行行脚本的执行。请结合本章的实战经历思考以下三个涉及架构、安全与排错的核心问题❓ 思考题 1CI/CD 的本质与价值题目 请用你自己的语言简述什么是 CI/CD在我们这个聊天机器人项目中GitHub Actions 具体扮演了什么角色它替我们节省了哪些传统运维中的手动操作步骤✅ 参考答案CI/CD 的本质CI持续集成指代码提交后自动进行构建和测试CD持续部署/交付指测试通过后自动将代码发布到生产服务器。它的本质是将人类枯燥、重复且易错的手动发布流程转化为由机器严格执行的自动化流水线。扮演的角色GitHub Actions 扮演了一个“不知疲倦的云端机器人运维管家”或者说“自动化脚本执行引擎”。节省的步骤它让我们告别了以下繁琐的手动闭环打开终端输入 SSH 命令及私钥登录云服务器 ➔cd 切换到项目目录 ➔手动敲 git pull 同步代码 ➔激活 Python 虚拟环境 ➔运行 pip install 检查并更新依赖 ➔查找并 kill 掉旧的机器人进程 ➔再次用 nohup 挂载新进程。现在这一切只需本地的一句 git push 即可全自动完成。❓ 思考题 2云原生时代的安全底线题目 在编写 deploy.yml 部署脚本时为什么我们绝对不能图省事直接把 EC2 的公网 IP 地址、用户名和极其私密的 .pem 密钥以明文Plaintext的形式写在 YAML 文件里配置 GitHub Secrets 的根本原理和作用是什么✅ 参考答案明文硬编码的毁灭性后果deploy.yml 文件是存放在项目代码库的 .github/workflows 目录下的它与你的业务代码一样受 Git 版本控制。如果直接写明文一旦你的仓库是公开的Public或者未来代码泄露任何人都能直接拿到你云服务器的最高控制权Root 权限。黑客可以轻易登录你的 AWS 注入勒索病毒、盗取隐私数据或利用你的算力疯狂挖矿导致你背负巨额的云服务账单。GitHub Secrets 的原理与作用GitHub Secrets 相当于一个完全脱离版本控制的“云端保险箱”。它的作用是环境变量的动态安全注入。存入 Secrets 的密钥会被高强度加密只有在 Actions 流水线运行的短暂瞬间才会被提取到内存中供脚本使用并且一旦使用完毕立即销毁。同时它会自动在所有的部署日志中将密码脱敏显示为 ***彻底斩断了密钥泄露的途径。❓ 思考题 3流水线“假阳性”排错实战题目 假设你刚 push 了一段新代码GitHub 网页端的 Actions 流水线跑完后显示了绿色的对勾✅ 部署成功但你拿出手机给 Telegram 机器人发消息它却毫无反应或者依然在回复旧版本的逻辑。请结合 Linux 后台运行机制推理一下最有可能导致这种现象的原因是什么你应该如何去排查✅ 参考答案这属于典型的**“流水线假阳性False Positive”**。Actions 显示绿勾仅仅代表 YAML 脚本里的 Bash 命令行执行完毕且没有抛出致命错误退出的状态码但这并不等同于你的 Python 业务代码成功运行了可能原因 1旧进程未被杀死端口/Token 抢占冲突。如果在 YAML 脚本里漏写了 pkill -f chatbot.py会导致新代码虽然下载了但原本在后台运行的旧进程依然存活。新进程由于与旧进程抢占同一个 Telegram API 端口或 Token 而启动失败或双双阵亡此时你调用的依然是没死透的旧机器人。可能原因 2Python 代码自身存在致命的语法错误。因为我们在 YAML 最后一行使用的是 nohup python chatbot.py chatbot.log 21 。请注意结尾的 符号它代表把程序丢到后台执行Bash 脚本一执行完这句就会立刻认为任务完成并宣告部署成功。此时如果你的 Python 代码里少写了一个括号导致瞬间崩溃Actions 是察觉不到的。排查方案立刻通过 SSH 登录 EC2 服务器进入项目目录执行 cat chatbot.log 命令查看你重定向的日志文件里面一定记录了 Python 抛出的具体报错追踪栈Traceback 文章摘要本文是《从零搭建聊天机器人》系列教程的第五章核心目标是利用GitHub Actions为部署在 AWS EC2 上的 Telegram 聊天机器人构建一套完整的CI/CD持续集成与持续部署自动化运维流水线。核心内容总结如下解决后台长驻问题通过nohup命令让机器人在 SSH 会话关闭后依然能在云端后台持久运行并解释了其原理忽略SIGHUP信号。安全凭证管理详细指导如何在 GitHub 仓库的 Secrets 中安全配置 EC2 服务器的连接信息主机、用户名、SSH 私钥避免敏感信息硬编码在代码中。构建自动化流水线提供了完整的deploy.yml工作流脚本该脚本在代码推送到main分支时自动触发执行拉取代码、更新依赖、杀死旧进程、重启新服务等一系列部署操作。实战测试与验证引导读者通过修改代码并推送触发自动化部署并通过检查 GitHub Actions 运行状态和服务器进程来验证部署是否成功。常见错误与排错总结了自动化部署中可能遇到的四大典型问题如进程冲突、Git 合并冲突、YAML 格式错误、SSH 密钥配置错误并提供了具体的解决方案和排查思路。深度思考通过三个思考题引导读者深入理解 CI/CD 的价值、GitHub Secrets 的安全原理以及如何排查“部署成功但服务未更新”的“假阳性”问题。最终成果实现“代码一推服务起飞”的自动化目标将传统繁琐的云端手动更新流程登录、拉取、重启完全自动化显著提升开发效率和部署可靠性。。
