CODEWITHSUNDEEP
java.netenterpriseproduction-environment
user996142
user996142

Reputation: 2883

Environment configuration management?

There is a team develops enterprise application with web interface: java, tomcat, struts, mysql, REST and LDAP calls to external services and so on.

All configuration is stored in context.xml --tomcat specific file that contains variables available via servlet context and object available via JNDI resources.

Developers have no access to production and QA platforms (as it should be) so context.xml is managed by support/sysadmin team.

Each release has config-notes.txt with instructions like:

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"

That is not good.

Here is my idea how to solve it.

Each release has special config file with required variable names, descriptions and default values (if any): even web.xml could be used.

Here is pseudo example:

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

And there is a special tool that support team runs against deployment artifact. Look at it (text after ">" is typed by support guy): 

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.

That will give us ability to deploy application on any environment and update configuration if needed.

Do you like my idea? What do you use for environment configuration management? Does there is ready-to-use tools for that?

Upvotes: 2

Views: 1211

Answers (2)

joevartuli
joevartuli

Reputation: 131

There are plenty of different strategies. All of them are good and depends on what suit you best.

  1. Build a single artifact and deploy configs to a separate location. The artifact could have placeholder variables and, on deployment, the config could be read in. Have a look at Springs property placeholder. It works fantastically for webapps that use Spring and doesn't involve getting ops involved.
  2. Have an externalised property config that lives outside of the webapp. Keep the location constant and always read from the property config. Update the config at any stage and a restart will be up the new values.
  3. If you are modifying the environment (i.e. application server being used or user/group permissions) look at using the above methods with puppet or chef. Also have a look at managing your config files with these tools.

As for the whole should devs be given access to prod, it really depends on a per company basis. For smaller companies where the dev is called every time there is a problem, regardless of whether that problem is server or application related, then obviously devs require access to the box.

DevOps is not about giving devs access to the box, its about giving devs the ability to use infrastructure as a service, the ability to spawn new instances with application X with config Y and to push their applications into environments without ops. In a large company like ours, what it allows is the ability for devs to manage the application they put on a server. Operations shouldn't care what version is on their, thats our job, their job is all about keeping the server up and running.

Upvotes: 2

moodywoody
moodywoody

Reputation: 2159

I strongly disagree with your remark that devs shouldn't have access to prod or staging environments. It's this kind of attitude that leads to teams working against each other instead of with eath other.

But to answer your question: you are thinking about what is typically called continuous integration ( http://en.wikipedia.org/wiki/Continuous_integration ) and moving towards devops. Ideally you should aim for the magic "1 click automated deployment". The guys from Flickr wrote a lot of blogs (and books) about how they achieved that. Anyhow .. there's a lot of tools around that sector. You may want to have a look a things like Hudson/Jenkins or Puppet/Chef.

Upvotes: 1

Related Questions