哪些是实现生产部署自动化的最佳方法？

我希望自动部署我的生产前端。我的前端部署在一个 docker 容器上，该容器在 Digital Ocean Droplet VPS（Ubuntu 24.04 (LTS) x64）上运行。目前，我按照以下步骤手动管理部署：

在我的 PC 上，在我的项目根目录（Docker 文件所在位置），我通过运行以下命令在本地重建我的 docker 镜像： docker build -t ghcr.io/my-github-username/my-image-name:my-image-version .

然后，我必须使用用户名和密码登录 GitHub 容器注册中心（密码是 GitHub 上生成的令牌，并非我在 GitHub 上的实际密码）。我通过运行 docker登录ghcr.io

通过 SSH 登录我的 Digital Ocean Droplet VPS

登录成功后，运行以下命令从 GHCR 提取更改： docker pull ghcr.io/my-github-username/my-image-name:my-image-version

运行以下命令，停止并删除使用过时旧镜像运行的容器： docker container rm -f <container id> （不知道是否有必要，但我就是这么做的）

再次创建容器，并在 VPS 的 3000 端口上公开它，方法是运行 docker run -p 3000:3000 ghcr.io/my-github-username/my-image-name:my-image-version

运行所有步骤后，所有更改都将成功部署到生产中。

我的问题是： Which are the best possible ways to automate this process? Any help is appreciated, sorry if this is kind of a noob question, but I really want to know multiple alternatives.

如果您发布了可供选择的方法，请联系我们。

如果您发布了替代方案，请强调其优缺点。

想要自动化的前端部署流程，这很棒！手动进行操作既容易出错又耗时。以下是一些可以实现自动化的方法，以及每种方法的优缺点：

1. GitHub Actions

优点：

• 与 GitHub 集成： 由于的代码已经在 GitHub 上，因此触发构建和部署管道的事件（例如，推送新的代码或创建新的标签）非常容易。
• 易于使用： GitHub Actions 使用 YAML 文件进行配置，这些文件相对容易理解和编写，即使不熟悉 CI/CD。
• 具有成本效益： GitHub Actions 为公共存储库提供免费层级，对于小型项目来说通常已经足够。

缺点：

• 有限的控制： 与在自己的服务器上运行的自托管解决方案相比，对底层基础设施的控制较少。
• 供应商锁定： 将的部署流程绑定到 GitHub。

实施：

1. 创建一个 GitHub Actions 工作流： 在的存储库中，创建一个 .github/workflows 文件夹（如果它尚不存在），并在其中创建一个 YAML 文件（例如， deploy.yml ）。
2. 配置工作流： 在的 YAML 文件中，定义的工作流。这将包括：
   • 触发器： 何时运行工作流（例如，在 main 分支上推送）。
   • 作业： 需要执行的一系列步骤。
   • 步骤： 每个作业中的单个操作，例如，签出的代码、构建 Docker 映像、登录到 GHCR、推送映像以及将映像部署到的 Droplet。

示例 deploy.yml 文件：

name: Deploy to DigitalOcean

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Login to GitHub Container Registry
      uses: docker/login-action@v1
      with:
        username: ${{ secrets.GITHUB_USERNAME }}
        password: ${{ secrets.GITHUB_TOKEN }}

    - name: Build and push Docker image
      uses: docker/build-push-action@v2
      with:
        context: .
        push: true
        tags: ghcr.io/${{ secrets.GITHUB_USERNAME }}/my-image-name:latest

    - name: SSH into production server and update
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.DO_HOST }}
        username: ${{ secrets.DO_USERNAME }}
        key: ${{ secrets.DO_SSH_KEY }}
        script: |
          docker pull ghcr.io/${{ secrets.GITHUB_USERNAME }}/my-image-name:latest
          docker container rm -f <container id> || true
          docker run -p 3000:3000 ghcr.io/${{ secrets.GITHUB_USERNAME }}/my-image-name:latest

1. 将秘密添加到的存储库设置中： 需要存储敏感信息，例如的 GHCR 用户名、GitHub 个人访问令牌 (PAT)、Droplet 的 IP 地址、用户名和 SSH 密钥。可以通过转到存储库设置 > 秘密来完成此操作。

2. DigitalOcean App Platform

优点：

• 易于使用： DigitalOcean App Platform 非常人性化，即使对于没有太多 DevOps 经验的人来说也是如此。
• 与 DigitalOcean 集成： 如果已经在使用 DigitalOcean，那么这将是一个很好的选择，因为它可以轻松地与其他 DigitalOcean 服务集成。
• 自动扩展： App Platform 可以根据需要自动扩展的应用程序，从而确保最佳性能和成本效率。

缺点：

• 控制更少： 与其他解决方案相比，对部署环境的控制更少。
• 供应商锁定： 将的部署流程绑定到 DigitalOcean。

实施：

1. 创建 DigitalOcean 帐户并连接的 GitHub 存储库。
2. 配置的应用程序： 选择 "Docker from GitHub" 作为部署方法，并指定要部署的分支以及任何环境变量。
3. 部署的应用程序： DigitalOcean 将处理构建和部署的 Docker 映像的过程。

3. 其他 CI/CD 工具

还有许多其他 CI/CD 工具可用于自动化的部署流程，例如：

• Travis CI
• CircleCI
• GitLab CI/CD
• Jenkins

这些工具提供了更大的灵活性和控制力，但也可能需要更多配置。

建议

对于的用例，如果正在寻找与 GitHub 紧密集成的易于使用的解决方案，我建议使用 GitHub Actions 。如果更喜欢托管解决方案并希望充分利用 DigitalOcean 的生态系统，那么 DigitalOcean App Platform 是一个不错的选择。如果需要更大的灵活性和控制力，或者有一个更复杂的部署流程，那么可以考虑使用其他 CI/CD 工具之一。