如何分析Spring Cloud Config 配置

今天給大家介紹一下如何分析Spring Cloud Config 配置。文章的內容小編覺得不錯，現在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著小編的思路一起來閱讀吧。

 Spring Cloud Config Server 配置服務

Spring為擴展配置服務，提供了一個基于HTTP的資源綁定的api。（鍵值對，或者YAML內容） 此服務可以通過@EnableConfigServer非常容易的整合進Spring Boot應用中。

例如：ConfigServer.java

@SpringBootApplication
@EnableConfigServer
public class ConfigServer {
  public static void main(String[] args) {
    SpringApplication.run(ConfigServer.class, args);
  }
}

默認情況下，和Spring Boot應用一樣運行在8080端口，當然也有很多種方法修改此端口。最簡單的方法，設置默認的配置資源庫。 通過在jar中configserver.yml文件中配置spring.config.name=configserver；或者通過指定自己的configserver.yml。

例如：application.properties

server.port: 8888
spring.cloud.config.server.git.uri: file://${user.home}/config-repo

${user.home}/config-repo,是一個git資源。內容為YAML或者properties文件內容。

例如：

$ cd $HOME
$ mkdir config-repo
$ cd config-repo
$ git init .
$ echo info.foo: bar > application.properties
$ git add -A .
$ git commit -m "Add application.properties"

注意： 以上使用本地文件只是為了測試。生產中應該使用遠程服務提供的配置資源。

1 Environment Repository 環境資源

在Config Server中，對于配置數據你想要怎么樣存儲呢？存儲策略由Environment 中的EnvironmentRepository來決定。同時多個Environment之間也允許復制配置項，甚至配置源propertySources。

Environment資源主要來自這三個參數：

• {application}對應著客戶端的spring.application.name配置；

• {profile}對應著客戶端spring.profiles.active配置；

• {label}這是一個服務端功能，標記著配置文件的版本。

資源實例通常表現和Srping Boot應用加載配置文件類似：spring.config.name類似于{application}參數;spring.profiles.active類似于{profiles}參數。 對于特定配置文件的優先級也是類似Spring Boot的規則：特定的配置會覆蓋默認配置，并且如果指定了多個，那最后一個優先級最高。

例如：一個客戶端應用可以配置一下引導配置：

bootstrap.yml

spring:
  application:
    name: foo
  profiles:
    active: dev,mysql

普通Spring Boot應用也可以通過環境變量或者命令行方式配置以上信息

如果資源是基于文件方式的，那系統會從application.yml創建一個Environment共享給所有客戶端，并且加載foo.yml進行覆蓋。 如果YAML文件中有指定特定配置的話，那么這些特定配置比默認配置擁有著更高的優先級。 這些擁有更高優先級的配置文件在Environment之前，就逐個生成PropertySource并被加載。

1.1 Git Backend 基于GIT

默認情況下EnvironmentRepository是基于GIT的，這樣非常方便管理更新、物理環境也方便對修改歷史進行審計。 可以通過spring.cloud.config.server.git.uri配置屬性修改Config Server的本地資源庫（例如：在application.yml中修改）。 如果設置成file：前綴，那會從本地資源進行加載，這樣方便你快速簡易的啟動服務。但是這樣就是直接在本地資源庫上進行操作，沒有備份。（不過如果遠程服務資源是不變得情況下，這種方式也無所謂。）

如果需要擴展Config Server使其具備高可用性，那你需要將所有的服務實例指向同一個資源，這樣就工作在一個共享文件的環境下。在這個情況下最好使用ssh:協議去訪問共享文件資源，這樣可以備份資源同時可以使用本地緩存提高效率。

資源實例會把HTTP資源中的{label}映射成git標簽(commit id, branch name 或者 tag) 如果git分支或者標簽名上有斜杠"/"那映射成HTTP URL時會自動替換成"_"。使用括號、空格時需要小心。（例如使用cmd時需要加上雙引號）

1.1.1 Placeholders in Git URI ：git uri 中的占位符

當需要時，Spring Cloud Config Server 支持在GIT URI中使用{application}、{profile}、{label}三個占位符，但是要記住{label}總是會映射成git的標簽。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/myorg/{application}

1.1.2 Pattern Matching and Multiple Repositories 正則與多資源庫

在應用配置文件與特定配置文件中可以同過正則表達式來支持更為復雜的情況。可以在{application}/{profile}中可以使用通配符進行匹配，如果有多個值可以使用逗號分隔。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          repos:
            simple: https://github.com/simple/config-repo
            special:
              pattern: special*/dev*,*special*/dev*
              uri: https://github.com/special/config-repo
            local:
              pattern: local*
              uri: file:/home/configsvc/config-repo

如果{application}/{profile}沒有匹配到任何資源，則使用spring.cloud.config.server.git.uri配置的默認URI。

上面例子中pattern屬性是一個YAML數組，也可以使用YAML數組格式來定義。這樣可以設置成多個配個配置文件。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          repos:
            development:
              pattern:
                - */development
                - */staging
              uri: https://github.com/development/config-repo
            staging:
              pattern:
                - */qa
                - */production
              uri: https://github.com/staging/config-repo

每個資源庫有一個可選的配置，用來指定掃描路徑。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          searchPaths: foo,bar*

這樣系統就會自動搜索foo的子目錄，以及以bar開頭的文件夾中的子目錄。

默認情況下，當第一次請求配置時，系統復制遠程資源庫。系統也可以配置成一啟動就復制遠程資源庫。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://git/common/config-repo.git
          repos:
            team-a:
                pattern: team-a-*
                cloneOnStart: true
                uri: http://git/team-a/config-repo.git
            team-b:
                pattern: team-b-*
                cloneOnStart: false
                uri: http://git/team-b/config-repo.git
            team-c:
                pattern: team-c-*
                uri: http://git/team-a/config-repo.git

上面的例子中team-a的資源庫會在啟動時就從遠程資源庫進行復制，其他的則等到第一次請求時才從遠程資源庫復制。

如果遠程資源庫設置了權限認證，則可以如下配置：

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          username: trolley
          password: strongpassword

如果你不是用HTTPS和用戶認證，可以使用SSH uri 的格式。例如：git@github.com:configuration/cloud-configuration 這樣你就需要先有SSH的key。 這種方式系統會使用JGit庫進行訪問，可以去查看相關文檔。可以在~/.git/config中設置HTTPS代理配置，或者也可以通過JVM參數-Dhttps.proxyHost、-Dhttps.proxyPort來配置代理。

提示： 當你不知道你的~/.git目錄時，可以使用git config --global來指定。例如：git config --global http.sslVerify false

3.2.1.1.3 Placeholders in Git Search Paths : GIT路徑搜索中的占位符

Spring Cloud 的 Config Server 也支持在搜索路徑中使用{application}、{profile}、{label}占位符配置。例如：

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          searchPaths: '{application}'

1.2 File System Backend 基于文件系統

也有不使用git資源庫的方式，那就是從本地classpath或者文件系統加載配置文件。這種方式可以通過spring.profiles.active=native開啟。

使用file:前綴加載文件系統，否則從classpath中加載，也可以使用${}樣式的環境占位符。例如：file:///${user.home}/config-repo

searchLocations默認值與本地Spring Boot應用的掃描路徑一樣，都是：[classpath:/, classpath:/config, file:./, file:./config] 這樣并不用擔心application.properties文件暴露給所有客戶端，因為在發送給客戶端之前就會被清理掉。

基于文件系統的配置服務對于測試和快速練手來說是比較好的，如果用于生產環境，那就需要確保文件系統的可靠性，并允許共享訪問。

路徑搜索時能夠包含{application}、{profile}、{label}，這樣方便你按照目錄來管理你的配置文件。

如果在路徑搜索時不使用占位符，那也會嘗試自動的在HTTP資源中加上{label}后綴，那這樣就會從不同的路徑加載到。因此，在默認情況下不使用占位符等價于在每一個路徑后添加了/{label}/。例如：file:/tmp/config 就等價于 file:/tmp/config,file:/tmp/config/{label}

1.3 Sharing Configuration With All Applications 應用共享配置

通過基于文件（svn，本地）資源，文件名為application*的資源將在所有的應用客戶端中共享。（application.properties,application.yml,application-*.properties） 可以通過這種方式來定義一個全局的默認配置，如有必要應用可以使用應用指定配置對其進行覆蓋。

1.4 Property Overrides 屬性覆蓋

Config Server 有一個屬性覆蓋的特性，允許操作者通過提供一個配置屬性去覆蓋所有應用中的配置。通過普通的Spring Boot鉤子方式來實現，因此應用不需要什么改變。

聲明覆蓋僅僅需要在spring.cloud.config.server.overrides中配置一個鍵值對。例如：

spring:
  cloud:
    config:
      server:
        overrides:
          foo: bar

這樣會引起所有的應用客戶端去讀取foo=bar去覆蓋自己的配置。（當然應用拿到新的數據后自己決定如何使用，因此，覆蓋并不是強制的，客戶端可以自定義拿到新數據后的行為）

提示： 使用文件方式時，Spring環境中的占位符${}可以用""對"$"轉義,例如：\${app.foo:bar} 。當使用YAML時，YAML本身會處理，因此不需要轉義。

2.2 Health Indicator 健康指示器

Config Server 通過一個健康指示器來檢測配置的EnvironmentRepository是否正常工作。 默認情況下會向EnvironmentRepository詢問一個名字為app的應用配置，EnvironmentRepository實例回應default配置。

可以通過配置讓健康指示器一起去檢查多個應用的多個配置。例如：

spring:
  cloud:
    config:
      server:
        health:
          repositories:
            myservice:
              label: mylabel
            myservice-dev:
              name: myservice
              profiles: development

也可以通過配置spring.cloud.config.server.health.enabled=false去關閉此功能。

2.2 Security 安全

你可以按你自己的情況用任何方法對Config Server進行安全處理。（從物理網絡安全到OAuth3授權token），不過通過Spring Security 結合Spring Boot能提供一種更好的方式。

使用Spring Boot默認的基于HTTP安全方式，僅僅需要引入Spring Security依賴。（如：可以通過spring-boot-starter-security）

默認情況使用一個用戶名和一個隨機產生的密碼，這種方式并不是很靠譜，因此，建議通過spring-boot-starter-security配置密碼，并對其進行加密處理。

2.3 Encryption and Decryption 加解密

重要：要使用此特性，需要完全的JCE授權，方法參見前文

如果遠程資源是一個經過加密的內容（以{cipher}開頭），在發送給客戶端之前會被解密。 這樣，配置內容就不用明文存放了。 當直接去替換一個沒有解密的值時，會被標記為"invalid"(無效的)。 這基本上可以大部分的杜絕密鑰泄露的發生。例如：

application.yml

spring:
  datasource:
    username: dbuser
    password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'

如果使用配置文件則加密數據不要加上雙引號。例如：

application.properties

spring.datasource.username: dbuser
spring.datasource.password: {cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ

這樣就可以安全共享此文件，同時可以保護密鑰。

這個服務通過/encrypt和/decrypt端點向外暴露。這樣就可以用過POST方式向/encrypt提交加密后的數據。例如：

$ curl localhost:8888/encrypt -d mysecret
682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

反過來也行，通過/decrypt安全提交數據。（前提是已經在服務端配置了相應的解密KEY）

$ curl localhost:8888/decrypt -d 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
mysecret

在提交之前，存放這些加密數據存在著潛在的不安全性。

/encrypt 和 /decrypt 都接受一個路徑/*/{name}/{profiles}用于分開控制每一個應用的密碼。

注意： 如果需要為每一個應用使用不同的密碼，則需要一個@Bean產生一個TextEncryptorLocator對象來創建不同的密鑰對，并給它們賦予一個名字。當然這是可選的，默認不需要這樣（所有應用使用相同的密鑰）

Spring 命令行客戶端（Spring Cloud CLI）也可以使用加解密特性。例如：

$ spring encrypt mysecret --key foo
682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
$ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
mysecret

可以使用@來指定一個路徑，包含一個存放加解密key 的文件。例如：

$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...

2.4 Key Management 密鑰管理

Config Server 可以使用對稱/非對稱加解密算法。使用非對稱算法擁有更好的安全性，但是對稱算法更方便。

配置對稱算法的key，只需要設置encrypt.key就行了。（或者使用環境變量ENCRYPT_KEY）

配置非對稱算法key，你可以選擇在encrypt.key中配置一個PEM編碼的文本，也可以通過encrypt.keyStore.*配置使用一個密鑰庫。

encrypt.keyStore.*包括如下配置：

• location 一個資源路徑

• password 密鑰庫密碼

• alias 被使用的密鑰標識

通過公鑰加密，私鑰解密。因此，原則上可以在服務端只配置公鑰。但是實踐中可能很少這樣做，密鑰管理在全部客戶端處理過程都會被包含，而不僅僅是服務端。不過從另一方面說，如果服務端 真的不安全，而且只有少數幾個客戶端需要加密處理，那這樣配置也有一定的合理性。

 2.5 Creating a Key Store for Testing 創建一個密鑰庫用于測試

可以通過如下配置來創建一個用于測試的密鑰庫：

$ keytool -genkeypair -alias mytestkey -keyalg RSA \
  -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" \
  -keypass changeme -keystore server.jks -storepass letmein

把server.jks文件放入classspath，然后在application.yml中進行以下配置：

encrypt:
  keyStore:
    location: classpath:/server.jks
    password: letmein
    alias: mytestkey
    secret: changeme

2.6 Using Multiple Keys and Key Rotation 使用多重密鑰以及密鑰輪換

通過添加{cipher}前綴來表明使用加密數據，系統會在對密文進行Base64解碼之前尋找{name:value}前綴信息。密鑰通過TextEncryptorLocator（無論哪種）實例，最終使用TextEncryptor來完成加解密。 如果配置了密鑰庫（encrypt.keystore.location）,那默認的執行器（locator）就會按照配置的alias去密鑰庫中查找相應的密鑰。例如：

foo:
  bar: `{cipher}{key:testkey}...`

上例中執行器（locator）將會去查找一個叫做“testkey”的密鑰。密鑰庫的密碼可以通過{secret:…}來指定，但是如非必要一般不指定。如果想使用密鑰庫密碼，那建議使用定制SecretLocator對其加密處理。

如果只是對很少的配置數據進行加密的話，密鑰輪換基本上沒有必要。 但是，偶還還是會有需求去修改密鑰的場景。在這種情況下，所有的客戶端都需要改變源配置文件（如：git）來使用新的{key:…},最好還要事先檢查密鑰庫中的密鑰。

提示： {name:value}也可以在/encrypt數據請求時使用。

2.7 Serving Encrypted Properties 提供加密屬性

有的時候需要客戶端對配置數進行解密，而不是在服務端解密。這種情況下，仍然可以通過/encrypt和/decrypt端點訪問。那就需要明確指定配置數據在服務端發出時不解密：spring.cloud.config.server.encrypt.enabled=false。如果不關系端點訪問，那就既不要配置密鑰也不要開啟此配置。

以上就是如何分析Spring Cloud Config 配置的全部內容了，更多與如何分析Spring Cloud Config 配置相關的內容可以搜索億速云之前的文章或者瀏覽下面的文章進行學習哈！相信小編會給大家增添更多知識,希望大家能夠支持一下億速云！