近期频发的收到云厂商关于服务器资源到期的提醒,当初为了躲避云厂商所谓的注册域名 IP 检测监控,无奈之下借着“新”用户的优惠政策,采购了一款最最实惠的云服务,周期为 1 年时间,如今也已是到了“寿终正寝”的时候啦, 因此不得已又要考虑给博客空间找新的部署服务器啦。后来得到热心朋友的资助,在其现有的云服务器上开辟了小空间提供给鄙人博客访问,真是感激万分呀!
通常情况下云服务器上的安全策略都会管理的比较严格,为此原来想通过 SSH 远程执行部署站点方案便不太可行啦,其中主要的影响因素就是 Github Action 所提供的 CI/CD 服务,其执行时机器是完全随机分配的,那几乎就是等同于动态 IP, 而云服务器上面的安全组策略根本无法支持这么庞大的 IP 段设置,而且也不想劳烦朋友去调整这系统级别的安全设置,于是便想到通过 Nginx 来调用本地脚本进行远程部署的方案。
方案的初步设想如下:
graph LR;
node1([fa:fa-play 开始 ])-->node2[/撰写文章/]-->
|fa:fa-upload Git提交&推送| node3[[fa:fa-blog Github Action构建构静态文件]]
-->node4[/推送 Gitee 仓库/]-->node5[fa:fa-link curl远程调用]
-->node6([fa:fa-stop 结束 ]);
node5-->node7[[fa:fa-hdd 云服务器部署]];
subgraph http-client
node4--> |fa:fa-download Git拉取更新| node7;
end;
style node7 fill:#f96;
中间增加了 Gitee 仓库的同步机制,部署的时间上可能会增加延迟,但部署成功率会更高些。
注:考虑到国内访问 Github 经常会不稳定,所以干脆就做个仓库同步,将部署文件先推送到 Gitee ,再让云服务器去 Gitee 上面拉取部署代码,这样部署的稳定性会比较好。
在经过一番资料的查找后,最终确认方案是具备可行性的,技术上将选择 Openresty
增强版本的 Nginx 服务,通过 lua 代码来调用本地的脚本执行(特别感谢
@二花
网友帮忙调试lua代码 👊) 需要在 Nginx 配置文件上加入如下的代码:
1
2
3
4
5
6
7
8
9
| location /auto-deploy {
auth_basic "Administrator’s Area";
auth_basic_user_file /etc/xxx/.htpasswd;
content_by_lua_block {
local status, out, err = os.execute("/bin/bash /www/blog/deploy.sh")
ngx.header.content_type = "text/plain"
ngx.say("Result: \n" .. out)
}
}
|
如上述配置代码所示,其中增加了 Basic Auth 授权来保障访问的安全。再通过 curl
命令对该路径进行访问便能实现自动化部署,最后的 Github Action 定义代码参考如下:
1
2
3
4
5
6
7
8
9
| # Git pull new things from Gitee.
deploy-cloud:
needs: sync-2-gitee
runs-on: ubuntu-latest
steps:
- name: Deploy Cloud Server
run: |
curl ipinfo.io
curl -i -u ${{ secrets.GACTION_CU }}:${{ secrets.GACTION_CP }} ${{ secrets.DEPLOY_URL }}
|
注: 切记要将站代码部署的文件夹和执行部署的脚本,其访问的权限给到 Nginx 运行用户,避免出现操作无权限的问题。
最后怀揣着“激动”的心情,写下此篇文章并提交至Github
进行测试验证,当看到那个绿色的 ✅ 状态显现时,用事实证明一切皆有可能,后续就专心写作发表便是啦。 🔋 🔋 🔋