近期频发的收到云厂商关于服务器资源到期的提醒，当初为了躲避云厂商所谓的注册域名 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进行测试验证，当看到那个绿色的 ✅ 状态显现时，用事实证明一切皆有可能，后续就专心写作发表便是啦。 🔋 🔋 🔋