Hej,
Analizuje sobie trzymanie konfigów w config server z wykorzystaniem Spring Cloud Config.
Dużą zaletą jest możliwość przeładowania konfiguracji bez restartu aplikacji. Zastanawiam się jednak czy nie jest to niebezpieczne. Mamy apkę na prodzie, zmieniamy w konfiguracji jakieś dane i wysyłamy request aby Spring przeładował konfigi.
Czy jest jakiś mechanizm do użycia poprzedniej konfiguracji jeśli nowa się nie wczyta (lub poleci exception)?
0
1
Poprawisz, odświeżysz i zacznie działać.
Zastanów się co się stanie jeżeli będziesz miał konfigurację wewnątrz aplikacji i nie wstanie. Trzeba ją zmienić lokalnie, wrzucić na środowisko, poczekać aż się odpali.
Według mnie, przy sensownym zarządzaniu zmianami możliwość wykopyrtnięcia się aplikacji jest zbliżona, możliwość zareagowania na zdarzenie już nie.
Z opisu wnioskuję, że aplikacja to jednoistancyjny monolit, więc cudów się nie zdziała.
1
Testowanie konfiguracji to raczej skomplikowana sprawa - każde środowisko może mieć inną, ciężko to otestować. Złe wcięcie w yamlu może spowodować awarię.
Automatyczny refresh konfiguracji brzmi spoko, ale czy wtedy aplikacja jest w stanie serwować ruch? Co się wtedy dzieje z healtcheckiem? Jak wyglada rollout takiej zmiany? Manualny restart jest jednak bardziej przewidywalny.
1
Wystarczy spojrzeć na ich dokumentację, i od razu powinna zapalić się czerwona lampka, żeby trzymać się od tego z daleka.
@RefreshScope works (technically) on an @Configuration class, but it might lead to surprising behaviour: e.g. it does not mean that all the @Beans defined in that class are themselves @RefreshScope. Specifically, anything that depends on those beans cannot rely on them being updated when a refresh is initiated, unless it is itself in @RefreshScope (in which it will be rebuilt on a refresh and its dependencies re-injected, at which point they will be re-initialized from the refreshed @Configuration).
1
Ok, chyba zbyt krótko i niedokładnie się wyraziłem.
Czy warto mieć konfigurację poza kodem.
Tak warto, bo można np. bez problemu wstrzykiwać różną konfigurację do dokładnie tego samego artefaktu i możesz odpalać go np. z różnymi connection stringami do bazy danych.
Jeżeli masz wiele instancji tego samego serwisu (np. pody) tez warto, bo masz w jednym miejscu całość tej konfiguracji
Czy warto podmieniać konfigurację "chodzącego" serwisu w locie
Zależy jaki masz powód do tego i co chcesz podmieniać. Oczywiste jest, że nic się "samo" nie podmieni i jeżeli masz jakiegoś singletona, którę tę konfigurację dostaje na starcie i przypisuje do jakichś zmiennych, to zawartość tych zmiennych się nie zmieni sama z siebie. Czyli albo zakładasz, że jakiś bean w scope request - ok, jeden się wykręci, zacznie się kręcić następny, z nowym konfigiem.
Oryginalny post twierdzi, że brak restartu aplikacji jest zaletą, zakładam, że z powodu przerwy w dostępie do aplikacji. Można uniknąć tej przerwy na różne sposoby łatwiejsze w implementacji. Może to być rolling update, albo red/green deployment.
Co do rollbacku, przecież można tę serwowaną konfigurację trzymać w normalnym Git i zarządzać nią z tego poziomu z pełną procesową pompą, łącznie z PR.