Docker、Nginx、Webhook三重门——我用两天才把网站部署成功

上篇讲到,我用了不到两天把代码写完了。然后我信心满满地敲下docker compose up -d,心想:这不就成了?然后我搞到了凌晨2点。 镜像拉不下来、端口被占用、Nginx配置死活不生效、Webhook签名校验失败、防火墙安全组三层关卡...... 今早9点爬起来继续,又折腾了大半天,总算把所有服务跑通了。 这篇文章,就是那"两天"里后半段的真实记录。

一、第一重门:Docker镜像拉不下来

我执行./deploy.sh start,然后看到这行报错:

text 复制代码
failed to resolve reference "docker.io/library/node:18-alpine": 
received unexpected HTTP status: 500 Internal Server Error

500? Docker Hub给我返回500?

我试了阿里云镜像加速器------还是500。

我试了改成官方国内镜像------连接超时。

我换了好几个国内镜像地址------终于有一个能用了。

那一刻我像个在沙漠里找水的人,每换一个镜像地址就满怀期待地敲下docker pull,然后眼睁睁看着报错。最后拉下来的时候,差点想给那个镜像站磕一个。

经验:如果你也遇到类似问题,多备几个国内镜像源,别死磕一个。


二、第二重门:端口冲突 + Nginx反向代理

镜像拉下来之后,构建成功。然后启动容器:

text 复制代码
Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use

80端口被占用了。我这才想起来服务器上还有个Nginx在跑。

docker-compose.yml,把前端端口从80:80改成8081:80

然后修改Nginx配置,反向代理到http://localhost:8081

conf 复制代码
server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://localhost:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

改完配置,nginx -s reload,信心满满地打开浏览器输入IP地址。

还是旧的静态页面。

我检查了配置路径、检查了代理目标、检查了容器是否真的在跑------全对。

最后发现:浏览器缓存。

强制刷新(Ctrl+Shift+R)之后,我的工具箱终于出现在屏幕上。

这一刻的喜悦,大概只有经历过的人能懂。


三、第三重门:Webhook------从0到1的自动部署

网站上线了,但我又开始犯懒了。

每次改完代码,流程是这样的:

  1. 本地git push
  2. 登录服务器
  3. git pull
  4. docker compose up -d --build
  5. 等构建完成

虽然每一步都不复杂,但次数一多就烦。

于是我问AI:能不能我推送代码,服务器自动部署?

AI说:Webhook。

3.1 写一个Python Webhook服务

AI帮我生成了一个webhook_server.py,核心逻辑很简单:

  • 监听9000端口
  • 收到Gitee的POST请求后,验证签名
  • 通过后执行bash deploy.sh start

代码量不大,一百来行。我用systemd把它做成服务,开机自启。

3.2 签名校验------被Gitee的文档教育了

Webhook服务跑起来之后,我配置好Gitee的Webhook URL

然后push了一次代码。

服务器收到了请求,但返回了403

AI一开始告诉我的签名算法是错的------它以为是对请求体做HMAC。但实际上Gitee的签名算法是:

text 复制代码
signature = Base64(HMAC-SHA256(timestamp + "\n" + secret))

而且这个签名通过X-Gitee-Token请求头传递,timestamp通过URL查询参数传递。

我去翻了Gitee官方文档才搞明白。改完代码之后,签名校验通过,自动部署终于跑通了。

3.3 防火墙------最后一公里的坑

签名校验通过之后,我push了一次代码,等了几分钟,服务器没反应。

登录上去一看:Webhook服务根本没收到请求。

原因有三层:

  1. 服务器本地防火墙没开9000端口
  2. 阿里云安全组没放行9000端口
  3. 我填的Webhook URL里的IP写错了

一层一层打通之后,终于:

text 复制代码
本地git push → Gitee收到推送 → 发送Webhook请求到服务器
→ webhook_server.py验证签名通过 → 执行deploy.sh start
→ docker compose拉取最新代码并重新构建 → 服务自动更新

整个过程不到1分钟。

那一刻,我终于真正理解了什么叫自动化


四、经验和教训

关于部署

部署的坑永远是网络>配置>代码

Docker镜像拉不下来、端口被占用、防火墙没开、安全组没放行------这些问题跟你的代码质量毫无关系,但能卡你半天。

排查顺序:先看网络通不通(端口、防火墙、安全组),再看配置对不对(路径、代理、环境变量),最后看代码。

关于AI辅助开发

AI很强大,但前提是你得知道自己在做什么。

它给的代码可能有版本问题、逻辑问题、甚至方向性错误。它能帮你提速,但不能替你决策。 你需要具备辨别能力和修正能力------这正是程序员的价值所在。

关于Webhook安全

务必校验签名,不要直接用明文密码比对。另外,Webhook的日志非常关键------journalctl -u webhook.service -f 救我无数次。


五、结尾

从一行代码都没有,到访问http://47.109.36.114能看见自己的工具箱,再到push代码自动部署------这条路上最大的收获不是那个工具箱,而是学会了怎么用AI当搭档,而不是当拐杖。

愿你的服务器也能被善用。


你遇到最离谱的坑是什么?欢迎讨论

相关推荐
考虑考虑5 天前
kafka4安装
后端·kafka·自动化运维
SkyWalking中文站7 天前
认识 Horizon UI · AI Assistant:用日常语言查询你的可观测性数据
运维·监控·自动化运维
SkyWalking中文站7 天前
认识 Horizon UI · 17/17:安装与迁移
运维·监控·自动化运维
SkyWalking中文站7 天前
认识 Horizon UI · 16/17:八种语言的本地化
运维·监控·自动化运维
SkyWalking中文站7 天前
认识 Horizon UI · 15/17:用模板定制控制台
运维·监控·自动化运维
路长慢慢8 天前
独立开发者的AI编程流水线:从需求到上线的48小时实录
自动化运维
SkyWalking中文站9 天前
认识 Horizon UI · 11/17:运行时规则与实时调试
运维·监控·自动化运维
SkyWalking中文站11 天前
认识 Horizon UI · 6/17:Trace 探索器
运维·监控·自动化运维