Deployment Architechture – Multihosts

Print Friendly, PDF & Email

Dom, Kieren, Ed and myself met on Friday to discuss the problem raised last week regarding the successes and shortfalls of the multi-host deployment paradigm used for Plone3/Zope 2.10. The current layout of a server environment at each stage of the development life-cycle was designed to allow all involved parties; developer, trainer, client and users, to work in tandem without risk of disruption to service. Some felt that the “prep” server was superfluous to needs and that some developers were not using the staged deployment procedure because of lack of tools to engage with the automated deployment systems; Bcfg2, Build-out, compiler boxes and other “glue”. Much work is anticipated in all areas to tack these systems together and it was agreed that developers and sysadmins need to work together to bridge the gaps.

At the end of the meeting we had agreed that the “prep” environment should be dropped in future incarnations, replaced by a better suited development environment. It was suggested that in the future developers would be given a method to create mirror copies of application infrastructure as a group of private virtual machines in a virtual network.  This is envisaged to work something along the lines of Amazon EC2 perhaps using Eucalyptus.

It was also discussed that there are a number of personalities of the demo box and it’s necessary to split this further. It was suggested and agreed upon that the software environment does not need to be split further into more virtual machines as this adds unnecessary complexity and confusion. Therefore, we imagine a basic set of; demo – for client previewing, prepop – for pre-population of content data site release and train – static copy for training purposes. Due to the fact that these would need to be public, some or all may have up to 2 separate SSL certificates and that there is a limit on our IPv4 space; it was suggested that we may have to make this environment fixed to a temporary period for the duration of the development and initial production support phases. It would need to be built using tools which allowed for the environment to be created quickly when needed and torn down at an agreed date so that the resources could be reused.

Due to the restrictions on development time on this we agreed to pretty much carry on as we are for now. However, new projects in other application environments may see an extra “demo” box.

The picture below is a rough outline of the intended deployment architecture.