37.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--扩展功能--增加Github Action

在第二部分（微服务基础工具与技术）中我们讲解了GitHub Action的相关知识，那么在这一节中，我们将为已有的微服务增加GitHub Action的支持。

一、什么是GitHub Action

虽然前面已经介绍过GitHub Action的相关知识，但这里还是简单回顾一下。GitHub Action是GitHub提供的一种持续集成和持续交付（CI/CD）服务，允许开发者在代码库中定义自动化工作流，以便在特定事件发生时自动执行任务。通过GitHub Action，开发者可以实现代码的自动构建、测试、部署等操作，从而提高开发效率和代码质量。

GitHub Action的工作流是由一系列的步骤（steps）组成的，每个步骤可以执行一个或多个操作（actions）。这些操作可以是预定义的，也可以是自定义的脚本。工作流可以在代码提交、拉取请求、定时任务等多种事件触发下运行。

GitHub Action的主要优势包括：

自动化：可以自动执行重复性任务，减少手动操作。
集成：与GitHub紧密集成，可以直接在代码库中管理工作流。
可扩展性：支持自定义操作，可以根据项目需求扩展功能。
社区支持：有大量的预定义操作可供使用，可以快速集成常用功能。
可视化：提供了直观的界面来查看工作流的执行状态和日志。

GitHub Action的工作流文件通常存储在代码库的.github/workflows目录下，文件格式为YAML。每个工作流可以定义触发条件、执行步骤、环境变量等。

二、创建 Dockerfile

我们依然以SP.ConfigService配置服务为例，创建一个Dockerfile文件。这个文件将定义如何构建配置服务的Docker镜像。

dockerfile 复制代码

# 使用官方.NET 8.0 SDK镜像作为构建阶段
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

# 复制项目文件
COPY ["SP.ConfigService/SP.ConfigService.csproj", "SP.ConfigService/"]
COPY ["SP.Common/SP.Common.csproj", "SP.Common/"]

# 还原NuGet包
RUN dotnet restore "SP.ConfigService/SP.ConfigService.csproj"

# 复制所有源代码
COPY . .

# 构建应用程序
WORKDIR "/src/SP.ConfigService"
RUN dotnet build "SP.ConfigService.csproj" -c Release -o /app/build

# 发布应用程序
FROM build AS publish
RUN dotnet publish "SP.ConfigService.csproj" -c Release -o /app/publish /p:UseAppHost=false

# 使用官方.NET 8.0运行时镜像作为最终阶段
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app

# 安装必要的系统包（如果需要）
RUN apt-get update && apt-get install -y \
    curl \
    && rm -rf /var/lib/apt/lists/*

# 创建非root用户
RUN groupadd -r appuser && useradd -r -g appuser appuser

# 复制发布的应用程序
COPY --from=publish /app/publish .

# 设置文件权限
RUN chown -R appuser:appuser /app
USER appuser

# 暴露端口
EXPOSE 80
EXPOSE 443

# 设置环境变量
ENV ASPNETCORE_URLS=http://+:80
ENV ASPNETCORE_ENVIRONMENT=Production

# 启动应用程序
ENTRYPOINT ["dotnet", "SP.ConfigService.dll"]

这个Dockerfile文件完整地描述了从源代码到可运行镜像的构建流程。它采用多阶段构建，先用官方.NET 8.0 SDK镜像进行编译和发布，确保最终镜像仅包含运行所需内容，从而减小体积并提升安全性。项目文件和依赖会被优先复制和还原，避免无关文件影响构建。随后将所有源代码复制到镜像中，完成编译和发布，生成可部署的应用程序文件。最终阶段使用.NET 8.0 ASP.NET运行时镜像，仅包含必要的运行环境，进一步优化镜像体积。为提升安全性，Dockerfile创建了非root用户appuser并设置了文件权限，降低容器运行时的安全风险。镜像还暴露了80和443端口，并配置了应用程序的运行环境变量，确保服务能在生产环境下正常运行。最后通过ENTRYPOINT指定应用程序的启动方式，使容器启动后自动运行服务。通过这样的配置，可以实现微服务的标准化部署，为后续集成到GitHub Action自动化流程打下坚实基础。

在创建完Dockerfile后，我们需要创建.dockerignore文件，以避免将不必要的文件添加到Docker镜像中。当然，这一步并不是必须的，但我建议大家都这么做，以保持镜像的整洁和高效。以下是配置服务的.dockerignore文件：

dockerignore 复制代码

# 构建输出
bin/
obj/

# 用户特定文件
*.user
*.suo
*.userosscache
*.sln.docstates

# 构建结果
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
build/
bld/
[Bb]in/
[Oo]bj/

# MSTest测试结果
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*

# NuGet包
*.nupkg
# NuGet Symbol包
*.snupkg
# 包文件夹
**/[Pp]ackages/*
# 除了build/，它被NuGet用作缓存
!**/[Pp]ackages/build/

# 其他
*.swp
*.*~
project.lock.json
.DS_Store
*.pyc
nupkg/

# Visual Studio缓存/选项目录
.vs/

# ReSharper
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

# TeamCity
_TeamCity*

# DotCover
*.dotCover

# NCrunch
_NCrunch_*
.*crunch*.local.xml
nCrunchTemp_*

# MightyMoose
*.mm.*
AutoTest.Net/

# Web workbench (sass)
.sass-cache/

# Installshield输出文件夹
[Ee]xpress/

# DocProject是一个文档生成器
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html

# Click-Once目录
publish/

# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
*.pubxml
*.publishproj

# Microsoft Azure Web App发布设置
PublishScripts/

# NuGet包
*.nupkg
# NuGet Symbol包
*.snupkg
# 包文件夹
**/[Pp]ackages/*
# 除了build/，它被NuGet用作缓存
!**/[Pp]ackages/build/

# Windows Azure Build Output
csx/
*.build.csdef

# Windows Store app package directories and files
AppPackages/
BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx
*.appxbundle
*.appxupload

# Visual Studio缓存文件
# 文件以.vs结尾
.vs/

# Others
ClientBin/
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.jfm
*.pfx
*.publishsettings
orleans.codegen.cs

# 包含敏感信息的文件
*.pfx
*.key

# 由于构建过程，忽略用户特定文件
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates

# 用户特定文件(MonoDevelop/Xamarin Studio)
*.userprefs

# Mono自动生成的文件
mono_crash.*

# Windows图像缓存文件
Thumbs.db
ehthumbs.db

# 文件夹配置文件
[Dd]esktop.ini

# 回收站
$RECYCLE.BIN/

# Windows Installer文件
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows快捷方式
*.lnk

# JetBrains Rider
.idea/
*.sln.iml

# 日志文件
*.log

# 临时文件
*.tmp
*.temp

# Docker相关
Dockerfile*
docker-compose*
.dockerignore

# Git相关
.git/
.gitignore

# 其他IDE文件
.vscode/
*.code-workspace

这个.dockerignore文件包含了常见的忽略规则，确保在构建Docker镜像时不会将不必要的文件添加进去，从而减小镜像体积并提高构建效率。通过排除如编译输出目录（bin/、obj/）、用户和IDE相关文件（如.vs/、.idea/、*.user）、日志和临时文件，以及敏感信息文件（如*.pfx、*.key），可以有效避免将无关或敏感内容打包进镜像。这不仅提升了镜像的安全性和可维护性，也加快了构建过程，减少了存储和网络资源的消耗。建议在每个微服务项目中都维护一个合理的.dockerignore文件，以便持续集成和自动化部署时获得更好的体验和结果。

三、创建 GitHub Action

在创建完Dockerfile和.dockerignore文件后，我们就可以为配置服务创建GitHub Action工作流文件了。我们将在项目的.github/workflows目录下创建一个名为deploy-config-service.yml的文件，内容如下：

yaml 复制代码

name: Deploy Config Service

on:
  push:
    branches: [ Microservices ]
    paths:
      - 'SP.ConfigService/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          file: ./SP.ConfigService/Dockerfile
          push: true
          tags: ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latest

      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USERNAME }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            docker pull ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latest
            docker stop sp-config-service || true
            docker rm sp-config-service || true
            docker run -d --name sp-config-service -p 5101:80 ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latest

在这个工作流文件中，我们定义了一个名为"Deploy Config Service"的工作流。当代码推送到Microservices分支且涉及SP.ConfigService目录下的文件时，工作流将被触发。工作流包含一个名为"deploy"的作业，运行在最新的Ubuntu环境中。作业步骤首先使用actions/checkout@v3操作签出代码库，然后设置Docker Buildx环境以支持多平台构建。接下来，通过docker/login-action@v2操作登录到Docker Hub，使用存储在GitHub Secrets中的凭据确保安全性。随后，利用docker/build-push-action@v4操作构建并推送配置服务的Docker镜像到Docker Hub，指定了上下文和Dockerfile路径，并打上最新标签。最后，使用appleboy/ssh-action@master操作通过SSH连接到远程服务器，拉取最新的Docker镜像，停止并删除现有的配置服务容器（如果存在），然后以守护态运行新的配置服务容器，映射端口5101到容器的80端口。通过这种方式，实现了从代码提交到自动构建、推送和部署的完整CI/CD流程，大大提升了开发和运维效率。

我们在创建的yml文件中看到了一些secrets，主要用于读取存储在Github仓库中的机密信息，这些secrets需要我们在GitHub仓库中进行配置。

打开GitHub仓库，点击右上角的Settings。
在左侧菜单中选择Secrets and variables，然后点击Actions。
点击New repository secret按钮，添加以下几个secrets：
- DOCKER_USERNAME：你的Docker Hub用户名。
- DOCKER_PASSWORD：你的Docker Hub密码或访问令牌。
- SERVER_HOST：你的服务器IP地址或域名。
- SERVER_USERNAME：用于SSH连接的服务器用户名。
- SERVER_SSH_KEY：用于SSH连接的私钥内容（确保格式正确）。

完成这些配置后，当你将代码推送到Microservices分支时，GitHub Action将自动触发，构建并部署配置服务。

四、总结

在本节中，我们为微服务项目添加了GitHub Action支持，创建了Dockerfile和相关的工作流文件，实现了从代码提交到自动构建、推送和部署的完整CI/CD流程。通过这种方式，我们可以更高效地管理微服务的部署，提高开发和运维效率。你可以根据需要调整工作流文件的内容，例如添加更多的测试步骤、通知步骤等，以满足项目的具体需求。

在下一节中，我们将继续扩展微服务的功能，增加更多的服务和功能模块。通过不断完善微服务架构，我们将逐步实现一个完整的微服务系统。如果你对GitHub Action或Docker有任何疑问，欢迎在评论区留言，我将尽快回复你。同时，也欢迎大家分享自己的经验和实践，共同学习和进步。