GitHub操作：构建外部容器还是内部容器？

Question

假设我们使用GitHub操作构建并发布应用程序的容器映像。我将选择ASP.NET Core作为应用程序的技术堆栈，尽管这不太重要。

我想讨论两种不同的方法：

1.“外部构建”：在GitHub Actions runner中构建/编译应用程序，将输出复制到容器映像中

例如，我们的GitHub操作工作流文件可能如下所示...

name: build-outside
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repo
      uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
    - name: .NET Publish
      run: dotnet publish --configuration Release --nologo -p:CI=true -o $GITHUB_WORKSPACE/buildOutput src
    - name: Build and push Docker image
      uses: docker/build-push-action@v1
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_ACCESS_TOKEN }}
        repository: ${{ format('{0}/build-outside-test', secrets.DOCKERHUB_USERNAME) }}
        tags: latest

...有一个简单的Dockerfile像这样：

FROM mcr.microsoft.com/dotnet/core/aspnet:latest
WORKDIR /app
COPY buildOutput /app
ENTRYPOINT ["dotnet", "MyTestApp.dll"]

2.“内置”：内置一个容器，将输出复制到另一个容器映像

在这种情况下，工作流文件较短...

name: build-inside
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repo
      uses: actions/checkout@v2
    - name: Build and push Docker image
      uses: docker/build-push-action@v1
      with:
        dockerfile: Dockerfile_build_inside
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_ACCESS_TOKEN }}
        repository: ${{ format('{0}/build-inside-test', secrets.DOCKERHUB_USERNAME) }}
        tags: latest

...而Dockerfile较长，因为现在我们正在构建应用程序本身和最终容器映像：

FROM mcr.microsoft.com/dotnet/core/sdk:latest AS build
WORKDIR /src
COPY src /src
RUN dotnet publish --configuration Release --nologo -p:CI=true -o ./buildOutput

FROM mcr.microsoft.com/dotnet/core/aspnet:latest AS runtime
WORKDIR /app
COPY --from=build /src/buildOutput ./
ENTRYPOINT ["dotnet", "MyTestApp.dll"]

旁白：如果您不熟悉多阶段构建，请注意第二个DockerFile中的两个from语句。我们正在构建第一个临时容器，然后只将构建输出复制到最终的（运行时优化的）容器映像中。

请注意，官方ASP.NET核心文档中明确推荐了第二种方法。

权衡

我已经确认了这两种方法都能工作并产生一个工作容器映像。特别要注意的是，对拉请求的构建检查“只适用于”™的两种方法：

现在，离开这个具体的例子，下面是我目前对每种方法的优点的看法：

1. 外部生成:

• 生成可以利用市场操作
• 如果构建是复杂的并且包含多个步骤，那么使用GitHub操作原语（即一系列作业/任务）来设置它可能是有益的。这样，我们就可以让GH来优化构建、根据需要分配额外的资源、并行运行作业等。
• 更容易检查生成失败（UI将准确显示哪一步失败）
• 构建期间不需要下载第二个容器映像，因此可能会节省一点网络带宽

• 精确、确定的生成输出
• 对生成环境的完全控制；独立于生成运行程序
• 容器生成也可以在本地开发计算机上运行，产生相同的精确输出

问题

>

我是否准确地描述了这两种方法的优点？

在容器内部构建vs外部，特别是在GitHub动作中，有没有其他方面值得一提的？