2015-02-25 15 views

Odpowiedz

5

Po pierwsze, zapiszesz inną ścieżkę pliku yml w .yml.

sample.yml

configPath: /another.yml 

another.yml

greet: Hello! 

i zostanie rozwiązany po prostu za pomocą SnakeYaml.

public void run(SampleConfiguration configuration, Environment environment) { 
    Yaml yaml = new Yaml(); 
    InputStream in = getClass().getResourceAsStream(configuration.getConfigPath()); 
    AnotherConfig anotherConfig = yaml.loadAs(in, AnotherConfig.class); 
    String str = anotherConfig.getGreet(); // Hello! 
... 
} 

Dla wrażliwych informacji uważam, że dobrze jest używać zmiennej środowiskowej.

na przykład użyć dropwizard-środowisko-config
https://github.com/tkrille/dropwizard-environment-config

+0

To będzie działać tylko w niestandardowych konfiguracjach. Ale jeśli chcą, powiedzmy, konfigurację serwera, która wpłynie na samą akcję DropWizard, to nie zadziała. Na przykład można ukryć hasło do klucza prywatnego certyfikatu https. – Natan

5

ConfigurationSourceProvider jest odpowiedź.

bootstrap.setConfigurationSourceProvider(new MyMultipleConfigurationSourceProvider()); 

Poniżej podano sposób, w jaki dropwizard does it by default. Możesz łatwo zmienić to na własne upodobania.

public class FileConfigurationSourceProvider implements ConfigurationSourceProvider { 
    @Override 
    public InputStream open(String path) throws IOException { 
     final File file = new File(path); 
     if (!file.exists()) { 
      throw new FileNotFoundException("File " + file + " not found"); 
     } 

     return new FileInputStream(file); 
    } 
} 
+0

Jak powinien wyglądać "MyMultipleConfigurationSourceProvider"? Nie mam jasnego obrazu tego, w jaki sposób może dostarczać dane z kilku plików. Czy mógłbyś wyjaśnić? –

+0

Przypuszczam, że byłby to odczyt dwóch plików (zakodowanych na stałe lub '|' plików pochodzących z parametru 'ścieżka'), scalając je razem w' InputStream' i zwracając je. – Natan

+0

Dzięki za szybką odpowiedź! Jeśli dobrze zrozumiem, będzie to miało znaczące konsekwencje, prawda? Na przykład pola, które znajdowały się w katalogu głównym każdego pliku, znajdą się w katalogu głównym pliku "główny rekonstruowany", potencjalnie z kolizjami. –

4

Idealnie powinno być konfigurowania aplikacji poprzez wprowadzenie poufnych informacji lub danych konfigurowalne wewnątrz Zmienne środowiskowe, zamiast zarządzania wieloma plikami. Zobacz dwanaście czynnik regułę na config: http://12factor.net/config

Aby włączyć to podejście w Dropwizard, można zastąpić swój config zmienne środowiska w czasie wykonywania przy użyciu -Ddw flag

java -Ddw.http.port=$PORT -jar yourapp.jar server yourconfig.yml 

czy można użyć tego poręczny dodatek na: https://github.com/tkrille/dropwizard-template-config umieścić zmienną środowiskową zastępcze wewnątrz config:

server: 
    type: simple 
    connector: 
    type: http 
    # replacing environment variables 
    port: ${env.PORT} 

Oba powyższe rozwiązania są zgodne z Heroku i Döcker kontenerów, w których środowisko Zmienna jest dostępna tylko po uruchomieniu aplikacji.

+1

Nie podoba mi się. Gdzie utrzymujesz swoje env vars? Mam na myśli, jaki scenariusz je ustawia? Może będziesz miał skrypt bash, który uruchamia aplikację, i najpierw ustawia wszystkie vv env. Teraz potrzebujesz wielu skryptów, po jednym dla każdego środowiska (dev, qa, stage, prod, itp.), Gdzie każdy skrypt ma inny zestaw zmiennych env. Te skrypty wymagają kontroli wersji. Ale teraz te skrypty są po prostu plikami konfiguracyjnymi. W tym momencie, dlaczego nie wystarczy plik z tylko zmiennymi (plik właściwości, lub yaml, lub json, cokolwiek) i przeczytać te i pomiń krok env var? –

+0

Tak, należy ustawić zmienne env, ale nie dla każdego wdrożenia, tak jak nie powinno być potrzeby rozpinania całego środowiska przy każdym wdrożeniu. Możesz używać skryptów, lub są narzędzia konfiguracyjne – yunspace

+0

... takie jak Pupplet, Chef, Ansible itp. Ostatecznie pomysł polega na tym, że oddzielasz swoje problemy od Dev od Ops, więc poświadczenia nie są sprawdzane w kodzie źródłowym, bezpieczeństwo może być niezależnie kontrolowane i że zmiany środowiska można wykonać na poziomie infrastruktury zamiast zagłębiać się w pliki konfiguracyjne każdego kodu źródłowego. Po udostępnieniu plików zmiennych może również działać, ale jak to jest lepsze? Oznacza to, że potrzebujesz kodu konfiguracyjnego do odczytywania zmiennych w każdej usłudze, gdzie jako DW config obsługuje Env Var out of box. Również Env Vars pracuje z ciągłą dostawą niezmiennych kontenerów, takich jak Docker/Heroku – yunspace

Powiązane problemy