這篇文章,我們要調整發布腳本。之所以要調整發布腳本,是因為現在我們的項目有三個環境:本地(Local)、開發(Development)、生產(Production)。
Tip:我們的項目雖然是實戰項目,但是對于測試部分并不會增加測試環境(Test),這是因為微服務的測試實戰內容很多,不是三四篇文章可以講完了,并且我們的實戰專欄核心是微服務應用的開發,所以我們不設置測試環境。
一、三個環境講解
設置三個環境的目的,是為了讓我們在不同的環境下,能夠有不同的配置文件。比如說,我們在本地開發的時候,可能會使用本地的數據庫,而在生產環境中,我們就需要使用生產環境的數據庫。在這一小節,我們來講解一下這三個環境的具體含義。
1.1 本地(Local)
本地環境是指我們在本地開發時使用的環境。在這個環境中,我們可以使用本地的數據庫、緩存等資源。通常情況下,本地環境的配置文件會包含詳細的調試信息,以便于我們在開發過程中進行調試,日志也會很詳細。
在本地環境下,開發者可以自由地修改代碼、重啟服務、調試功能,而不會影響到其他開發者或線上用戶。常見的做法是將數據庫連接指向本地的數據庫實例,緩存服務也可以部署在本地,甚至可以使用一些模擬服務來代替真實的第三方依賴。此外,本地環境通常會開啟詳細的日志記錄和錯誤提示,方便定位和解決問題。
本地環境的安全性和性能要求相對較低,主要關注開發效率和調試便利性。因此,某些生產環境下的安全策略和性能優化措施,在本地環境中可以不啟用。
1.2 開發(Development)
開發環境是指團隊在協作開發和聯調過程中使用的環境。在該環境下,項目會連接到專門的開發數據庫和緩存服務等,這些資源通常與生產環境隔離,便于多人協作和問題排查。開發環境的配置文件一般保留必要的調試信息,但日志級別和詳細程度會低于本地環境,以減少無關信息干擾。
在開發環境中,開發者可以進行前后端聯調、多模塊集成測試,以及服務端的自動化測試。該環境通常會盡量模擬生產環境的部署方式和依賴配置,以便提前發現集成和部署中的潛在問題。開發環境的數據庫和服務通常為團隊成員共享,便于協作開發,但訪問權限會受到一定限制,僅限開發人員使用。
開發環境對服務器性能和安全性的要求適中,主要關注功能完整性和調試便利性。與本地環境相比,開發環境更接近實際生產環境,但仍保留一定的靈活性,支持開發和測試工作。
1.3 生產(Production)
生產環境是最終用戶實際訪問和使用的環境。在該環境下,項目會連接到正式的生產數據庫、緩存等核心資源,這些資源經過嚴格的測試和驗證,確保數據安全和服務穩定。生產環境的配置文件會關閉調試信息,優化日志級別,以提升系統性能并保障敏感信息安全。
在生產環境中,服務的高可用性、性能和安全性是首要目標。所有代碼和配置的變更都必須經過完整的測試和審批流程,確保不會影響用戶體驗。日志記錄通常僅保留必要的信息,避免泄露敏感數據,同時減少對系統性能的影響。
生產環境的訪問權限嚴格受控,僅限授權人員操作。數據庫和服務實例與其他環境完全隔離,確保數據的完整性和安全。任何變更操作通常會選擇在業務低峰期進行,以最大程度降低對用戶的影響。
Tip:在我們的孢子記賬項目中,由于僅有一個臺服務器,因此開發環境和生產環境是共用的。我們會在發布腳本中根據不同的環境來選擇不同的配置文件。
二、調整發布腳本
在上一篇文章中,我們為每個微服務都創建Github Action工作流,但是這些工作流都是針對單一環境的。現在,我們要調整發布腳本,讓它能夠根據不同的環境來選擇不同的配置文件。我們以用戶配置服務(SP.ConfigService
)為例,來講解如何調整發布腳本。
2.1 配置launchSettings.json
要配置本地環境,我們需要修改 launchSettings.json
文件。launchSettings.json
文件位于 ASP.NET Core 項目的 Properties
文件夾下,主要用于配置項目的啟動和調試參數。它允許為不同的啟動方式(如 IIS Express、本地運行、Docker 等)定義多個啟動配置(profile),并在每個配置中設置環境變量(如 ASPNETCORE_ENVIRONMENT)、端口號、命令行參數以及是否自動打開瀏覽器等選項。通過合理配置 launchSettings.json
,可以方便地在本地開發環境下切換不同的運行模式,實現針對本地、開發或生產環境的調試和測試需求。Visual Studio 和 dotnet run
命令都會讀取該文件,從而為開發者提供靈活的本地啟動體驗。
由于我們在開發功能時是在各自的本地電腦上開發的,因此我們需要將 ASPNETCORE_ENVIRONMENT
環境變量設置為 Local
。我們打開 SP.ConfigService
項目的 Properties/launchSettings.json
文件,找到 profiles
節點下的 SP.ConfigService
節點,然后將 ASPNETCORE_ENVIRONMENT
的值修改為 Local
,修改后的內容如下所示:
{"$schema": "http://json.schemastore.org/launchsettings.json","iisSettings": {"windowsAuthentication": false,"anonymousAuthentication": true,"iisExpress": {"applicationUrl": "http://localhost:45810","sslPort": 44303}},"profiles": {"http": {"commandName": "Project","dotnetRunMessages": true,"launchBrowser": true,"launchUrl": "swagger","applicationUrl": "http://localhost:5116","environmentVariables": {"ASPNETCORE_ENVIRONMENT": "Local"}},"https": {"commandName": "Project","dotnetRunMessages": true,"launchBrowser": true,"launchUrl": "swagger","applicationUrl": "https://localhost:7108;http://localhost:5116","environmentVariables": {"ASPNETCORE_ENVIRONMENT": "Local"}}}
}
在上面的配置中,我們將 ASPNETCORE_ENVIRONMENT
的值修改為 Local
,這樣我們在本地運行項目時,就會使用 appsettings.Local.json
配置文件。
2.2 創建appsettings.Local.json
接下來,我們創建 appsettings.Local.json
文件,并添加本地環境的配置內容,配置如下:
{"nacos": {"ServerAddresses": [ "http://14.103.224.141:8848" ],"Namespace": "a8f01c53-b0b2-4046-b0f8-850e24738b23","ServiceName": "SPConfigService","GroupName": "DEFAULT_GROUP","ClusterName": "DEFAULT","Username": "SP_ADMIN","Password": "123*asdasd","Weight": 100,"ConfigUseRpc": true,"NamingUseRpc": true,"RegisterEnabled": true,"InstanceEnabled": true,"Ephemeral": true,"GrpcReconnectInterval": 5000,"ConnectionTimeOut": 10000,"Listeners": [{"Optional": false,"DataId":"SP.ConfigService","Group":"DEFAULT_GROUP"},{"Optional": false,"DataId":"Common","Group":"DEFAULT_GROUP"}]}
}
在這個配置文件中,我們配置了 Nacos 的相關信息,這些信息是我們在本地開發時使用的,其中Namespace
是我們在Nacos中創建的本地命名空間的ID。
Tip:同樣,我們也可以為開發環境創建
appsettings.Development.json
文件,為生產環境創建appsettings.Production.json
文件,配置內容和上面的類似,只是Namespace
的值不同,分別對應我們在Nacos中創建的開發命名空間和生產命名空間的ID。
2.2 修改Dockerfile配置
接著我們需要修改 Dockerfile
文件,使其能夠支持多環境部署。我們打開 SP.ConfigService
項目的 Dockerfile
文件,刪除原有的環境變量設置命令 ENV ASPNETCORE_ENVIRONMENT=Production
,讓環境變量的設置交由外部傳遞。這樣做的好處是,ASPNETCORE_ENVIRONMENT
環境變量可以在容器啟動時通過命令行參數或 CI/CD 發布腳本動態指定。例如,在使用 docker run
啟動容器時,可以通過 -e
參數傳遞環境變量:
docker run -e ASPNETCORE_ENVIRONMENT=Development your-image-name
或者在 GitHub Actions、Jenkins 等自動化部署腳本中,根據不同的環境傳遞不同的環境變量值,實現靈活的多環境部署。最終,Dockerfile
文件無需硬編碼環境變量,環境的切換完全交由外部控制,便于后續擴展和維護。
Tip:不建議為每個環境單獨維護一份
Dockerfile
,這樣會增加維護成本且容易出錯。通過外部傳遞環境變量的方式,可以讓同一個鏡像適配不同的環境配置,既簡化了鏡像管理,也提升了部署的靈活性。
2.3 修改Github Action 工作流
最后,我們需要修改 SP.ConfigService
項目的 GitHub Action 工作流文件,使其能夠根據不同的環境來選擇不同的配置文件。我們打開 deploy-config-service.yml
文件,我們需要新增workflow_dispatch
和Set deployment environment
步驟,以及修改Deploy to Server
步驟的docker 運行命令。以下是修改后的內容:
name: Deploy Config Serviceon:push:branches: [ Microservices ]paths:- 'SP.ConfigService/**'workflow_dispatch:jobs:deploy:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v3- name: Set up Docker Buildxuses: docker/setup-buildx-action@v2- name: Login to Docker Hubuses: docker/login-action@v2with:username: ${{ secrets.DOCKER_USERNAME }}password: ${{ secrets.DOCKER_PASSWORD }}- name: Build and push Docker imageuses: docker/build-push-action@v4with:context: .file: ./SP.ConfigService/Dockerfilepush: truetags: ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latest- name: Set deployment environmentrun: |if [ "${{ github.event_name }}" == "push" ]; thenecho "ENVIRONMENT=Development" >> $GITHUB_ENVelseecho "ENVIRONMENT=Production" >> $GITHUB_ENVfi- name: Deploy to Serveruses: appleboy/ssh-action@masterwith:host: ${{ secrets.SERVER_HOST }}username: ${{ secrets.SERVER_USERNAME }}key: ${{ secrets.SERVER_SSH_KEY }}script: |docker pull ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latestdocker stop sp-config-service || truedocker rm sp-config-service || truedocker run -d --name sp-config-service -p 5101:80 -e ASPNETCORE_ENVIRONMENT=${{ env.ENVIRONMENT }} ${{ secrets.DOCKER_USERNAME }}/sp-config-service:latest
在上面的代碼中,我們新增了 workflow_dispatch
事件,這樣我們就可以手動觸發工作流,并選擇要部署的環境。同時,我們新增了 Set deployment environment
步驟,根據觸發事件來設置環境變量 ENVIRONMENT
的值。最后,在 Deploy to Server
步驟中,我們將 ASPNETCORE_ENVIRONMENT
環境變量的值設置為 ${{ env.ENVIRONMENT }}
,這樣就可以根據不同的環境來選擇不同的配置文件。
三、總結
通過以上的調整,我們實現了在不同環境下使用不同的配置文件。現在,當我們在本地開發時,使用的是 appsettings.Local.json
配置文件;當我們在開發環境部署時,使用的是 appsettings.Development.json
配置文件;當我們在生產環境部署時,使用的是 appsettings.Production.json
配置文件。這樣做的好處是,我們可以在不同的環境下使用不同的配置,避免了在同一個配置文件中混合不同環境的配置,從而減少了出錯的可能性。