4 sposoby na organizację konfiguracji w repozytorium

Jeśli używasz Spring Cloud Config warto zwrócić uwagę na to jak wygląda twoja organizacja konfiguracji w repozytorium GIT. Dobre jej zaprojektowanie umożliwi Ci wykorzystanie pełnej historii, tagów oraz branchy w sposób efektywny.

Założenia naszego ekosystemu

Na początek, zdefiniujmy kilka założeń, aby było jasne jaką sytuację rozważamy.

mamy wiele aplikacji
każda aplikacja to ekosystem mikroserwisów
mamy 4 środowiska: dev, uat, stage i prod
na chwilę obecną, mamy 2 aplikacje składające się z kilku mikroserwisów:
- SHOP
  - shop-invoices
  - shop-products
- CRM
  - crm-customers
  - crm-mail

Spójrzmy teraz na cztery opcję przygotowania repozytorium i skonfigurowania serwera.

Repozytorium per aplikacja i branch per środowisko
Branch per aplikacja i środowisko
Branch per aplikacja
Branch per środowisko

Od razu zaznaczę, że zdecydowanie, moim faworytem jest pierwsza opcja, ponieważ daje nam największą elastyczność. Jednak, drugi wariant jest też dosyć dobrym kompromisem, jeśli chcemy mieć tylko jedno repozytorium. Przeanalizujmy każdą opcję z osobna.

1. Repozytorium per aplikacja i branch per środowisko

Zawartość repozytorium

(dev) shop-invoices/application.yml
(dev) shop-products/application.yml

(uat) shop-invoices/application.yml
(uat) shop-products/application.yml

(stage) shop-invoices/application.yml
(stage) shop-products/application.yml

(prod) shop-invoices/application.yml
(prod) shop-products/application.yml

(dev) crm-customers/application.yml
(dev) crm-mail/application.yml

(uat) crm-customers/application.yml
(uat) crm-mail/application.yml

(stage) crm-customers/application.yml
(stage) crm-mail/application.yml

(prod) crm-customers/application.yml
(prod) crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           repos:
             shop:
                 pattern: shop-*
                 uri: "https://github.com/lmonkiewicz/shop"
                 search-paths:
                     - '{application}/'
                 default-label: 'main'
             crm:
                 pattern: crm-*
                 uri: "https://github.com/lmonkiewicz/crm"
                 search-paths:
                     - '{application}/'
                 default-label: 'main'

W aplikacjach klienckich używamy parametru label jako nazwy środowiska (dev, uat, state, prod).

Plusy

Każda aplikacja jest odseparowana od pozostałych
Możliwość kontroli uprawnień per repozytorium i dodatkowo per branch (do aplikacji i do środowisk)
Możemy użyć profili springowych
Możemy użyć git merge do przenoszenia konfiguracji ze środowiska niższego na wyższe.
Mała ilość branchy
Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

Każde nowe repozytorium musimy dodać do konfiguracji serwera
Każde repozytorium musimy od nowa skonfigurować

2. Branch per aplikacja i środowisko

Zawartość repozytorium

(shop_dev)   shop-invoices/application.yml
(shop_dev)   shop-products/application.yml
(shop_uat)   shop-invoices/application.yml
(shop_uat)   shop-products/application.yml
(shop_stage) shop-invoices/application.yml
(shop_stage) shop-products/application.yml
(shop_prod)  shop-invoices/application.yml
(shop_prod)  shop-products/application.yml

(crm_dev)   crm-customers/application.yml
(crm_dev)   crm-mail/application.yml
(crm_uat)   crm-customers/application.yml
(crm_uat)   crm-mail/application.yml
(crm_stage) crm-customers/application.yml
(crm_stage) crm-mail/application.yml
(crm_prod)  crm-customers/application.yml
(crm_prod)  crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako kodu aplikacji i środowiska, czyli np. crm_prod dla aplikacji CRM i środowiska PROD.

Plusy

Możliwość kontroli uprawnień per branch (do aplikacji i do środowisk)
Możemy użyć profili springowych
Możemy użyć git merge do przenoszenia konfiguracji ze środowiska niższego na wyższe.
Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

Wszystkie aplikację są w jednym repozytorium
Duża ilość branchy

3. Branch per aplikacja

Zawartość repozytorium

(shop)   shop-invoices/application.yml
(shop)   shop-invoices/application-dev.yml
(shop)   shop-invoices/application-uat.yml
(shop)   shop-invoices/application-stage.yml
(shop)   shop-invoices/application-prod.yml
(shop)   shop-products/application.yml
(shop)   shop-products/application-dev.yml
(shop)   shop-products/application-uat.yml
(shop)   shop-products/application-stage.yml
(shop)   shop-products/application-prod.yml

(crm)   crm-customers/application.yml
(crm)   crm-customers/application-dev.yml
(crm)   crm-customers/application-uat.yml
(crm)   crm-customers/application-stage.yml
(crm)   crm-customers/application-prod.yml
(crm)   crm-mail/application.yml
(crm)   crm-mail/application-dev.yml
(crm)   crm-mail/application-uat.yml
(crm)   crm-mail/application-stage.yml
(crm)   crm-mail/application-prod.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako kodu aplikacji natomiast musimy używać profile aby wybrać odpowiednie środowisko.

Plusy

Możliwość kontroli uprawnień per branch (do aplikacja)
Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

Brak możliwości kontroli uprawnień do środowiska
Wszystkie aplikację są w jednym repozytorium
Duża ilość branchy
Nie możemy używać profili springowych
Nie możemy użyć git merge do przenoszenia konfiguracji

4. Branch per środowisko

Zawartość repozytorium

(dev)   shop-invoices/application.yml
(dev)   shop-products/application.yml
(dev)   crm-customers/application.yml
(dev)   crm-mail/application.yml

(uat)   shop-invoices/application.yml
(uat)   shop-products/application.yml
(uat)   crm-customers/application.yml
(uat)   crm-mail/application.yml

(stage)   shop-invoices/application.yml
(stage)   shop-products/application.yml
(stage)   crm-customers/application.yml
(stage)   crm-mail/application.yml

(prod)   shop-invoices/application.yml
(prod)   shop-products/application.yml
(prod)   crm-customers/application.yml
(prod)   crm-mail/application.yml

Konfiguracja dla Spring Cloud Config Server

spring:
   cloud:
     config:
       server:
         git:
           uri: "https://github.com/lmonkiewicz/config-example"
           search-paths:
             - '{application}/'
           default-label: 'main'

W aplikacjach klienckich używamy parametru label jako nazwy środowiska.

Plusy

Możliwość kontroli uprawnień per branch (do środowiska)
Nie musimy modyfikować konfiguracji serwera dodając nową aplikację
Możemy użyć profile springowe
Mała ilość branchy
Możemy użyć cherry-pick do przenoszenia konfiguracji między środowiskami
Możemy użyć tagów gita w celu wersjonowania konfiguracji (np. crm_mail_2.1.3)

Minusy

Brak możliwości kontroli uprawnień do aplikacji
Wszystkie aplikację są w jednym repozytorium
Nie możemy użyć git merge do przenoszenia konfiguracji ponieważ przenosimy konfigurację wszystkich aplikacji
Mamy bardzo ograniczone możliwości wykorzystania tagów gita

Więcej informacji

Dokumentacja konfiguracji GIT dla Spring Cloud Config

Artykuły na temat konfiguracji

Konfiguracja w Kontenerze – wykorzystanie warstw Dockerowych do przechowywania konfiguracji
Konfiguracja ze zmiennych środowiskowych – wykorzystanie zmiennych środowiskowych do wstrzykiwania parametrów do konfiguracji
Konfiguracja z serwera konfiguracji – wykorzystanie Spring Cloud Config w celu utworzenia serwera konfiguracji
4 sposoby na organizację konfiguracji w repozytorium – porównanie kilku strategii organizacji konfiguracji w repozytorium GIT

Założenia naszego ekosystemu

1. Repozytorium per aplikacja i branch per środowisko

Zawartość repozytorium

Konfiguracja dla Spring Cloud Config Server

Plusy

Minusy

2. Branch per aplikacja i środowisko

Zawartość repozytorium

Konfiguracja dla Spring Cloud Config Server

Plusy

Minusy

3. Branch per aplikacja

Zawartość repozytorium

Konfiguracja dla Spring Cloud Config Server

Plusy

Minusy

4. Branch per środowisko

Zawartość repozytorium

Konfiguracja dla Spring Cloud Config Server

Plusy

Minusy

Więcej informacji

Artykuły na temat konfiguracji

Łukasz Monkiewicz