2

At work we're in the process of moving our production apps to a VM infrastructure, and so far so good.

One of the ideas we're throwing around is related to our software deployment process. The idea is that when we deploy an app, instead of deploying to an existing VM, we would create a new VM, deploy the app to it, test it, and then once it's looking good add it to the load balancer.

One major advantage we're expecting is that this would help control the drift that occurs between our test and prod environment configurations. If we are blowing VMs away with each deployment then even if somebody makes a change an individual server, it won't last long. (Ultimately we're driving toward centralized configuration management though we think the VM approach still helps.)

Does anybody have experience or even thoughts on this? One challenge one of my coworkers raised was that we might need to move to a one-app-per-VM configuration so that we're not forced to bring down multiple apps on the same VM when deploying one of the apps. Another potential issue is having multiple VMs with the same hostname while we're doing the deployment.

Would be interested in hearing your experience and thoughts. This is pretty new territory for my organization.

  • http://serverfault.com/questions/64843/vmware-clone-vs-templating-a-gold-master-server/ – warren Oct 23 '09 at 06:02
  • Thanks Warren for that link--it is interesting though I think it's treating something different than what I'm asking about. I'm less worried here about the best approach to creating VMs and more about whether creating new VMs is a reasonable thing to be doing as part of a software deployment. (I.e. always create a new VM and then deploy the app to it, for the reasons described in the post.) Currently we deploy to existing VMs. –  Oct 23 '09 at 06:17

1 Answers1

0

I think deploying to a fresh VM each time is a great idea. Having multiple apps per VM shouldn't be a problem as long has you have a process in place to test each one before you switch over to production. You should be able to create a custom startup script that gives each VM a unique host name to avoid conflicts with the production VMs.

A couple of things (I'm sure there are more) that you'll need to consider:

  • how you'll maintain your master VM configuration that you clone the others from, and stop people from making inadvertent changes that could make their way into production
  • how you'll automate the switch of a VM from test to production, and optionally take the old VM that it replaces out of the production load balancer.
gareth_bowles
  • 9,127
  • 9
  • 34
  • 42
  • Yeah, those are some things we are definitely thinking about. On the master VM config, we're actually thinking of defining a small number of standards (e.g., maybe one for Java web apps, another for IIS, etc.) and just loading them up with whatever standard stuff they would need given that role. You gave me an idea on the multiple apps per VM. Maybe when we deploy to a VM we deploy all apps to that server (whether there's a release for all or not), verify them as you say, and then deploy, treating the VM as potentially extra capacity for those apps. Drain the old sessions via the LB... –  Oct 24 '09 at 04:36