Выпуск Building Production - учетные данные подключения к БД - PullRequest
Новая
       40

Выпуск Building Production - учетные данные подключения к БД

1 голос
/ 31 января 2011

У нас есть сборка, которая может упаковать файлы war для определенных сред, где все наши файлы свойств встроены в архив (файл war).

Сейчас мы собираемся создать для производства.Меня беспокоит то, что кодовая база должна будет предоставить пароль рабочей базы данных, и, хотя маловероятно, что существует риск, что профиль производственной сборки может быть запущен с отрицательным эффектом.хранить производственные данные в SVN и:

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

  2. Контейнер управляет подключением к БД вместо c3p0, таким образом, они могут сами управлять этой конфигурацией.

У вас есть какой-нибудь совет?

Ответы [ 3 ]

2 голосов
/ 31 января 2011

Вы определенно должны не вводить имя пользователя и пароль рабочей БД в свою систему контроля версий.Ваше приложение должно получать соединение с БД (например, DataSource), используя JNDI, который контролируется / ограничивается администраторами в производственной среде.

Например, если ваше приложение развернуто в Tomcat, у вас естьследующий в tomcat / conf / context.xml 

 <Resource name="jdbc/myDB"
              auth="Container"
              type="javax.sql.DataSource"
              maxActive="20"
              maxIdle="10"
              maxWait="3000"
              username="myusername"
              password="mypassword"
              driverClassName="com.mysql.jdbc.Driver"
              url="jdbc:mysql://myhost:3306/myschema"
              defaultAutoCommit="false"/>

.. и соединение получено из java:/comp/env/jdbc/myDB без того, чтобы ваше приложение никогда не предоставляло имя пользователя или пароль.Установка tomcat защищена на серверах prod администраторами, поэтому она недоступна всем, у кого нет прав администратора на вашем сервере prod.

0 голосов
/ 31 января 2011

Я пробовал как иметь свойства в архиве, так и вне архива, и иметь их вне архива намного проще для решения такого рода проблем.

Некоторые вещи, на которые следует обратить внимание:

  1. Насколько это возможно, для свойств могут быть установлены значения по умолчанию, так что если свойство не будет найдено, оно будет использовать значение по умолчанию (например, с использованием "localhost" в качестве URL-адреса подключения к базе данных по умолчанию).
  2. Вы по-прежнему можете хранить файлы свойств для непроизводственных сред в системе контроля версий вместе с кодом.

Используя эти две политики, разработчики могут нести ответственность за управление файлами непроизводственных свойств, которые такжепоэтому служить примером для администратора производства.Он также сохраняет большинство свойств централизованными в управлении исходным кодом, предоставляя некоторые преимущества сохранения централизации, при этом все же отсоединяя свойства достаточно.

РЕДАКТИРОВАТЬ: обратите внимание, что JNDI является опцией, но архитектурно это то же самоечто касается хранения файлов свойств снаружи - вам все равно нужно позаботиться о версии, чтобы они не были свободными в разных средах.

0 голосов
/ 31 января 2011

В производстве я предпочитаю подход, который вообще не хранит учетные данные в файлах свойств.Вместо этого я предпочитаю, чтобы сервер приложений предоставлял учетные данные, используя jndi.

Если вы используете Apache Tomcat, посмотрите, например, jndi reference .

...