基于 GitHub Workflow和 Docker 构建 NextJS

时间:2024-03-23 11:07:51

最近由于某个偶然的事件,突然对Docker、Github自动化部署产生了浓厚的兴趣,开始研究Docker部署Nextjs应用!

NextJS 是 vercel 创建的 JavaScript 框架。它允许你使用 React 构建无服务器 API、服务器端渲染和静态 Web 应用程序。 Vercel 提供与 GitHub、GitLab 和 BitHub 的开箱即用 CI/CD 集成。

但有时,我们希望将 NextJS 应用程序托管在 vercel 之外的其他平台上,例如 AWS、 Azure。

在本博客中,我们将了解如何使用 GitHub Workflow 和 Docker 构建 NextJS 应用程序。

设置 NextJS 应用程序

NextJS 建议使用 create-next-app ,它会自动为你设置所有内容。要创建项目,请运行:

npx create-next-app
# or
yarn create next-app

安装完成后,按照说明启动开发服务器。尝试编辑 pages/index.js 并在浏览器上查看结果。

设置 Dockerfile

我们将把 NextJS 应用程序打包到 Docker 镜像中。使用 Docker 的原因是当我们想要运行 NextJS 服务器时,我们不需要安装任何额外的软件包,如 nodejs、pm2 等。

Docker 会将所有内容捆绑在一起,并为我们提供可以在任何地方运行的镜像。以下是我的 NextJS 应用程序的示例 Dockerfile。

FROM node:lts-alpine

ENV NODE_ENV production
ENV NPM_CONFIG_LOGLEVEL warn

RUN mkdir /home/node/app/ && chown -R node:node /home/node/app

WORKDIR /home/node/app

COPY package.json package.json
COPY package-lock.json package-lock.json

USER node

RUN npm install --production

COPY --chown=node:node .next .next
COPY --chown=node:node public public

EXPOSE 3000

CMD npm start

现在,让我们逐步看看上面的 Dockerfile 中发生了什么。

  • 我们使用 node:lts-alpine 作为基础镜像。
  • 将环境变量设置为 production 。
  • 设置一个 app 文件夹,并以 node 用户作为所有者。
  • 将 package.json 和 package-lock.json 复制到映像中。
  • 运行 npm install production 仅安装生产依赖项。
  • 将 .next 和 public 文件夹复制到容器中。这是非常有趣的一步。为什么我们要复制文件夹而不是使用 next build 命令构建应用程序?我们将在下面详细讨论这一点。
  • 暴露端口 3000,以便我们的应用程序可以从容器中访问。
  • 最后,运行 npm start 命令来启动我们的 NextJS 应用服务器。

我们可以看到,我们没有对 Dockerfile 进行任何更改。它很容易理解并且简单明了。有趣的部分是我们将 .next 和 public 文件夹复制到容器中,而不是在容器内构建。

这是详细的解释:

  • 在NextJS应用程序中,我们可能需要使用NEXT_PUBLIC环境变量。构建时过程需要 NEXT_PUBLIC 变量。 (例如 Firebase Web 客户端)
  • 如果我们使用 Firebase Web 客户端,那么我们需要提供一些必需的变量,例如 firebase api_key、app_id、auth_domain。
  • 在本地开发应用程序时,我们将这些变量写入 .env 或 .env.local 文件中。但我们不、不应该也不得将此文件推送到 git 等 VCS 系统上。
  • 因此,当我们在本地构建应用程序时,它将使用 .env 中的这些变量,并且过程会顺利完成。但是,当我们使用 RUN next build 命令在 Docker 中构建应用程序时,构建命令将失败,因为我们没有在 docker 映像中提供这些变量。
  • 如果我们想在 docker 构建过程中构建 NextJS 应用程序,我们需要在 docker build 命令中使用 --build-args 来传递构建时变量。有两种方法可以做到这一点。
    1. 我们使用 ci 秘密变量并将它们传递到 docker build 命令中
    2. 我们创建一个 .env 文件,使用 base64 对其进行编码,将其作为 ci 秘密变量传递,在 docker 文件内使用 base64 对其进行解码,然后构建 docker 映像。
  • 如果我们的公共变量列表将来增长,这将变得非常难以传递和维护。
  • 因此,为了不使构建过程复杂化,我们将使用 ci job 在 docker 映像之外构建应用程序,然后将 .next 、 public 文件夹复制到 docker 映像中。
  • 要在 ci 中传递环境变量,有两种方法。
    1. 将环境变量作为秘密传递
    2. 传递 .env 文件的base64编码,在ci进程中对其进行解码,将文件写入我们项目文件夹的根目录,与本地开发相同并构建我们的应用程序。

GtiHub Workflow

Workflow是由一个或多个作业组成的可配置自动化流程。我们将使用 YAML 文件配置工作流程。你可以在这里阅读更多。

下面是工作流程文件,我们将使用相同的。将此文件保存在 PROJECT_ROOT_FOLDER/.github/workflows/main.yml ,以便 GitHub 可以读取 yaml 文件并相应地设置操作。

name: Build & Publish

on:
  push:
    branches:
      - "**"             # all branches
      - "!dependabot/**"      # exclude dependbot branches
  workflow_dispatch:      # Manually run the workflow

jobs:
  next-build:
    if: ${{ github.event_name == 'workflow_dispatch' }}       # Run only if triggered manually
    runs-on: ubuntu-latest
    container: node:lts          # Use node LTS container version, same as Dockerfile base image
    steps:
      - name: Checkout
        uses: actions/checkout@v2       # Checkout the code
      - run: npm ci            #install dependencies
      - run: npm run build
        env:
          NEXT_PUBLIC_FIREBASE_API_KEY: ${{secrets.NEXT_PUBLIC_FIREBASE_API_KEY}}
          NEXT_PUBLIC_FIREBASE_APP_ID: ${{secrets.NEXT_PUBLIC_FIREBASE_APP_ID}}
          NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN: ${{secrets.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN}}
          NEXT_PUBLIC_FIREBASE_PROJECT_ID: ${{secrets.NEXT_PUBLIC_FIREBASE_PROJECT_ID}}
          NEXT_PUBLIC_SENTRY_DSN: ${{secrets.NEXT_PUBLIC_SENTRY_DSN}}
      - name: Upload Next build          # Upload the artifact
        uses: actions/upload-artifact@v2
        with:
          name: build
          path: |
            .next
            public
          retention-days: 7         # artifact retention duration, can be upto 30 days
  docker-push:
    needs: next-build        # Job depends on next-build(above) job
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Download next build       # Download the above uploaded artifact
        uses: actions/download-artifact@v2
        with:
          name: build
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.CR_PAT }}
      - name: Build and Push Docker Images
        run: |
          export CURRENT_BRANCH=${GITHUB_REF#refs/heads/}
          export TAG=$([[ $CURRENT_BRANCH == "main" ]] && echo "latest" || echo $CURRENT_BRANCH)
          export GITHUB_REF_IMAGE=ghcr.io/$GITHUB_REPOSITORY:$GITHUB_SHA
          export GITHUB_BRANCH_IMAGE=ghcr.io/$GITHUB_REPOSITORY:$TAG
          docker build -t $GCR_IMAGE -t $GITHUB_REF_IMAGE -t $GITHUB_BRANCH_IMAGE .
          echo "Pushing Image to GitHub Container Registry"
          docker push $GITHUB_REF_IMAGE
          docker push $GITHUB_BRANCH_IMAGE

现在,让我们讨论一下 yaml 文件中发生了什么。

  • 我们需要传递要触发工作流程的事件的条件。在我们的例子中,我们希望它出现在推送事件上。它也可以像 [push, pull_request] 一样多个。你可以在这里阅读更多。
  • 我们可以定义分支,我们希望这个工作流运行来观看。 !意味着要排除这些分支。
  • workflow_dispatch 手动运行构建过程。如果我们不写这个,我们的工作流程将在每次推送到存储库的任何分支时运行。你可以在这里阅读更多。
  • 我们将构建过程分为 2 个作业。
    1. 下一个构建:
      • 在此步骤中,我们使用 node:lts 作为基础镜像,这必须与 Dockerfile 基础镜像相同
      • 我们保留这份作业手册,因为我们不希望每次推送代码时都运行该作业。所以我们在步骤中添加 if: ${{ github.event_name == ‘workflow_dispatch’ }} 条件。
      • 在 env 部分中,我们从机密中导出环境变量。所以我们需要在GitHub项目的secret中添加这些变量。请在此处阅读有关如何操作的更多信息。
      • 在下一步中,操作将检查代码,运行 npm ci 以安装依赖项,并运行 npm run build 使用导出的环境变量构建 NextJS 应用程序。
      • 最后,在成功构建后,CI 作业将使用 actions/upload-artifact@v2 操作将我们的构建文件夹作为工件上传到 GitHub 上,保留时间为 7 天,以便 ci 作业可以在 docker-build 作业中下载相同的文件夹并用它来构建图像。在构建文件夹中,我们包括 .next 和 public 文件夹。 .next 文件夹是由构建过程生成的,我们使用公共文件夹来存放 svgs、图像等资源。因此我们也希望保留该文件夹。
    1. docker-push:构建我们的 docker 镜像
      • 该作业依赖于 needs:next-build ,这意味着我们只有在成功 next-build 作业后才会看到该作业。如果我们不写这个,那么我们的两个作业将并行,并且该作业将失败,因为它将无法下载 build 工件。 next build 将上传工件,然后,ci 作业,我们将能够访问它。所以我们需要这样写,它将创建一个顺序作业,而不是并行作业。
      • CI 作业将检查代码,使用 actions/download-artifact@v2 下载构建工件文件夹并将其解压缩。
      • 我们希望将 docker 镜像托管在 GitHub 包上,为此,我们将使用 docker/login-action@v1 操作使用用户名和密码登录 GitHub 容器注册表服务器。我们还需要在存储库机密中传递 CR_PAT ,与 NEXT_PUBLIC 变量相同。我们还可以在此处添加其他注册表,例如 GCR、AWS ECR 等。
      • 接下来,ci 作业将获取 CURRENT_BRANCH 并相应地标记我们的 docker 构建。在这里,我们创建 2 个标签,一个是分支名称,如 dev 、 qa 、 uat 、 main ,另一个是 commit沙。
      • 之后,该作业将开始构建我们的 docker 镜像,并在成功构建后将其推送到 GitHub 包。在这里,我们也可以将其推送到其他注册表,例如 GCR、AWS ECR 等。
      • 最后,这个作业就会退出,我们的工作流程就成功通过了。

要运行作业,我们必须导航到存储库操作,你将在左侧边栏上看到带有 Build & Push 的工作流程。单击该链接,你将看到如下屏幕。n

有了这个,我们将能够构建和打包我们的 NextJS 应用程序。你将在屏幕截图下方看到操作屏幕。

帮助链接:

https://dev.to/thakkaryash94/build-nextjs-application-using-github-workflow-and-docker-3foj