Jaki jest preferowany sposób przechowywania konfiguracji aplikacji?

W większości przypadków przechowuję konfigurację aplikacji programistycznych w katalogu głównym projektu, w następujący sposób:

app
|-- config.json

Ale to nie wydaje się być najlepszym podejściem, ponieważ ta konfiguracja ostatecznie jest przechowywana w systemie kontroli wersji - prawdopodobnie skutkując wyciekiem nazw użytkowników, haseł i innych wrażliwych rzeczy.

12 Przewodnik po aplikacji Factor zaleca całkowite usunięcie plików konfiguracyjnych i użycie zmiennych środowiskowych do konfiguracji konfiguracji:

... przechowuje konfigurację w zmiennych środowiskowych. Zmian środowiska Env można łatwo zmieniać między wdrożeniami bez zmiany kodu; w przeciwieństwie do plików konfiguracyjnych, istnieje niewielkie prawdopodobieństwo przypadkowego sprawdzenia ich w repozytorium kodu; i w przeciwieństwie do niestandardowych plików konfiguracyjnych lub innych mechanizmów konfiguracyjnych, takich jak Java System Properties, są one standardem zależnym od języka i systemu operacyjnego.

To brzmi dla mnie naprawdę miło, ale gdzie przechowuje się wspomniane zmienne środowiskowe, bez sprawdzania ich w kontroli źródła? A jakich narzędzi mogę użyć do przekazania tych zmiennych do aplikacji? Może istnieć kilkadziesiąt opcji konfiguracji, a ręczne wpisywanie ich przy każdym uruchomieniu aplikacji nie jest przyjemne - więc muszą być gdzieś przechowywane w jakimś pliku. Wspomniany plik w ten sposób przejdzie w kontrolę źródła i wrócimy do miejsca, w którym zaczęliśmy.

Czy istnieje jakiś powszechnie akceptowany sposób obsługi opcji konfiguracji, który nie wiąże się z ryzykiem przechowywania konfiguracji lokalnej w kontroli źródła?

Być może nie ma na to dobrej odpowiedzi. Wydaje się, że musisz przechowywać te dane w bezpiecznym miejscu, ponieważ pewnego dnia będą one potrzebne do odzyskiwania danych po awarii. Dotyczy to również plików właściwości i skryptów, które ustawiają zmienne środowiskowe.

• Z kodem źródłowym (w SVN / GIT itp.) Jest naprawdę zły pomysł, ponieważ dane te będą zawierać hasła do produkcyjnej bazy danych i tym podobne.
• Twoja korporacyjna nocna kopia zapasowa może być wystarczająca, ale jest mało prawdopodobne, aby przechowywać łatwo dostępną historię zmian.
• Dane muszą być wersjonowane osobno dla używającego oprogramowania. W naszym obecnym systemie zmiana konfiguracji prowadzi do nowej wersji aplikacji i jest to po prostu zły błąd.

Obecnie szukamy rozwiązań tego problemu i skłaniamy się ku repozytorium kodu z ograniczonym dostępem. To repozytorium zawierałoby tylko dane dotyczące współbieżności. Czy inni mają podzielone doświadczenia?

Przy badaniu problemów i możliwych rozwiązań pomaga mi metoda spopularyzowana przez Jeffa Atwooda : Gdyby Bóg stworzył sposób przechowywania poufnych informacji konfiguracyjnych, jak by to zrobił?

Cóż, wiedziałby, kto potrzebuje informacji o konfiguracji i przekazuje je tylko tym osobom, a informacje te nigdy nie będą dostępne dla nikogo innego.

Pierwszą część należy już załatwić: Twój system kontroli źródła powinien uwierzytelniać użytkowników. Podejście to zyskuje również ważność zgodnie z 10 w 10 przykazaniach Troy Hunta dotyczących kontroli źródła: „zależności muszą być pod kontrolą źródła”.

Ale jak zabezpieczyć go przed wyciekiem? Cóż, nie trzeba go tam przechowywać w postaci zwykłego tekstu! Użyj szyfrowania. W .NET można wykonać kroki, aby zaszyfrować dane ciągu połączenia w plikach konfiguracyjnych . Musisz znaleźć równoważne metody, aby to zrobić z wybraną przez siebie technologią.

Wiele osób krytykuje przechowywanie konfiguracji w zwykłych plikach wraz z kodem źródłowym, ale z mojego doświadczenia wynika, że ​​jest to całkiem dobre rozwiązanie:

• Prosty do wdrożenia w dowolnym języku. W wielu otrzymujesz wsparcie dla złożonych plików konfiguracyjnych od razu po wyjęciu z pudełka. Np. W przypadku Java z Spring Boot, otrzymujesz wsparcie YAML, które może wyrażać dowolną strukturę drzewa, i łatwo jest mieć osobne pliki konfiguracyjne dla różnych środowisk, a także konfigurację bazową, z której mogą dziedziczyć pliki specyficzne dla środowiska.
• Konfiguracja jest wymagana do uruchomienia oprogramowania, a zmiany w kodzie często wymagają dodania / modyfikacji ustawień konfiguracji, więc naturalne jest zachowanie razem konfiguracji i kodu.
• Przechowywanie konfiguracji ze źródłem zapewnia wszystkie korzyści związane z kontrolą źródła, takie jak wiedza o tym, kto zmodyfikował to ustawienie i kiedy lub możliwość sprawdzenia konfiguracji podczas regularnego przeglądania kodu.
• Jeśli nie pracujesz dla CIA, argument bezpieczeństwa wydaje mi się przesadzony. Dlatego hasło do bazy danych jest przechowywane w pliku na komputerze, na którym działa Twoja aplikacja. Cóż, jeśli ktoś uzyska dostęp do komputera z twoją aplikacją, prawdopodobnie masz już poważne kłopoty - może np. Zdjąć aplikację i uruchomić własną aplikację na swoim miejscu na tym samym porcie. W takim scenariuszu dostęp do hasła DB może nie być tak dużym problemem. O ile wszystkie twoje połączenia nie są w pełni zaszyfrowane, mając dostęp do twojego komputera, i tak mogą wąchać wiele interesujących danych z interfejsów sieciowych.
• Możesz użyć narzędzia takiego jak Hiera, aby mieć tekstowy plik konfiguracyjny, ale nie przechowywać w nim haseł ani innych poufnych danych.

Tak więc w wielu przypadkach konfiguracja tekstowa przechowywana w kontroli źródła wraz z kodem jest dobrym początkiem.

Jeśli jesteś w systemach rozproszonych lub chcesz mieć możliwość zamiany konfiguracji bez konieczności ponownego wdrażania aplikacji, możesz lepiej znaleźć rozwiązanie oparte na serwerze konfiguracji. Spring Cloud obsługuje takie mechanizmy , a konfiguracjami służącymi do obsługi zaplecza może być repozytorium git lub Eureka . Możesz także rzucić własny za pomocą np . Zookeeper . Każde z tych podejść ułatwi zarządzanie spójnymi konfiguracjami na wielu serwerach w celu aktualizacji konfiguracji bez konieczności przebudowywania i ponownego wdrażania oprogramowania. Kosztem tego jest oczywiście nauka serwera konfiguracji i sposobu korzystania z niego z aplikacji, a także innego systemu do wdrażania i obsługi.

Walczymy z tym samym problemem, w którym pracuję. Obecnie wszystkie nasze konfiguracje są oparte na plikach i kontrolowane przez źródło za pomocą poszczególnych aplikacji, które ich używają. Prowadzi to do powielania, a programiści mają dostęp do haseł produkcyjnych / qa zamiast do samego programowania.

To powiedziawszy, myślę, że opracowaliśmy dobre rozwiązanie na przyszłość. Przenosimy nasze pliki konfiguracyjne do osobnego repozytorium git (oznaczonego jako repozytorium konfiguracji). Następnie konfigurujemy serwer spring-cloud-config (java), który po prostu obsługuje pliki z repozytorium konfiguracji na podstawie przekazanych mu profili. Jest to idealne rozwiązanie dla aplikacji Java, które mogą korzystać z klienta i pobierać je podczas uruchamiania. W przypadku naszych aplikacji PHP / innych niż Java usuniemy plik bezpośrednio. (Nieidealny). W przyszłości możemy napisać coś, co pozwoli aplikacji PHP na samodzielne pobieranie konfiguracji i buforowanie ich gdzieś, ale nie jest to wysoki priorytet dla pierwszego uruchomienia. Myślę o tym rozwiązaniu jako o usłudze konfiguracji jako usługi, która nie narusza jednoznacznie rekomendacji 12-czynnikowych aplikacji.

Wierzę, że zookeeper może być używany do tego samego (widziałem konfigurację z kubernetes + zookeeper), więc nie jestem pewien, dlaczego ta odpowiedź uzyskała -1 powyżej.

Spinki do mankietów:

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

Zamiast przechowywać całą konfigurację w jednym pliku, przechowuj ją w kilku plikach.

• Posiadaj katalog konfiguracji . Wszystkie pliki są interpretowane jako pliki konfiguracyjne, z wyjątkiem może README*.
• Wszystkie nazwy plików są sortowane alfabetycznie, a pliki są ładowane w tej kolejności. Dlatego pliki w takich przypadkach często zaczynają się od cyfry lub dwóch: 01-logging.json. 02-database.jsonitd.
• Dane ze wszystkich plików są ładowane do tej samej struktury konfiguracji dostępnej dla aplikacji. W ten sposób kilka plików może uzupełniać ustawienia innych, a nawet zastępować je w przewidywalny sposób.
• Przechowuj tylko w VCS pliki konfiguracyjne z wartościami bezpiecznymi lub wartościami domyślnymi. Dodaj pliki konfiguracyjne z kluczami tajnymi podczas wdrażania lub, jeszcze lepiej, skorzystaj z usługi przechowywania uwierzytelnionych sekretów.

Na najbliższym Linux-ie spójrz na /etc/sudoers.dlub /etc/nginx/conf.d. Pokazuje ten sam wzór.

Zarządzanie sekretami to inna bestia. Możesz nimi zarządzać jako krok ręczny, gdy jesteś mały. Możesz używać rzeczy takich jak Zookeeper. Możesz nawet sprawdzić sekrety w VCS w postaci zaszyfrowanej i odszyfrować je jako krok wdrożenia. Istnieje wiele innych opcji.

(Również opinia: JSON nie jest dobrym formatem pliku konfiguracyjnego, ponieważ nie pozwala na komentarze; komentarze są kluczowe. Formaty TOML, YAML, a nawet INI są lepsze w praktyce.)

Myślę, że twoje opcje są nieco określone przez system operacyjny, w którym wdrażasz

Sugerowałbym, tak, podaj wartości w kontroli źródła. ALE tylko wersje „dev”. Chcesz, aby Twój kod źródłowy się skompilował I działał! nie zawierają dodatkowych tajnych kroków

Proces kompilacji i wdrażania powinien następnie zamienić te wartości na środowisko podczas wdrażania. (ośmiornica ma tego rodzaju model)

Zookeeper Apache oferuje wspaniałe opcje przechowywania konfiguracji aplikacji dla systemów rozproszonych. Zmiany dokonane w zookeeper mogą być przechwytywane i przetwarzane przez posiadanie kuratora lub nasłuchującego zookeeper na końcu aplikacji.