为了进行练习,我用了几天时间来实现了一个自己的工具网页,主要用于博客的banner和插图处理,尽管目前只实现了webp转换。随后发现项目的不断迭代导致需要频繁部署,作为拥有拖延症和懒惰特性的人,非常想要只点一下提交就能自动部署到私人服务器,因此打算实现一部分的DevOps工作流:CD持续部署。
虽然我的代码托管仓库是gitea,但是其生态包含了几乎完全对应到GitHub Action的Runner,甚至大部分在GitHub的markspace 的action的镜像都支持,因此这篇记录同样适用于GitHub Action。
我的前端项目是手写的纯原生html+css+前端组件库mdui,后端使用fastapi实现,且前后不分离,因此问题变成了利用Action实现自动部署fastapi项目。
在此之前,我需要考虑fastapi项目的部署形式。
因此决定采用docker技术,需要手写dockerfile构建镜像。
搜索发现fastapi官方提供了docker镜像,并提供了以此为基础镜像的构建说明,详情
根据示例可知,我们主要需要设置WORKDIR,安装依赖并使用uvicorn启动项目。
1 2 3 4 5 6 7 8 9
| WORKDIR /code
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY ./app /code/app
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "80"]
|
简单测试构建后的镜像能正常启动后进行workerflow的配置。
工作流主要的工作是
- clone项目
- 进行预处理(自己添加的这个环节,主要是为了添加这个环节,手动进行版本替换)
- 重新构建镜像
- 重建容器并启动。
python项目不需要编译运行,所以最关键的一步只是将项目代码复制到容器内。
我使用appleboy/ssh-action
先让容器远程连接到服务器后台后再进行以上工作流操作。
这是示例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
| name: gitea deploy toolkit web run-name: deploying toolkit on: [push]
jobs: remote-ssh-clone: runs-on: ubuntu-latest env: TZ: Asia/Shanghai steps: - name: checkout source uses: actions/checkout@v4
- name: remote-execute uses: appleboy/ssh-action@v1.0.3 with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} key: ${{ secrets.KEY }} port: 22 script: | rm -rf ${{ vars.TOOLKIT_PROD_PATH }} REPO_URL=${{ gitea.server_url }}/${{ gitea.repository }} git clone $REPO_URL ${{ vars.TOOLKIT_PROD_PATH }} ${{ vars.TOOLKIT_PROD_PATH }}/insert_version.sh docker build ${{ vars.TOOLKIT_PROD_PATH }} -t toolkit:latest cd ${{ vars.TOOLKIT_PROD_PATH }}/../ docker compose down toolkit docker compose up -d toolkit
|
实际上这个没啥可写的,但是我迟早把所有我在运行的项目容器化了。