Блог

Существует команда, разрабатывающая корпоративное приложение с веб-интерфейсом: java, tomcat, struts, mysql, REST и LDAP вызовы внешних служб и так далее.

Вся конфигурация хранится в context.xml —специфичный для tomcat файл, содержащий переменные, доступные через контекст сервлета, и объект, доступный через ресурсы JNDI.

Разработчики не имеют доступа к производственным платформам и платформам контроля качества (как и должно быть), поэтому context.xml управляется командой поддержки / системного администратора.

Каждый выпуск имеет config-notes.txt с такими инструкциями, как:

 please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and     credentials) named "barDb"
  

Это нехорошо.

Вот моя идея, как ее решить.

Каждая версия имеет специальный конфигурационный файл с требуемыми именами переменных, описаниями и значениями по умолчанию (если таковые имеются): даже web.xml можно было бы использовать.

Вот псевдопример:

 foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)
  

И есть специальный инструмент, который команда поддержки запускает против артефакта развертывания.
Посмотрите на это (текст после «>» вводится сотрудником службы поддержки):

 Config for version 123 of artifact "mySever".

Enter your config file location> /opt/tomcat/context/myServer.xml

 "foo" value "bar" -- already exists and would not be changed
 "userLimit" value "123" -- adding new
 "barDb"(connection to our new server) please type> jdbc:mysql:host/db

Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.
  

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

Вам нравится моя идея? Что вы используете для управления конфигурацией среды? Есть ли готовые к использованию инструменты для этого?

Существует множество различных стратегий. Все они хороши и зависят от того, что подходит вам лучше всего.

1. Создайте один артефакт и разверните конфигурации в отдельном месте. Артефакт может иметь переменные-заполнители, и при развертывании конфигурация может быть прочитана. Взгляните на заполнитель свойств Springs. Это фантастически работает для веб-приложений, использующих Spring, и не требует участия операций.
2. Имейте внешнюю конфигурацию свойств, которая находится за пределами веб-приложения. Сохраняйте местоположение постоянным и всегда считывайте из конфигурации свойств. Обновите конфигурацию на любом этапе, и при перезапуске появятся новые значения.
3. Если вы изменяете среду (например, используемый сервер приложений или разрешения пользователя / группы), рассмотрите использование вышеуказанных методов с помощью puppet или chef. Также взгляните на управление вашими конфигурационными файлами с помощью этих инструментов.

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

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

Я категорически не согласен с вашим замечанием о том, что разработчики не должны иметь доступа к prod или промежуточным средам. Именно такое отношение приводит к тому, что команды работают друг против друга, а не друг с другом.

Но чтобы ответить на ваш вопрос: вы думаете о том, что обычно называется непрерывной интеграцией ( http://en.wikipedia.org/wiki/Continuous_integration ) и движется в направлении devops. В идеале вы должны стремиться к волшебному «автоматизированному развертыванию в 1 клик». Ребята из Flickr написали много блогов (и книг) о том, как они этого добились. Во всяком случае .. в этом секторе много инструментов. Возможно, вы захотите взглянуть на такие вещи, как Hudson / Jenkins или Puppet / Chef.