大家好,我是磊哥。
目前,我們所有微服務的配置中心都沒有采用Nacos,而是選擇了另一款攜程開源的分布式配置中心Apollo,今天就跟大家詳細介紹一下這款神級配置中心
1. 基本概念
由於 Apollo 概念比較多,剛開始使用比較復雜,最好先過一遍概念再動手實踐嘗試使用。
1.1、背景
隨著程式功能的日益復雜,程式的配置日益增多,各種功能的開關、參數的配置、伺服器的地址……對程式配置的期望值也越來越高,配置修改後即時生效,灰度釋出,分環境、分集群管理配置,完善的許可權、稽核機制…… 在這樣的大環境下,傳統的透過配置檔、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求。因此 Apollo 配置中心應運而生!
1.2、簡介
Apollo(阿波羅)是攜程框架部門研發的開源配置管理中心,能夠集中化管理套用不同環境、不同集群的配置,配置修改後能夠即時推播到套用端,並且具備規範的許可權、流程治理等特性。
1.3、特點
部署簡單
灰度釋出
版本釋出管理
提供開放平台API
客戶端配置資訊監控
提供Java和.Net原生客戶端
配置修改即時生效(熱釋出)
許可權管理、釋出稽核、操作審計
統一管理不同環境、不同集群的配置
1.4、基礎模型
如下即是 Apollo 的基礎模型:
(1)、使用者在配置中心對配置進行修改並釋出
(2)、配置中心通知Apollo客戶端有配置更新
(3)、Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到套用
1.5、Apollo 的四個維度
Apollo支持4個維度管理Key-Value格式的配置:
application (套用)
environment (環境)
cluster (集群)
namespace (名稱空間)
(1)、application
Apollo 客戶端在執行時需要知道當前套用是誰,從而可以根據不同的套用來獲取對應套用的配置。
每個套用都需要有唯一的身份標識,可以在程式碼中配置
app.id
參數來標識當前套用,Apollo 會根據此指來辨別當前套用。
(2)、environment
在實際開發中,我們的套用經常要部署在不同的環境中,一般情況下分為開發、測試、生產等等不同環境,不同環境中的配置也是不同的,在 Apollo 中預設提供了四種環境:
FAT(Feature Acceptance Test):功能測試環境
UAT(User Acceptance Test):整合測試環境
DEV(Develop):開發環境
PRO(Produce):生產環境
在程式中如果想指定使用哪個環境,可以配置變量
env
的值為對應環境名稱即可。
(3)、cluster
一個套用下不同例項的分組,比如典型的可以按照數據中心分,把上海機房的套用例項分為一個集群,把北京機房的套用例項分為另一個集群。
對不同的集群,同一個配置可以有不一樣的值,比如說上面所指的兩個北京、上海兩個機房設定兩個集群,兩個集群中都有 mysql 配置參數,其中參數中配置的地址是不一樣的。
(4)、namespace
一個套用中不同配置的分組,可以簡單地把 namespace 類比為不同的配置檔,不同型別的配置存放在不同的檔中,如資料庫配置檔,RPC 配置檔,套用自身的配置檔等。
熟悉 SpringBoot 的都知道,SpringBoot 計畫都有一個預設配置檔
application.yml
,如果還想用多個配置,可以建立多個配置檔來存放不同的配置資訊,透過指定
spring.profiles.active
參數指定套用不同的配置檔。這裏的
namespace
概念與其類似,將不同的配置放到不同的配置
namespace
中。
Namespace 分為兩種許可權,分別為:
public(公共的): public許可權的 Namespace,能被任何套用獲取。
private(私有的): 只能被所屬的套用獲取到。一個套用嘗試獲取其它套用 private 的 Namespace,Apollo 會報 "404" 異常。
Namespace 分為三種型別,分別為:
私有型別: 私有型別的 Namespace 具有 private 許可權。例如 application Namespace 為私有型別。
公共型別: 公共型別的 Namespace 具有 public 許可權。公共型別的N amespace 相當於遊離於套用之外的配置,且透過 Namespace 的名稱去標識公共 Namespace,所以公共的 Namespace 的名稱必須全域唯一。
關聯型別(繼承型別): 關聯型別又可稱為繼承型別,關聯型別具有 private 許可權。關聯型別的 Namespace 繼承於公共型別的 Namespace,將裏面的配置全部繼承,並且可以用於覆蓋公共 Namespace 的某些配置。
1.6、本地緩存
Apollo客戶端會把從伺服端獲取到的配置在本地檔案系統緩存一份,用於在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置,不影響套用正常執行。
本地緩存路徑預設位於以下路徑,所以請確保/opt/data或C:\opt\data\目錄存在,且套用有讀寫許可權。
Mac/Linux: /opt/data/{appId}/config-cache
Windows: C:\opt\data{appId}\config-cache
本地配置檔會以下面的檔名格式放置於本地緩存路徑下:
{appId}+{cluster}+{namespace}.properties
1.7、客戶端設計
上圖簡要描述了Apollo客戶端的實作原理
客戶端和伺服端保持了一個長連線,從而能第一時間獲得配置更新的推播。
客戶端還會定時從 Apollo 配置中心伺服端拉取套用的最新配置。
這是一個 fallback 機制,為了防止推播機制失效導致配置不更新
客戶端定時拉取會上報本地版本,所以一般情況下,對於定時拉取的操作,伺服端都會返回 304 - Not Modified
定時頻率預設為每 5 分鐘拉取一次,客戶端也可以透過在執行時指定
apollo.refreshInterval
來覆蓋,單位為分鐘。
客戶端從 Apollo 配置中心伺服端獲取到套用的最新配置後,會保存在記憶體中。
客戶端會把從伺服端獲取到的配置在本地檔案系統緩存一份 在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置。
應用程式從 Apollo 客戶端獲取最新的配置、訂閱配置更新通知。
配置更新推播實作
前面提到了 Apollo 客戶端和伺服端保持了一個長連線,從而能第一時間獲得配置更新的推播。長連線實際上我們是透過 Http Long Polling 實作的,具體而言:
客戶端發起一個 Http 請求到伺服端
伺服端會保持住這個連線 60 秒
如果在 60 秒內有客戶端關心的配置變化,被保持住的客戶端請求會立即返回,並告知客戶端有配置變化的 namespace 資訊,客戶端會據此拉取對應 namespace 的最新配置
如果在 60 秒內沒有客戶端關心的配置變化,那麽會返回 Http 狀態碼 304 給客戶端
客戶端在收到伺服端請求後會立即重新發起連線,回到第一步
考慮到會有數萬客戶端向伺服端發起長連,在伺服端我們使用了 async servlet(Spring DeferredResult) 來服務 Http Long Polling 請求。
1.8、總體設計
上圖簡要描述了Apollo的總體設計,我們可以從下往上看:
Config Service 提供配置的讀取、推播等功能,服務物件是 Apollo 客戶端
Admin Service 提供配置的修改、釋出等功能,服務物件是 Apollo Portal(管理界面)
Config Service 和 Admin Service 都是多例項、無狀態部署,所以需要將自己註冊到 Eureka 中並保持心跳
在 Eureka 之上我們架了一層 Meta Server 用於封裝Eureka的服務發現介面
Client 透過網域名稱存取 Meta Server 獲取Config Service服務列表(IP+Port),而後直接透過 IP+Port 存取服務,同時在 Client 側會做 load balance 錯誤重試
Portal 透過網域名稱存取 Meta Server 獲取 Admin Service 服務列表(IP+Port),而後直接透過 IP+Port 存取服務,同時在 Portal 側會做 load balance、錯誤重試
為了簡化部署,我們實際上會把 Config Service、Eureka 和 Meta Server 三個邏輯角色部署在同一個 JVM 行程中
1.9、可用性考慮
配置中心作為基礎服務,可用性要求非常高,下面的表格描述了不同場景下Apollo的可用性:
場景 | 影響 | 降級 | 原因 |
---|---|---|---|
某台 config service 下線 | 無影響 | Config service無狀態,客戶端重連其它config service | |
所有 config service 下線 | 客戶端無法讀取最新配置,Portal無影響 | 客戶端重新開機時,可以讀取本地緩存配置檔 | |
某台 admin service 下線 | 無影響 | Admin service無狀態,Portal重連其它 admin service | |
所有 admin service 下線 | 客戶端無影響,portal無法更新配置 | ||
某台 portal 下線 | 無影響 | Portal網域名稱透過slb繫結多台伺服器,重試後指向可用的伺服器 | |
全部 portal 下線 | 客戶端無影響,portal無法更新配置 | ||
某個數據中心下線 | 無影響 | 多數據中心部署,數據完全同步,Meta Server/Portal 網域名稱透過 slb 自動切換到其它存活的數據中心 |
2. Apollo 配置中心建立計畫與配置
接下來我們將建立一個 Apollo 的客戶端計畫,參照 Apollo 來實作配置動態更新,不過在此之前我們需要提前進入 Apollo Portal 界面,在裏面提前建立一個計畫並在其配置一個參數,方便後續客戶端引入該配置參數,測試是否能動態變化。
2.1、登入 Apollo
我這裏是部署到 Kubernetes 中,透過 NodePort 方式暴露出一個埠,開啟這個地址登入 Apollo:
使用者名稱:apollo
密 碼:admin
2.2、修改與增加部門數據
在登入後建立計畫時,選擇部門預設只能選擇 Apollo 內建的 測試部門1與測試部門2兩個選項。
開始這真讓人迷糊,原來 Apoloo 沒有修改或新增部門資訊的管理節目,只能透過修改資料庫,來新增或者修改數據,這裏開啟
Portal
對月的資料庫中的表
ApolloPortalDB
修改
key
為
organizations
的
value
的 json 數據,改成自己對於的部門資訊。
2.3、建立一個計畫
修改完資料庫部門資訊後,重新登入 Apollo Portal,然後建立計畫,這時候選擇部門可以看到已經變成我們自己修改後的部門資訊了,選擇我們自訂部門,然後設定套用 ID 為 apollo-test,套用名為 apollo-demo 。
建立完成後進入配置管理界面
2.4、建立一個配置參數
建立一個配置參數,方便後續 Apollo 客戶端計畫引入該參數,進行動態配置測試。
設定 key 為
test
value 為
123456
然後設定一個備註,保存。
建立完成後可以看到配置管理節目新增了一條配置。
接下來我們將此配置透過釋出按鈕,進行釋出。
3. 建立 Apollo 客戶端測試計畫
這裏建立一個 SpringBoot 計畫,引入 Apollo 客戶端來來實作與 Apollo 配置中心伺服端互動。
3.1、Mavne 添加 Apollo 依賴
<?xml version="1.0" encoding="UTF-8"?>
<projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.8.RELEASE</version>
</parent>
<groupId>club.mydlq</groupId>
<artifactId>apollo-demo</artifactId>
<version>0.0.1</version>
<name>apollo-demo</name>
<description>Apollo Demo</description>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.ctrip.framework.apollo</groupId>
<artifactId>apollo-client</artifactId>
<version>1.4.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
3.2、配置檔添加參數
在 application.yml 配置檔中添加下面參數,這裏簡單介紹下 Apollo 參數作用:
apollo.meta: Apollo 配置中心地址。
apollo.cluster: 指定使用某個集群下的配置。
apollo.bootstrap.enabled: 是否開啟 Apollo。
apollo.bootstrap.namespaces : 指定使用哪個 Namespace 的配置,預設 application。
apollo.cacheDir=/opt/data/some-cache-dir: 為了防止配置中心無法連線等問題,Apollo 會自動將配置本地緩存一份。
apollo.autoUpdateInjectedSpringProperties: Spring套用通常會使用 Placeholder 來註入配置,如${someKey:someDefaultValue},冒號前面的是 key,冒號後面的是預設值。如果想關閉 placeholder 在執行時自動更新功能,可以設定為 false。
apollo.bootstrap.eagerLoad.enabled : 將 Apollo 載入提到初始化日誌系統之前,如果設定為 false,那麽將打印出 Apollo 的日誌資訊,但是由於打印 Apollo 日誌資訊需要日誌先啟動,啟動後無法對日誌配置進行修改,所以 Apollo 不能管理套用的日誌配置,如果設定為 true,那麽 Apollo 可以管理日誌的配置,但是不能打印出 Apollo 的日誌資訊。
#套用配置
server:
port:8080
spring:
application:
name:apollo-demo
#Apollo 配置
app:
id:apollo-test#套用ID
apollo:
cacheDir:/opt/data/#配置本地配置緩存目錄
cluster:default#指定使用哪個集群的配置
meta:http://192.168.2.11:30002#DEV環境配置中心地址
autoUpdateInjectedSpringProperties:true#是否開啟 Spring 參數自動更新
bootstrap:
enabled:true#是否開啟 Apollo
namespaces:application#設定 Namespace
eagerLoad:
enabled:false#將 Apollo 載入提到初始化日誌系統之前
3.3、建立測試 Controller 類
寫一個 Controller 類來輸出 test 變量的值,使用了 Spring 的 @Value 註解,用於讀取配置檔中的變量的值,這裏來測試該值,計畫啟動後讀取到的變量的值是設定在 application 配置檔中的預設值,還是遠端 Apollo 中的值,如果是 Apollo 中配置的值,那麽再測試在 Apollo 配置中心中改變該變量的值後,這裏是否會產生變化。
@RestController
public classTestController{
@Value("${test:預設值}")
private String test;
@GetMapping("/test")
public String test(){
return"test的值為:" + test;
}
}
3.4、建立啟動類
SpringBoot 計畫啟動類。
@SpringBootApplication
public classApplication{
publicstaticvoidmain(String[] args){
SpringApplication.run(Application. class, args);
}
}
3.5、JVM 啟動參數添加啟動參數
由於本人的 Apollo 是部署在 Kubernetes 環境中的,JVM 參數中必須添加兩個變量:
env:
套用使用 Apollo 哪個環境,例如設定為
DEV
就是指定使用開發環境,如果設定為
PRO
就是制定使用生產環境。
apollo.configService: 指定配置中心的地址,跳過 meta 的配置,在測試時指定 meta 地址無效果。如果 Apollo 是部署在 Kubernetes 中,則必須設定該參數為配置中心地址,如果 Apollo 不是在 Kubernetes 環境中,可以不設定此參數,只設定 meta 參數即可。一般情況下,configService 和 meta 值一致。
如果是在 Idea 中啟動,可以配置啟動參數,加上:
-Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV
如果是 java 命令啟動程式,需要 JVM 加上:
$ java -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar
註意: 上面 env 指定的環境,要和 apollo.meta 指定 Config 地址的環境一致,例如 -Denv=DEV 即使用開發環境,那麽 apollo.meta=http://xxx.xxx.xxx:8080 這個url 的 Config 也是開發環境下的配置中心服務,而不能是 PRO 或者其它環境下的配置中心。
4. 啟動計畫進行測試
4.1、測試是否能夠獲取 Apollo 中設定的值
啟動上面的測試用例,然後輸入地址 http://localhost:8080/test 檢視:
test的值為:123456
可以看到使用的是 Apollo 中配置的
test
參數的值
123456
,而不是預設的值。
4.2、測試當 Apollo 中修改參數值後客戶端是否能及時重新整理
修改 Apollo 配置中心參數
test
值為
666666
,然後再次釋出。
釋出完成後再次輸入地址 http://localhost:8080/test 檢視:
test的值為:666666
可以看到範例套用中的值已經改變為最新的值。
4.3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變
回滾完成後狀態將變為未釋出狀態,則時候輸入地址 http://localhost:8080/test 檢視:
test的值為:123456
可以看到已經回滾到之前的
test
配置的值了。
4.4、測試當不能存取 Apollo 時客戶端的變化
這裏我們將 JVM 參數中 Apollo 配置中心地址故意改錯:
-Dapollo.configService=http://192.168.2.100:30002 -Denv=DEV
然後輸入地址 http://localhost:8080/test 可以看到值為:
test的值為:123456
可以看到顯示的值並不是我們定義的預設值,而還是 Apollo 配置中心配置的
test
參數的值。考慮到由於 Apollo 會在本地將配置緩存一份,出現上面原因,估計是緩存生效。當客戶端不能連線到 Apollo 配置中心時候,預設使用本地緩存檔中的配置。
上面我們配置了本地緩存配置檔存放地址為 "/opt/data/" ,接下來進入緩存目錄,找到對應的緩存配置檔,刪除緩存配置檔後,重新開機套用,再次輸入地址檢視:
test的值為:預設值
刪除緩存配置檔後,可以看到輸出的值為自己定義的預設值。
4.5、測試當 Apollo 中將參數刪除後客戶端的變化
這裏我們進入 Apollo 配置中心,刪除之前建立的
test
參數,然後釋出。
然後再次開啟地址 http://localhost:8080/test 檢視:
test的值為:預設值
可以看到顯示的是應用程式中設定的預設值。
5. 對 Apollo 的 Cluster、Namespace 進行探究
在 Apollo 中,配置可以根據不同的環境劃分為 Dev(開發)、Prod(生產) 等環境,又能根據區域劃分為不同的 Cluster(集群),還能根據配置參數作用功能的不同劃分為不同的 Namespace(名稱空間),這裏探究下,如何使用上述能力。
5.1、不同環境下的配置
(1 )、Apollo 配置中心 PRO 環境添加參數
開啟 Apollo 配置中心,環境列表點選 PRO 環境,然後新增一條配置,和之前例子中參數保持一致,都為
test
參數,建立完成後釋出。
然後修改上面的範例計畫,將配置參數指定為 PRO 環境:
(2)、範例計畫修改 application.yml 配置檔
把
apollo.meta
參數改成 RPO 的配置中心地址
......
apollo:
meta: http://192.168.2.11:30005 #RPO環境配置中心地址
......
(3)、範例計畫修改 JVM 參數
把
apollo.configService
參數改成 PRO 配置中心地址,
env
參數的值改為
PRO
。
-Dapollo.configService=http://192.168.2.11:30005 -Denv=PRO
(4)、啟動範例計畫觀察結果
啟動範例計畫,然後接著輸入地址 http://localhost:8080/test 檢視資訊:
test的值為:abcdefg
可以看到已經改成生成環境配置,所以在實際計畫中,如果要更換環境,需要修改 JVM 參數
env
(如果 Apollo 部署在 Kubernetes 環境中,還需要修改
apollo.configService
參數),和修改 application.yml 配置檔的參數
apollo.meta
值。
5.2、不同集群下的配置
(1)、建立兩個集群
例如在開發過程中,經常要將套用部署到不同的機房,這裏分別建立
beijing
、
shanghai
兩個集群。
(2)、兩個集群都配置同樣的參數不同的值
在兩個集群
beijing
與
shanghai
中,都統一配置參數
test
,並且設定不同的值。
(3)、範例計畫 application.yml 修改集群配置參數,並啟動計畫觀察結果
指定集群為 beijing:
......
apollo:
cluster:beijing#指定使用 beijing 集群
......
啟動範例計畫,然後接著輸入地址 http://localhost:8080/test 檢視資訊:
test的值為:Cluster-BeiJing
可以看到用的是 beijing 集群的配置
指定集群為 shanghai:
......
apollo:
cluster:shanghai#指定使用 shanghai 集群
......
啟動範例計畫,然後接著輸入地址 http://localhost:8080/test 檢視資訊:
test的值為:Cluster-ShangHai
可以看到用的是 shanghai 集群的配置
5.3、不同名稱空間下的配置
(1)、建立兩個名稱空間
名稱空間有兩種,一種是 public(公開),一種是 private 私有,公開名稱空間所有計畫都能讀取配置資訊,而私有的只能
app.id
值屬於該套用的才能讀取配置。
這裏建立
dev-1
與
dev-2
兩個私有的名稱空間,用於測試。
(2)、兩個集群都配置同樣的參數不同的值
在兩個名稱空間中,都統一配置參數
test
,並且設定不同的值,設定完後釋出。
(3)、範例計畫 application.yml 修改名稱空間配置參數,並啟動計畫觀察結果
指定名稱空間為 dev-1:
......
apollo:
bootstrap:
namespaces:dev-1#設定 dev-1 名稱空間
......
啟動範例計畫,然後接著輸入地址 http://localhost:8080/test 檢視資訊:
test的值為:dev-1 Namespace
可以看到用的是 dev-1 名稱空間的配置
指定名稱空間為 dev-2:
......
apollo:
bootstrap:
namespaces:dev-2#設定 dev-1 名稱空間
......
YAML
啟動範例計畫,然後接著輸入地址 http://localhost:8080/test 檢視資訊:
test的值為:dev-2 Namespace
HTML
可以看到用的是 dev-2 名稱空間的配置
6. Kubernetes 的 SpringBoot 套用使用 Apollo 配置中心
本人的 Apollo 和 SpringBoot 套用一般都是基於 Kubernetes 部署的,所以這裏簡單介紹下,如何在 Kubernetes 環境下部署 SpringBoot 套用且使用 Apollo 作為配置中心。
這裏計畫依舊使用上面的範例,不過首先要將其編譯成 Docker 映像,方便後續部署到 Kubernetes 環境下。
6.1、構建 Docker 映像
(1)、執行 Maven 編譯
首先執行 Maven 命令,將計畫編譯成一個可執行 JAR。
$ mvn clean install
BASH
(2)、準備 Dockerfile
建立構建 Docker 映像需要的 Dockerfile 檔,將 Maven 編譯的 JAR 復制到映像內部,然後設定兩個變量,分別是:
JAVA_OPTS: Java JVM 啟動參數變量,這裏需要在這裏加一個時區參數。
APP_OPTS: Spring 容器啟動參數變量,方便後續操作時能透過此變量配置 Spring 參數。
Dockerfile:
FROM openjdk:8u222-jre-slim
VOLUME /tmp
ADD target/*.jar app.jar
RUN sh -c 'touch /app.jar'
ENV JAVA_OPTS="-XX:MaxRAMPercentage=80.0 -Duser.timezone=Asia/Shanghai"
ENV APP_OPTS=""
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]
(3)、構建 Docker 映像
執行 Docker Build 命令構建 Docker 映像。
$ docker build -t mydlqclub/springboot-apollo:0.0.1 .
BASH
6.2、Kubernetes 部署範例套用
(1)、建立 SpringBoot 且使用 Apollo 配置中心的 Kubernetes 部署檔
這裏建立 Kubernetes 下的 SpringBoot 部署檔
apollo-demo-example.yaml
。在之前 Dockerfile 中設定了兩個環境變量,
JAVA_OPTS
與
APP_OPTS
。其中
JAVA_OPTS
變量的值將會作為 JVM 啟動參數,
APP_OPTS
變量的值將會作為套用的配置參數。所以,這裏我們將 Apollo 配置參數放置到變量中,這樣一來就可以方便修改與維護 Apollo 的配置資訊。
在下面配置的環境變量參數中,設定的配置中心地址為
http://service-apollo-config-server-dev.mydlqclub:8080
,這是因為 Apollo 部署在 K8S 環境中,且可以使用網域名稱方式存取,service-apollo-config-server-dev 是套用的 Service 名稱,mydlqcloud 是 K8S 下的 Namespace 名稱。
springboot-apollo.yaml
apiVersion:v1
kind:Service
metadata:
name:springboot-apollo
spec:
type:NodePort
ports:
-name:server
nodePort:31080
port:8080
targetPort:8080
-name:management
nodePort:31081
port:8081
targetPort:8081
selector:
app:springboot-apollo
---
apiVersion:apps/v1
kind:Deployment
metadata:
name:springboot-apollo
labels:
app:springboot-apollo
spec:
replicas:1
selector:
matchLabels:
app:springboot-apollo
template:
metadata:
name:springboot-apollo
labels:
app:springboot-apollo
spec:
restartPolicy:Always
containers:
-name:springboot-apollo
image:mydlqclub/springboot-apollo:0.0.1
imagePullPolicy:Always
ports:
-containerPort:8080
name:server
env:
-name:JAVA_OPTS
value:"-Denv=DEV"
##註意修改此處的 mydlqcloud 為你自己的 Namespace 名稱
-name:APP_OPTS
value:"
--app.id=apollo-demo
--apollo.bootstrap.enabled=true
--apollo.bootstrap.eagerLoad.enabled=false
--apollo.cacheDir=/opt/data/
--apollo.cluster=default
--apollo.bootstrap.namespaces=application
--apollo.autoUpdateInjectedSpringProperties=true
--apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080
"
resources:
limits:
memory:1000Mi
cpu:1000m
requests:
memory:500Mi
cpu:500m
(2)、部署 SpringBoot 套用到 Kubernetes
-n:建立套用到指定的 Namespace 中。
$ kubectl apply -f springboot-apollo.yaml -n mydlqcloud
BASH
6.3、測試部署的套用介面
上面的套用配置了 NodePort 埠,可以透過此埠存取 Kubernetes 集群內的套用介面,本人 Kubernetes 集群地址為 192.168.2.11 且 NodePort 埠為 31081,所以瀏覽器存取地址 http://192.168.2.11:31081/test 來測試介面,顯示:
test的值為:123456
可以看到能透過 Apollo 獲取參數值,此文章到此結束。
🔥 磊哥私藏精品 熱門推薦 🔥