我之前测过把项目部署到vercel和自己的vps的dokploy上，结果发现自己vps上的项目访问起来要快不少，可能是由于我是免费vercel的原因吧，再加上流量大之后收费贵，所以我放弃了，同时也放弃了linode，我之前写过两篇文章讲了这个情况：Vercel免费虽好，流量一大收费吓人？ 用了10多年了linode今天停止续费了

然后不知道是不是项目有点多了，或者机器配置不够了，我发现最近dokploy自动部署项目的时候会出现卡死重启的现象：

以上是dokploy自动发送消息到我的discord频道。

这样的话每次部署都要卡一下，肯定不是我们做出海网站想看到的，于是我去搜一下，发现都建议使用github actions去部署，然后我们的dokploy直接拉取镜像就行了。

我根本不知道github actions是什么东西，之前也没用过，不过这不影响我们现在来使用，于是下面这些步骤是我昨天晚上，哦不，是凌晨摸索出来的，也可以说是借鉴出来的：

1，首先到咱们的github仓库上方的actions里面新建一个workflow

我直接选择排第一的Docker image，然后把下面的内容复制进去：

# https://docs.github.com/zh/actions/use-cases-and-examples/publishing-packages/publishing-docker-images
name: Create and publish a Docker image

# Configures this workflow to run every time a change is pushed to the branch called `release`.
on:
push:
branches: ['main']

# Defines two custom environment variables for the workflow. These are used for the Container registry domain, and a name for the Docker image that this workflow builds.
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}

# There is a single job in this workflow. It's configured to run on the latest available version of Ubuntu.
jobs:
build-and-push-image:
runs-on: ubuntu-latest
# Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
permissions:
contents: read
packages: write
attestations: write
id-token: write
#
steps:
- name: Checkout repository
uses: actions/checkout@v4
# Uses the `docker/login-action` action to log in to the Container registry registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
- name: Log in to the Container registry
uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
# This step uses [docker/metadata-action](https://github.com/docker/metadata-action#about) to extract tags and labels that will be applied to the specified image. The `id` "meta" allows the output of this step to be referenced in a subsequent step. The `images` value provides the base name for the tags and labels.
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
# This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
# It uses the `context` parameter to define the build's context as the set of files located in the specified path. For more information, see "[Usage](https://github.com/docker/build-push-action#usage)" in the README of the `docker/build-push-action` repository.
# It uses the `tags` and `labels` parameters to tag and label the image with the output from the "meta" step.
- name: Build and push Docker image
id: push
uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}

# This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see "[AUTOTITLE](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)."
# - name: Generate artifact attestation
# uses: actions/attest-build-provenance@v1
# with:
# subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME}}
# subject-digest: ${{ steps.push.outputs.digest }}
# push-to-registry: true

# Trigger redeploy on dokploy => project webhooks settings
- name: Trigger dokploy redeploy
run: |
curl -X GET https://dokploy.xxx.com/api/deploy/xxxxxxxx

只需要把最后一行的链接https://dokploy.xxx.com/api/deploy/xxxxxxxx改成dokploy项目Deployments里面的Webhook URL就行了：

然后把这个workflow保存，你的项目里面就会多一个文件.github/workflows/docker-image.yml

2，好了现在我们有actions了，库这边搞定了，咱们再去dokploy那边做一点设置。

首先就是添加Docker Registry：

添加之前首先要创建一个Github Token，这个Token需要有权限拉取你上传到Github镜像注册中心的镜像，你可以在https://github.com/settings/tokens/new创建一个Token，勾选如下图所示的write权限就行

在Dokploy的Docker Registry配置中，新建一个外部Registry，Username是你的Github账号名，Password是上面创建的Token，URL是 https://ghcr.io 。

然后重新配置部署方式，这次我们换成Docker的部署方式。首先在应用的高级设置中，设置Registry是我们刚才创建的Registry。

然后，配置部署参数，Docker Image是 ghcr.io/[Github账号名]/[Repository项目名]:[分支名] ，比如我的就是ghcr.io/andylee20014/n8ncn.io:main，然后保存。意思是，部署时，Dokploy去Registry中找到这个Docker镜像，把最新镜像拉取下来并部署上线。

3，OK，到现在就搞定了，当我们提交代码到main分支的时候，workflow会自动执行，构建镜像并push到Github镜像中心。

如果没有环境变量的项目，是可以了。不过如果你的项目中有环境变量，就会了现github actions部署出错，这是因为我们没有把环境变量传到库中。

现在有两个办法，一个是直接在库后台的Environments一个个填写:

和vercel不一样的是，vercel环境变量可以直接全部复制粘贴就会自动识别，但是github这个就要一个个填写，比较麻烦，特别是我们的环境变量有20多个。

那怎么办呢，我咨询了fox，找到一个新办法，那就是直接把.env.production带进仓库，就这么简单。

反正是新项目，个人项目，怎么方便怎么来，怎么快怎么来，后面项目流量起来了再处理都行。

4，所以最后一步（仅针对我个人），直接把变量全部复制到.env.production，然后到.gitignore里面去掉.env.production即可。

以上。