Развертывание приложений Java без включения производственных учетных данных в VC - PullRequest
2 голосов
/ 14 декабря 2011

Я использую Maven и Jenkins для управления развертыванием моего веб-приложения. По существу:

  • Когда запускается развертывание, окно CI выводит код из-под контроля версий.
  • Если код проходит тесты, он запускает плагин релиза Maven для создания версионной войны и помещает его в наше локальное хранилище nexus
  • В той же сборке извлекает артефакт из нексуса и копирует артефакт в кота, вызывая Tocmat, чтобы снова взорвать войну.

Это прекрасно работает, и с помощью этой техники я могу использовать maven для замены соответствующих конфигураций, специфичных для среды, если они находятся в проекте. Тем не менее, мой SysAdmin считает угрозой безопасности наличие учетных данных в VC. Вместо этого мы предпочли бы хранить производственные учетные данные на производственных машинах, которые будут их использовать. Я могу себе представить написание простого bash-скрипта для ssh в сервисной коробке и мягкую ссылку на файл conf на путь к классам, но это выглядит довольно нелегким решением.

Это разумно? Есть ли лучший / более стандартный способ добиться этого? Является ли на самом деле угрозой безопасности хранение учетных данных в VC?

Ответы [ 2 ]

0 голосов
/ 15 декабря 2011

Да, это риск для безопасности иметь учетные данные в системе контроля версий. Это позволяет вашим разработчикам делать практически все, что они хотят. Такие нормативы, как HIPAA в медицине или PCI для электронной коммерции или SoX для публичных компаний США, не одобрят этого. Ваш системный администратор также разумен.

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

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

Я думаю, что именно здесь Хадсон подводит вас с точки зрения непрерывной доставки. Некоторые из коммерческих инструментов, в том числе uBuild / AnthillPro моей компании, формально отслеживают различные среды и позволяют sys-admin безопасно настраивать производственные учетные данные, а разработчики настраивают учетные данные dev с помощью этого инструмента. Аналогичным образом, инструменты автоматизации выпуска приложений, такие как uDeploy , которые будут извлекать сборки из Hudson и развертывать их, должны иметь такую ​​конфигурацию для каждой среды.

В этих сценариях большинство файлов property / xml имеют общую конфигурацию, и механизм развертывания заменяет env. конкретные данные в процессе развертывания.

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

У вас есть несколько вариантов здесь. Подумайте, как все меняется в зависимости от окружающей среды; что зависит от сервера; что нужно защитить, что меняется со временем на стороне разработчика и т. д. И, пожалуйста, пожалуйста, сядьте со своим системным администратором и вместе разработайте решение. У каждого из вас есть понимание, которого нет у другого, и конечное решение будет лучше для сотрудничества.

0 голосов
/ 14 декабря 2011

У вас есть файл conf на вашем производственном сервере в каком-то месте.Это место также может быть собственностью.

Если нет особой причины не загружать его как файл с диска, а не загружать как ресурс из classpath, вы можете создать отдельный профиль Maven production, который будет filter место, заменяющее его на путь к файлу для вашего производственного сервера.

...