SpringBoot 整合 Apollo 配置中心
目錄
. 一、基本概念
. 1、背景
. 2、簡介
. 3、特點
. 4、基礎模型
. 5、Apollo 的四個維度
. 6、本地快取
. 7、客戶端設計
. 8、總體設計
. 9、可用性考慮
. 二、Apollo 配置中心建立專案與配置
. 1、登入 Apollo
. 2、修改與增加部門資料
. 3、建立一個專案
. 4、建立一個配置引數
. 三、建立 Apollo 客戶端測試專案
. 1、Mavne 新增 Apollo 依賴
. 2、配置檔案新增引數
. 3、建立測試 Controller 類
. 4、建立啟動類
. 5、JVM 啟動引數新增啟動引數
. 四、啟動專案進行測試
. 1、測試是否能夠獲取 Apollo 中設定的值
. 2、測試當 Apollo 中修改引數值後客戶端是否能及時重新整理
. 3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變
. 4、測試當不能訪問 Apollo 時客戶端的變化
. 5、測試當 Apollo 中將引數刪除後客戶端的變化
. 五、對 Apollo 的 Cluster、Namespace 進行探究
. 1、不同環境下的配置
. 2、不同叢集下的配置
. 3、不同名稱空間下的配置
. 六、Kubernetes 的 SpringBoot 應用使用 Apollo 配置中心
. 1、構建 Docker 映象
. 2、Kubernetes 部署示例應用
. 3、測試部署的應用介面
目錄
-
一、Kubernetes 部署配置中心 Apollo
-
二、SpringBoot 整合 Apollo 配置中心
系統環境
-
SpringBoot 版本:2.1.8.RELEASE
-
Apollo 版本:1.4.0
參考地址
-
Apollo 文件知識
-
Apollo Github 地址
-
SpringBoto 整合 Apollo 示例專案 Github 地址:https://github.com/my-dlq/blog-example/tree/master/springboot/springboot-apollo-demo
一、基本概念
由於 Apollo 概念比較多,剛開始使用比較複雜,最好先過一遍概念再動手實踐嘗試使用。
1、背景
隨著程式功能的日益複雜,程式的配置日益增多,各種功能的開關、引數的配置、伺服器的地址……對程式配置的期望值也越來越高,配置修改後實時生效,灰度釋出,分環境、分叢集管理配置,完善的許可權、稽核機制…… 在這樣的大環境下,傳統的透過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求。因此 Apollo 配置中心應運而生!
2、簡介
Apollo(阿波羅)是攜程框架部門研發的開源配置管理中心,能夠集中化管理應用不同環境、不同叢集的配置,配置修改後能夠實時推送到應用端,並且具備規範的許可權、流程治理等特性。
特點
-
部署簡單
-
灰度釋出
-
版本釋出管理
-
提供開放平臺API
-
客戶端配置資訊監控
-
提供Java和.Net原生客戶端
-
配置修改實時生效(熱釋出)
-
許可權管理、釋出稽核、操作審計
-
統一管理不同環境、不同叢集的配置
基礎模型
如下即是 Apollo 的基礎模型:
(1)、使用者在配置中心對配置進行修改併發布
(2)、配置中心通知Apollo客戶端有配置更新
(3)、Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到應用
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 的某些配置。
-
繼承,並且可以用於覆蓋公共 Namespace 的某些配置。
6、本地快取
Apollo客戶端會把從服務端獲取到的配置在本地檔案系統快取一份,用於在遇到服務不可用,或網路不通的時候,依然能從本地恢復配置,不影響應用正常執行。
本地快取路徑預設位於以下路徑,所以請確保/opt/data或C:\opt\data\目錄存在,且應用有讀寫許可權。
-
Mac/Linux: /opt/data/{appId}/config-cache
-
Windows: C:\opt\data{appId}\config-cache
本地配置檔案會以下面的檔名格式放置於本地快取路徑下:
1 {appId}+{cluster}+{namespace}.properties
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 請求。
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 程式中
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 自動切換到其它存活的資料中心 |
二、Apollo 配置中心建立專案與配置
接下來我們將建立一個 Apollo 的客戶端專案,引用 Apollo 來實現配置動態更新,不過在此之前我們需要提前進入 Apollo Portal 介面,在裡面提前建立一個專案並在其配置一個引數,方便後續客戶端引入該配置引數,測試是否能動態變化。
1、登入 Apollo
我這裡是部署到 Kubernetes 中,透過 NodePort 方式暴露出一個埠,開啟這個地址登入 Apollo:
-
使用者名稱:apollo
-
密 碼:admin
2、修改與增加部門資料
在登入後建立專案時,選擇部門預設只能選擇 Apollo 自帶的 測試部門1與測試部門2兩個選項。
開始這真讓人迷糊,原來 Apoloo 沒有修改或新增部門資訊的管理節目,只能透過修改資料庫,來新增或者修改資料,這裡開啟
Portal
對月的資料庫中的表
ApolloPortalDB
修改
key
為
organizations
的
value
的 json 資料,改成自己對於的部門資訊。
3、建立一個專案
修改完資料庫部門資訊後,重新登入 Apollo Portal,然後建立專案,這時候選擇部門可以看到已經變成我們自己修改後的部門資訊了,選擇我們自定義部門,然後設定應用 ID 為
apollo-test
,應用名為
apollo-demo
。
建立完成後進入配置管理介面
4、建立一個配置引數
建立一個配置引數,方便後續 Apollo 客戶端專案引入該引數,進行動態配置測試。
設定 key 為
test
value 為
123456
然後設定一個備註,儲存。
建立完成後可以看到配置管理節目新增了一條配置。
接下來我們將此配置透過釋出按鈕,進行釋出。
三、建立 Apollo 客戶端測試專案
這裡建立一個 SpringBoot 專案,引入 Apollo 客戶端來來實現與 Apollo 配置中心服務端互動。
1、Maven 新增 Apollo 依賴
1
2
<
project
xmlns=
"
xmlns:xsi=
"
3
xsi:schemaLocation=
">
4
<
modelVersion>4.0.0
</
modelVersion>
5
6
<
parent>
7
<
groupId>org.springframework.boot
</
groupId>
8
<
artifactId>spring-boot-starter-parent
</
artifactId>
9
<
version>2.1.8.RELEASE
</
version>
10
</
parent>
11
12
<
groupId>club.mydlq
</
groupId>
13
<
artifactId>apollo-demo
</
artifactId>
14
<
version>0.0.1
</
version>
15
<
name>apollo-demo
</
name>
16
<
description>Apollo Demo
</
description>
17
18
<
properties>
19
<
java.version>1.8
</
java.version>
20
</
properties>
21
22
<
dependencies>
23
<
dependency>
24
<
groupId>org.springframework.boot
</
groupId>
25
<
artifactId>spring-boot-starter-web
</
artifactId>
26
</
dependency>
27
<
dependency>
28
<
groupId>com.ctrip.framework.apollo
</
groupId>
29
<
artifactId>apollo-client
</
artifactId>
30
<
version>1.4.0
</
version>
31
</
dependency>
32
</
dependencies>
33
34
<
build>
35
<
plugins>
36
<
plugin>
37
<
groupId>org.springframework.boot
</
groupId>
38
<
artifactId>spring-boot-maven-plugin
</
artifactId>
39
</
plugin>
40
</
plugins>
41
</
build>
</
project>
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 的日誌資訊。
1#應用配置
2server:
3 port:
8080
4spring:
5 application:
6 name: apollo-demo
7
8
#Apollo 配置
9app:
10 id: apollo-test #應用
ID
11apollo:
12 cacheDir: /opt/data/ #配置本地配置快取目錄
13 cluster: default #指定使用哪個叢集的配置
14 meta: http://
192.168
.2
.11:
30002
#DEV環境配置中心地址
15 autoUpdateInjectedSpringProperties:
true #是否開啟
Spring 引數自動更新
16 bootstrap:
17 enabled:
true #是否開啟
Apollo
18 namespaces: application #設定
Namespace
19 eagerLoad:
20 enabled:
false #將
Apollo 載入提到初始化日誌系統之前
3、建立測試 Controller 類
寫一個 Controller 類來輸出 test 變數的值,使用了
Spring
的
@Value
註解,用於讀取配置檔案中的變數的值,這裡來測試該值,專案啟動後讀取到的變數的值是設定在 application 配置檔案中的預設值,還是遠端 Apollo 中的值,如果是 Apollo 中配置的值,那麼再測試在 Apollo 配置中心中改變該變數的值後,這裡是否會產生變化。
1
import
org
.springframework
.beans
.factory
.annotation
.Value;
2
import
org
.springframework
.web
.bind
.annotation
.GetMapping;
3
import
org
.springframework
.web
.bind
.annotation
.RestController;
4
5
@
RestController
6
public
class
TestController {
7
8
@
Value(
"${
test:預設值}")
9
private
String
test;
10
11
@
GetMapping(
"/
test")
12
public String
test(){
13
return
"
test的值為
:" +
test;
14 }
15}
4、建立啟動類
SpringBoot 專案啟動類。
1
import org.springframework.boot.SpringApplication;
2
import org.springframework.boot.autoconfigure.SpringBootApplication;
3
4
@SpringBootApplication
5
public
class
Application {
6
7
public
static
void
main(String[] args) {
8 SpringApplication.run(Application.
class, args);
9 }
10
11}
5、JVM 啟動引數新增啟動引數
由於本人的 Apollo 是部署在 Kubernetes 環境中的,JVM 引數中必須新增兩個變數:
-
env: 應用使用 Apollo 哪個環境,例如設定為
DEV
就是指定使用開發環境,如果設定為PRO
就是制定使用生產環境。 -
apollo.configService: 指定配置中心的地址,跳過 meta 的配置,在測試時指定 meta 地址無效果。如果 Apollo 是部署在 Kubernetes 中,則必須設定該引數為配置中心地址,如果 Apollo 不是在 Kubernetes 環境中,可以不設定此引數,只設定 meta 引數即可。一般情況下,configService 和 meta 值一致。
如果是在 Idea 中啟動,可以配置啟動引數,加上:
1-Dapollo.configService=
http:
//192.168.2.11:30002 -Denv=DEV
如果是 java 命令啟動程式,需要 JVM 加上:
1$ java -Dapollo.configService=
http:
//192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar
注意:上面 env 指定的環境,要和 apollo.meta 指定 Config 地址的環境一致,例如 -Denv=DEV 即使用開發環境,那麼 apollo.meta=這個url 的 Config 也是開發環境下的配置中心服務,而不能是 PRO 或者其它環境下的配置中心。
四、啟動專案進行測試
1、測試是否能夠獲取 Apollo 中設定的值
啟動上面的測試用例,然後輸入地址 檢視:
1test的值為
:123456
可以看到使用的是 Apollo 中配置的
test
引數的值
123456
,而不是預設的值。
2、測試當 Apollo 中修改引數值後客戶端是否能及時重新整理
修改 Apollo 配置中心引數
test
值為
666666
,然後再次釋出。
釋出完成後再次輸入地址 檢視:
1test的值為
:666666
可以看到示例應用中的值已經改變為最新的值。
3、測試當 Apollo 執行配置回滾操作時客戶端是否能及時改變
回滾完成後狀態將變為未釋出狀態,則時候輸入地址 檢視:
1test的值為
:123456
可以看到已經回滾到之前的
test
配置的值了。
4、測試當不能訪問 Apollo 時客戶端的變化
這裡我們將 JVM 引數中 Apollo 配置中心地址故意改錯:
1-Dapollo.configService=
http:
//192.168.2.100:30002 -Denv=DEV
然後輸入地址 可以看到值為:
1test的值為
:123456
可以看到顯示的值並不是我們定義的預設值,而還是 Apollo 配置中心配置的
test
引數的值。考慮到由於 Apollo 會在本地將配置快取一份,出現上面原因,估計是快取生效。當客戶端不能連線到 Apollo 配置中心時候,預設使用本地快取檔案中的配置。
上面我們配置了本地快取配置檔案存放地址為 “/opt/data/” ,接下來進入快取目錄,找到對應的快取配置檔案,刪除快取配置檔案後,重啟應用,再次輸入地址檢視:
1test的值為:預設值
刪除快取配置檔案後,可以看到輸出的值為自己定義的預設值。
5、測試當 Apollo 中將引數刪除後客戶端的變化
這裡我們進入 Apollo 配置中心,刪除之前建立的
test
引數,然後釋出。
然後再次開啟地址 檢視:
1test的值為:預設值
可以看到顯示的是應用程式中設定的預設值。
五、對 Apollo 的 Cluster、Namespace 進行探究
在 Apollo 中,配置可以根據不同的環境劃分為 Dev(開發)、Prod(生產) 等環境,又能根據區域劃分為不同的 Cluster(叢集),還能根據配置引數作用功能的不同劃分為不同的 Namespace(名稱空間),這裡探究下,如何使用上述能力。
1、不同環境下的配置
(1)、Apollo 配置中心 PRO 環境新增引數
開啟 Apollo 配置中心,環境列表點選 PRO 環境,然後新增一條配置,和之前例子中引數保持一致,都為
test
引數,建立完成後釋出。
然後修改上面的示例專案,將配置引數指定為 PRO 環境:
(2)、示例專案修改 application.yml 配置檔案
把
apollo.meta
引數改成 RPO 的配置中心地址
1.....
.
2
3
apollo:
4
meta:
http:
//192.168.2.11:30005 #RPO環境配置中心地址
5
6......
(3)、示例專案修改 JVM 引數
把
apollo.configService
引數改成 PRO 配置中心地址,
env
引數的值改為
PRO
。
1-Dapollo.configService=
http:
//192.168.2.11:30005 -Denv=PRO
(4)、啟動示例專案觀察結果
啟動示例專案,然後接著輸入地址 檢視資訊:
1test的值為
:abcdefg
可以看到已經改成生成環境配置,所以在實際專案中,如果要更換環境,需要修改 JVM 引數
env
(如果 Apollo 部署在 Kubernetes 環境中,還需要修改
apollo.configService
引數),和修改 application.yml 配置檔案的引數
apollo.meta
值。
2、不同叢集下的配置
(1)、建立兩個叢集
例如在開發過程中,經常要將應用部署到不同的機房,這裡分別建立
beijing
、
shanghai
兩個叢集。
(2)、兩個叢集都配置同樣的引數不同的值
在兩個叢集
beijing
與
shanghai
中,都統一配置引數
test
,並且設定不同的值。
(3)、示例專案 application.yml 修改叢集配置引數,並啟動專案觀察結果
指定叢集為 beijing:
1.....
.
2
3apollo
:
4
cluster:
beijing #指定使用
beijing 叢集
5
6......
啟動示例專案,然後接著輸入地址 檢視資訊:
1test的值為
:Cluster-BeiJing
可以看到用的是 beijing 叢集的配置
指定叢集為 shanghai:
1.....
.
2
3apollo
:
4
cluster:
shanghai #指定使用
shanghai 叢集
5
6......
啟動示例專案,然後接著輸入地址 檢視資訊:
1test的值為
:Cluster-ShangHai
可以看到用的是 shanghai 叢集的配置
3、不同名稱空間下的配置
(1)、建立兩個名稱空間
名稱空間有兩種,一種是 public(公開),一種是 private 私有,公開名稱空間所有專案都能讀取配置資訊,而私有的只能
app.id
值屬於該應用的才能讀取配置。
這裡建立
dev-1
與
dev-2
兩個私有的名稱空間,用於測試。
(2)、兩個叢集都配置同樣的引數不同的值
在兩個名稱空間中,都統一配置引數
test
,並且設定不同的值,設定完後釋出。
(3)、示例專案 application.yml 修改名稱空間配置引數,並啟動專案觀察結果
指定名稱空間為 dev-1:
1.....
.
2
3apollo
:
4
bootstrap
:
5
namespaces:
dev-1 #設定
dev-1 名稱空間
6
7......
啟動示例專案,然後接著輸入地址 檢視資訊:
1test的值為
:dev-
1 Namespace
可以看到用的是 dev-1 名稱空間的配置
指定名稱空間為 dev-2:
1.....
.
2
3apollo
:
4
bootstrap
:
5
namespaces:
dev-2 #設定
dev-1 名稱空間
6
7......
啟動示例專案,然後接著輸入地址 檢視資訊:
1test的值為
:dev-
2 Namespace
可以看到用的是 dev-2 名稱空間的配置
六、Kubernetes 的 SpringBoot 應用使用 Apollo 配置中心
本人的 Apollo 和 SpringBoot 應用一般都是基於 Kubernetes 部署的,所以這裡簡單介紹下,如何在 Kubernetes 環境下部署 SpringBoot 應用且使用 Apollo 作為配置中心。
這裡專案依舊使用上面的示例,不過首先要將其編譯成 Docker 映象,方便後續部署到 Kubernetes 環境下。
1、構建 Docker 映象
(1)、執行 Maven 編譯
首先執行 Maven 命令,將專案編譯成一個可執行 JAR。
1$
mvn clean install
(2)、準備 Dockerfile
建立構建 Docker 映象需要的 Dockerfile 檔案,將 Maven 編譯的 JAR 複製到映象內部,然後設定兩個變數,分別是:
-
JAVA_OPTS: Java JVM 啟動引數變數,這裡需要在這裡加一個時區引數。
-
APP_OPTS: Spring 容器啟動引數變數,方便後續操作時能透過此變數配置 Spring 引數。
Dockerfile:
1
FROM openjdk:
8u222-jre-slim
2VOLUME /tmp
3ADD target/*.jar app.jar
4RUN sh -c
'touch /app.jar'
5
ENV JAVA_OPTS=
"-Duser.timezone=Asia/Shanghai"
6
ENV APP_OPTS=
""
7ENTRYPOINT [
"sh",
"-c",
"java
$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar
$APP_OPTS" ]
(3)、構建 Docker 映象
執行 Docker Build 命令構建 Docker 映象。
1$
docker build -t mydlqclub/springboot-apollo:0.0.1 .
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
1
apiVersion:
v1
2
kind:
Service
3
metadata:
4
name:
springboot-apollo
5
spec:
6
type:
NodePort
7
ports:
8
-
name:
server
9
nodePort:
31080
10
port:
8080
11
targetPort:
8080
12
-
name:
management
13
nodePort:
31081
14
port:
8081
15
targetPort:
8081
16
selector:
17
app:
springboot-apollo
18
---
19
apiVersion:
apps/v1
20
kind:
Deployment
21
metadata:
22
name:
springboot-apollo
23
labels:
24
app:
springboot-apollo
25
spec:
26
replicas:
1
27
selector:
28
matchLabels:
29
app:
springboot-apollo
30
template:
31
metadata:
32
name:
springboot-apollo
33
labels:
34
app:
springboot-apollo
35
spec:
36
restartPolicy:
Always
37
containers:
38
-
name:
springboot-apollo
39
image:
mydlqclub/springboot-apollo:0.0.1
40
imagePullPolicy:
Always
41
ports:
42
-
containerPort:
8080
43
name:
server
44
env:
45
-
name:
JAVA_OPTS
46
value:
"-Denv=DEV"
47
##注意修改此處的 mydlqcloud 為你自己的 Namespace 名稱
48 - name: APP_OPTS
49 value: "
50 -- app.id=apollo-demo
51 -- apollo.bootstrap.enabled=true
52 -- apollo.bootstrap.eagerLoad.enabled=false
53 -- apollo.cacheDir=/opt/data/
54 -- apollo.cluster=default
55 -- apollo.bootstrap.namespaces=application
56 -- apollo.autoUpdateInjectedSpringProperties=true
57 -- apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080
58 "
59 resources:
60 limits:
61 memory: 1000Mi
62 cpu: 1000m
63 requests:
64 memory: 500Mi
65 cpu: 500m
(2)、部署 SpringBoot 應用到 Kubernetes
-n:建立應用到指定的 Namespace 中。
1$ kubectl apply -f springboot-apollo.yaml -n mydlqcloud
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69969697/viewspace-2683850/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SpringBoot整合Apollo配置中心Spring Boot
- Springboot 整合Apollo配置中心【記錄】Spring Boot
- 使用Spring Boot整合Apollo配置中心Spring Boot
- SpringBoot 整合 apolloSpring Boot
- SpringBoot(19)---SpringBoot整合ApolloSpring Boot
- springboot整合nacos註冊中心和配置中心Spring Boot
- Docker部署Apollo配置中心Docker
- apollo與springboot整合實現動態重新整理配置Spring Boot
- 攜程 Apollo 配置中心傳統 .NET 專案整合實踐
- Linux安裝Apollo配置中心Linux
- Apollo 配置中心詳細教程
- .NET Core 下使用 Apollo 配置中心
- Apollo 分散式配置中心(補充)分散式
- Apollo配置中心-配置熱釋出如何實現
- 配置中心的設計-nacos vs apollo
- apollo配置中心啟動遇到的問題
- Dubbo使用Apollo作為配置中心實戰
- 聊聊如何將資料同步到apollo配置中心
- SpringBoot使用Nacos配置中心Spring Boot
- ABP微服務系列學習-對接Apollo配置中心微服務
- YoyoGo v1.7.2 釋出, 支援 Nacos & Apollo 配置中心Go
- SpringBoot整合Dubbo,註冊中心nacosSpring Boot
- springboot整合kafka配置方式Spring BootKafka
- springboot 整合 Shiro 配置類Spring Boot
- Springboot整合外部Tomcat配置Spring BootTomcat
- Spring Boot 整合 ApolloSpring Boot
- springcloud/springboot整合NACOS 做註冊和配置中心以及nacos原始碼分析GCCloudSpring Boot原始碼
- 整合 nacos註冊中心配置使用
- SpringBoot專案使用Nacos作為配置中心Spring Boot
- springboot工程dubbo使用nacos作為配置中心Spring Boot
- Solon2 專案整合 Nacos 配置中心
- SpringBoot整合Nacos自動重新整理配置Spring Boot
- SpringBoot使用Nacos作為配置中心服務和服務註冊中心Spring Boot
- Spring Boot實戰系列(7)整合Consul配置中心Spring Boot
- SpringBoot整合MyBatisPlus配置動態資料來源Spring BootMyBatis
- jackson學習之九:springboot整合(配置檔案)Spring Boot
- 初探Nacos(四)-- SpringBoot下使用Nacos作為配置中心Spring Boot
- SpringBoot與Dubbo整合報錯排查(Nacos作為註冊中心)Spring Boot