Showing posts from 2013

Presentation: Vagrant as part of a production workflow

The following presentation was given on 24 July 2012 to the DevOps Brisbane group . Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.

eZ Publish 5 Virtual Machine

One of the most common issues of newcomers to eZ Publish is the setup of a system suitable for running it. Without a correctly configured system in place they usually do not get beyond the installation process and abandon their evaluation before having experienced the product.  The eZ Publish puppet module is an attempt to codify the requirements  for running eZ Publish and provide a means for automatically creating a system suitable for running it - no more following a checklist of "setting up eZ Publish on XYZ". The eZ Publish 5 Virtual Machine can be found on github at .   It combines Vagrant, VirtualBox & Puppet to generate a VM with the current eZ Publish community version (2013.4) installed and ready to be configured. The  provides details of the requirements and how to use it. Vagrant is a system that  orchestrates the automatic creation and configuration of systems. It has been used to d

New eZ Publish Puppet Module

In my last blog post I wrote about an eZ Publish Puppet module that I'd created that could be used to setup and install eZ Publish. Its been awhile since I'd done any work on it (and blogged for that matter!) and in that time both Puppet and Vagrant have matured considerably. I've also had more experience creating Puppet modules and managing systems with Puppet. I've decided to re-write the eZ Publish module from scratch utilising Puppets own modules for apache and mysql. The result is available on GitHub and in the Puppet Module Forge . The overall functionality in the new module is essentially the same as the old one, but elements have been decoupled.  This allows for the various components that make up an eZ Publish "stack" to be combined to match the desired architecture. e.g. a standalone system with the database and application on the one system to a clustered systems where different components are on separate systems. In the coming weeks I