Services: DevOps Thought Leadership | JEE Consulting
In order to create a WordPress server I need 4 main components:
I hit my first problem, the WordPress package from EPEL for RHEL/CentOS 5 is quite old, it’s 2.8 while the version of WordPress with all the new hotness is 3.0.
Hmm ”old busted” or “new hotness” (not to say the 2.8 is either old or busted but you get what I mean). I decided I’d roll with the new hotness and then I hit another dilemma I couldn’t find a RPM for RHEL/CentOS 5, so should I just roll out the tar ball or create a package for it?
This is currently a hot topic in the Devops community and when I went to Devops Hamburg back in October one of the more popular open space sessions was “packaging vs. non-packaging, when and what?” and the main output was it “depends”.
However I wanted a zero touch and fully automated deployment so I investigated both methods and weighted them up:
Scenario 1 – Installation of Tar ball
OK now I have my newly packaged WordPress 3.0 rpm and life is good, everything else I need is already packaged and can be easily installed using yum, a few minutes later I have a fully functioning WordPress server.
Now for the fun part, how do a fully automate the creation of a WordPress server end to end.
Firstly I created a custom kickstart profile on my cobbler server to install a minimal Just Enough Operating System (JeOS) base build (faster to install and patch with the minimum security attack surface) with some additional post install stuff to bootstrap puppet.
Next I had to install and configure a simple apache server I didn’t have to do anything clever with virtual hosts so I wrote a nice simple puppet module.
For the MySQL installation and configuration I wanted something a little more robust since I believed I could make a lot of use out of a good MySQL puppet module. I found it quite ironic that I stumbled across a problem that I had previously answered on server fault that being how do you find a top notch MySQL module:
There were quite a few out there and after a fair bit of back and forth I settled on the Camp to Camp boys’ MySQL puppet module, it is very functional and quite compact in the amount of supporting modules that are needed to make it function:
You’ll need to have the plugin sync enabled in your puppet.conf for this to work because it copies some custom facts and plugins to the client in order to create the databases.
Onto the final stretch I need to install WordPress so I whipped up the following puppet module to install WordPress.
I used the following entry in my nodes.pp file to pull it all together
Ok so I now have a fully functional WordPress Server in about 5 minutes. This is just a basic setup but it demonstrates what can be done without too much effort and if I wanted to take this further in the future, I would create an erb template for the wp-config.php so that the database settings are populated by puppet using the existing username, password and database name variables.
Martin Jackson is a Freelance Linux and Virtualization Consultant, Devops advocate, Infrastructure as Code Hacker and a keen Judoka. You can follow him as @actionjack on twitter.
Steve Robinson has been working in IT for over 20 years and has
provided solutions for many leading brands around
the world. Steve specialises in JEE, DevOps and Thought Leadership.
In January 2013, I was awarded the prestigous
'IBM Champion' accolade.
IBM WebSphere Application Server 8.0 Administration Guide
WebSphere Application Server 7.0 Administration Guide
Contact | Articles | Shell Scripts | Java Code | JACL | Jython | WebSphere MQ | WebSphere Message Broker | WebSphere Blog | © Copyright 2006-2013 Robinson (UK) Limited