2015-02-25 1 views
9

Я хочу иметь несколько файлов yaml для DropWizard. Один из них содержит конфиденциальную информацию и одну нечувствительную.Могу ли я иметь несколько файлов конфигурации в DropWizard?

Можете ли вы указать мне на какие-либо документы или пример того, как иметь несколько конфигураций в DropWizard?

ответ

5

Во-первых, вы напишете еще один путь к файлу yml в .yml.

sample.yml

configPath: /another.yml 

another.yml

greet: Hello! 

и вы будете решать, просто используя 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! 
... 
} 

Для чувствительной информации, я думаю, что полезно использовать переменную окружения.

Например, используйте dropwizard-среду-конфигурации
https://github.com/tkrille/dropwizard-environment-config

+0

Это будет работать только для пользовательских конфигураций. Но если они хотят сказать «конфигурацию сервера», которая повлияет на сам dropwizard, это не сработает. Например, может потребоваться обфускация пароля секретного ключа сертификата https. – Natan

5

ConfigurationSourceProvider ваш ответ.

bootstrap.setConfigurationSourceProvider(new MyMultipleConfigurationSourceProvider()); 

: dropwizard does it by default. Вы можете легко изменить его по своему вкусу.

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

Что будет выглядеть «MyMultipleConfigurationSourceProvider»? У меня нет четкого представления о том, как он может предоставлять данные из нескольких файлов. Не могли бы вы объяснить? –

+0

Я предполагаю, что это будет чтение двух файлов (либо жесткокодированных, либо '' 'отделенных файлов, поступающих из параметра' path'), объединяя их в 'InputStream' и возвращая их. – Natan

+0

Спасибо за быстрый ответ! Если я правильно пойму, это будет иметь серьезные последствия, не так ли? Например, поля, которые находились в корне каждого файла, попадают в корень «основного реконструированного» файла, потенциально с коллизиями. –

4

В идеале вы должны быть настройки вашего приложения, поставив вашу конфиденциальную информацию или конфигурируемые данные внутри Переменные среды, а не управление несколькими файлами. См двенадцать правила фактора на конфигурации: http://12factor.net/config

Чтобы включить этот подход в Dropwizard, вы можете переопределить конфигурации с помощью переменной среды во время выполнения с помощью -Ddw флага:

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

или вы можете использовать эту удобную надстройку на: https://github.com/tkrille/dropwizard-template-config поставить переменной окружения заполнителей внутри вашей конфигурации:

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

Оба вышеуказанных решений совместимы с Heroku и Докер контейнеров, где окружающая среда Переменная доступна только при запуске приложения.

+1

Не нравится. Где вы поддерживаете свои env vars? Я имею в виду, какой скрипт их устанавливает? Возможно, у вас будет скрипт bash, который запускает приложение, и сначала устанавливает все env vars. Теперь вам нужно несколько сценариев, по одному для каждой среды (dev, qa, stage, prod и т. Д.), Где каждый скрипт имеет другой набор env vars. Эти сценарии должны контролироваться ревизией. Но теперь эти скрипты - это только файлы конфигурации. В этот момент, почему бы просто не иметь файл с только переменными (файл свойств, или yaml, или json, что угодно), и прочитать их и пропустить шаг env var? –

+0

Да, env vars необходимо установить, но не для каждого развертывания, так же, как вам не нужно разворачивать всю среду с каждым развертыванием. Вы можете использовать скрипты или есть инструменты настройки – yunspace

+0

... такие как Pupplet, Chef, Ansible и т. Д. В конечном счете идея состоит в том, что вы отделяете свои проблемы от разработчиков от Ops, чтобы учетные данные не были проверены в исходном коде, безопасность может быть независимо проверяется и что изменения окружающей среды могут выполняться на уровне инфраструктуры, а не копаться в каждом файле конфигурации исходного кода. Совместное использование переменных файлов также может работать, но как это лучше? Это означает, что ваш код конфигурации нужен для чтения в переменных в каждой службе, где, поскольку DW config поддерживает Env Var из коробки. Также Env Vars работает с непрерывной доставкой неизменяемых контейнеров, таких как Docker/Heroku. – yunspace

 Смежные вопросы

  • Нет связанных вопросов^_^