Konfiguracja jest koniecznością. Nic w tym odkrywczego. Natomiast jak dobrze zarządzać konfiguracją, aby nie narobić sobie problemów w przyszłości. Zwłaszcza gdy myślimy o skalowaniu, elastyczności i automatyzacji. Rozbroimy dziś jeden z największych błędów, przy zarządzaniu konfiguracją, czyli podejście do bazujące na plikach w repozytorium.
Zaszyta konfiguracja
Jak najłatwiej przekazać dane konfiguracyjne do aplikacji, wdrożonej na konkretne środowisko? Użyć plików konfiguracyjnych. Proste! Może to być web.config
, appsettings.json
, env.json
, settings.xml
. Obojętnie. W różnych technologiach są różne konwencje, ale są to rozwiązania standardowe, dobre i działające. Zwłaszcza w początkowej fazie życia projektu. Jednak, z upływem czasu, należy podchodzić do nich ostrożnie. Dlaczego? Już piszę.
Na późniejszych etapach życia projektu zaczynamy wdrażać kod na różne środowiska. W związku z tym musimy przekazać im różne wartości konfiguracyjne, aby strzelały do różnych baz danych, różnych serwisów, czy żeby przedstawiały się inaczej. Często nadużywanym podejściem jest tworzenie, kopii plików konfiguracyjnych lub ich transformacji. Po tym kroku otrzymujemy stertę plików web.dev.config
, web.test.config
, env-test.json
, env-dev.json
, env-prod.json
…. i tak dalej!!!
Co jest w tym nie tak?
Bezpieczeństwo
Zmienne konfiguracyjne w repozytorium to proszenie się o kłopoty. Jeżeli ktoś zdobędzie dostęp do kodu źródłowego, będzie w stanie dobrać się danych i nadać sobie nieograniczony dostęp. Chyba, nie muszę Cię przekonywać, że nie jest to dobre?
Sztywność
Wyobraź sobie sytuację, że przychodzi do pracy nowy tester i chcesz przygotować dla niego, dedykowane, czyste środowisko, aby sobie eksperymentował? Albo klient potrzebuje nowej instancji produktu, bo z jakiegoś powodu nie chce lub nie może udostępnić aktualnego?
W takiej sytuacji musisz wejść do repozytorium, przygotować nowe pliki, aby następnie zająć się ich opublikowaniem. Mało wygodne, nieprawdaż?
Czasochłonność
Skoro paczka jest ograniczona do konkretnego, przygotowanego wcześniej, środowiska. Nie jesteśmy w stanie zainstalować konkretnej wersji na innej maszynie, bo musimy przebudować aplikację za każdym razem, gdy chcemy ją wdrożyć na nowe środowisko. Jest to absurdalne marnotrawstwo czasu, przestrzeni i potencjału.
A jak już jesteśmy przy marnowaniu czasu. Sprawdź jak go oszczędzić wprowadzając Cache Task do Azure Pipelines.
Niestabilność
Jeżeli musimy przebudować paczkę za każdym razem, to tracimy część stabilności, bo jak zagwarantować, że ta konkretna wersja jest dokładnie tym samym co ta przetestowana przez testerów. Da się, ale wymaga to większych zasobów i kombinowania.
Jak sobie z tym poradzić?
Nie twórz plików konfiguracyjnych per środowisko. Podejdź do tego z głową i buduj jedną, lecz generyczną paczkę. Natomiast konfigurację nadpisuj podczas deploymentu. Dzięki temu:
- Nie ogranicza Cię ilość środowisk, bo nowe stworzysz kilkoma kliknięciami
- Bezpieczeństwo zmiennych konfiguracyjnych jest po stronie serwera CI
- Oszczędzasz czas, bo uniwersalna paczka jest tworzona tylko raz
- Masz pewność, że aplikacja przetestowana na jednym środowisku, jest dokładnie tym samym, co na drugim
Coś więcej z innej perspektywy
Jeżeli chcesz jeszcze więcej na temat konfiguracji, to sprawdź ten film.
Chyba że…
Nigdy nie jest prosto. To zawsze zależy. Istnieje wyjątkowa sytuacja, że trzymanie zmiennych dostępowych w repo jest wskazane. Co jest taką, specjalną okazją?
Jest to konfiguracja deweloperska, czyli taka pozwalająca programiście na odpalenie aplikacji bezpośrednio po sklonowaniu repozytorium. Dzięki temu oszczędzisz ogrom czasu na wdrożeniach nowych ludzi, reprodukcji błędów i na milionie innych rzeczy.
Jak jest u Ciebie?
A, że tak zapytam bez ogródek. Jak Ty zarządzasz konfiguracją?
3 Komentarze
Jakub Barczyk · 30 września, 2020 o 12:49
Fajny artykuł! Wytyka dużo często spotykanych problemów – gdzie na pierwszy plan wysuwa się bezpieczeństwo. Osobiście preferuję tworzenie plików appsettings.{env}.json gdzie znajduje się konfiguracja bez sekretów (np. zdefiniowane retry policy, cache lifetime), oraz pliku appsettings.json gdzie znajduje się lista sekretów, które są podmieniane w procesie deploymentu.
Jerzy Wickowski · 30 września, 2020 o 13:17
Cześć @Jakub,
Zawsze należy znaleźć złoty środek i należy dobrać odpowiednie rozwiązane, zdając sobie sprawę z przyszłych konsekwencji. U Ciebie widzę, że wygląda to świadomie, więc spoko 🙂
Jak podchodzisz do problemu, gdy potrzebujesz stworzyć nowe środowisko? Używasz domyślnej konfiguracji + sekrety?
Jakub Barczyk · 30 września, 2020 o 14:17
Cześć @Jerzy,
Dokładnie tak jak mówisz. Rzadko się zdarza, że na środowisko, które powstaje na dodatkowe życzenie (czyli różne niż stałe środowiska), potrzebujemy specjalnej konfiguracji.
Pozdrawiam
Możliwość dodawania komentarzy nie jest dostępna.