I have been struggling in the world of Virtualization for the past few weeks, and I am not sure that I have any bold solutions at this point. It is painfully obvious that although you lose the burden of physical hardware for your Virtualized environment, you still have the terrible tasks of managing each of the VMs you create as a server. Enlightening, I know this must be. However, with all the hype of virtualization, it is fairly easy to purchase a robust server platform and suddenly find yourself managing 20 VMs without a clear picture of overall direction for your enterprise.
In the old days, you knew you were ready to burst because you ran out of power strips to plug the 21st box into the wall, and your network hub was blinking collisions on every call out to the network.
So, this week I downloaded the VMWare ESX server platform and its management tools. I look to the next few weeks to become accustomed to it, and then hopefully, the burden of managing the virtual environment goes away.
However, I am still not convinced that this is the best solution for out continuous integration strategies. This environment will grow by three to four virtual machines with each project that you add. That is about 1 box for every two teams, which is doable, but still scary. I am not sure I have any answers, but I sure have a headache.
What would you do?
Subscribe to:
Post Comments (Atom)
1 comment:
Hey Tom, We haven't met yet but I'm a fairly new member of the CI team at Gestalt/Accenture with Tim Fox and company. I'm not sure this is completely relevant but as you probably know we're using VMware ESX for our CI infrastructure and already have allot of the management issues you're anticipating.
One of the things that I think has compounded this problem for us is that every Virtual Machine is different in some way. That is mostly due to the fact that we've followed a model of dedicating a VM to each team we're setting up continuous builds for and have let those machines "drift" over time with regard to the software installed on them.
One of the things we're trying to do going forward is implement more of a build "farm" idea for at least the jobs that are strictly compile & unit test oriented. We're tossing around the idea of keeping a single versioned "tools disk" that gets mounted on each of the VMs so that they're all the same. We'll then hopefully use the functionality built into our continuous build tool of choice (Hudson) that allows you to associate multiple slave machines to a single master that 'farms' the builds off to the next available server. This also decouples the need to build/copy a new virtual machine every time a new team/project stands up and instead only add new virtual machines when capacity issues arise. In this environment adding a new team is simply a matter of adding a new job to the Master Hudson server and letting Hudson take care of the rest.
Of course with some tools (Hudson included I think) you'd have to have a farm for each "stack" of development tools. I don't think Hudson is smart enough yet to differentiate between things like java versions and only farm the builds to machines that have the correct compiler.
Post a Comment