- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Stackato Training
- Professional Services
- Commercial Support
- Code Recipes
Troy Topnik, June 13, 2013
We recently came across an interesting project on Github called wordpress-development-flow. David Laing, an agile software developer working with City Index has created a development flow to help developers standardize their development and production environments using Vagrant, Heroku buildpacks, and Stackato.
David uses Heroku buildpacks to create the same environment in Vagrant VMs as in Stackato application containers. The buildpack he's created shows just how flexible Stackato can be when you start customizing your application environment. It uses the HipHop for PHP JIT compiler for serving WordPress to deliver a 5x performance improvement over the the default PHP 5.3 and Apache.
I asked David a few questions about this project. Here's what he had to say:
One of the goals of the wordpress-development-flow project seems to be creating consistent environments for development and production deployment. Why did you choose Vagrant for the "Dev workstation" environment?
Vagrant gives me a scriptable way to launch local VMs, and configure them with a "provisioning" script. Most importantly, it works cross platform, and since Vagrant v1.1 the installation of the toolchain required to launch VMs has been drastically simplified. If I'm honest, Vagrant has become such a standard part of my dev toolset that I didn't really consider any other options.
Have you thought of using the Stackato VM itself for this part?
I'm actually trying to simulate the LXC runtime container with the DEV VM; spinning up an entire Stackato micro cloud seemed like overkill for this purpose.
You made your own buildpack called 'stackato-buildpack-wordpress' which uses Facebook's HipHop for PHP. How hard was that to create? Were you able to reuse any of Marc Chung's Wordpress buildpack?
Marc Chung's Wordpress buildpack got me started with a layout and components for writing a WordPress buildpack; but after several iterations I think I've rewritten nearly everything to better fit my requirements.
Creating a buildpack isn't hard, but it is slow. There are 2 reasons for this:
Manual verification - creating the buildpack using bash encourages manual verification, with "god" scripts that have to be manually run "from the beginning" everytime you want to test a change. If I were to start again I think I would write my buildpack scripts in ruby, so I can componentise them and write automated tests.
Component compilation - compiling stuff takes ages (eg, HipHop-PHP takes over an hour); so a scripting mentality of "try this compilation config, then test" takes forever.
You use this buildpack in the Vagrant VM as well. Did you have to do anything special to make the buildpack work in both the "dev workstation" VM and Stackato? Did you have to write your own mechanism to build the buildpack in that VM?
No; since the Stackato VM and my dev VM are Ubuntu 12.04 using the buildpack inside my dev VM is as simple as git cloning it, and running buildpack/bin/compile.
I started out with my dev VM "building" the files to /home/vagrant/dist rather than /app/app where the Stackato LXC container builds things. On reflection I should have just configured my dev VM to have the same folder layout & environment vars as the Stackato LXC container.
The 'rake release' part of your flow deploys to Stackato. Why did you choose Stackato for application deployment?
I'm a firm believer in a LXC container based PAAS as the "correct" way to deploy to a cloud infrastructure. The Stackato installation and documentation is excellent; so this helped me get my CloudFoundry PAAS going quickly and easily.
You're using Jenkins for continuous deployment to Stackato, how do you trigger those deployments, and what exactly do they do?
Jenkins builds are triggered by a GitHub checkin (via the Jenkins GitHub plugin).
I try to keep as much logic as possible out of Jenkins, preferring to encapsulate it in my projects build-script. For example, the commands to deploy to Stackato are wrapped in my Rakefile's release task, and all Jenkins does is call rake release. This makes local testing of the Jenkins CI process significantly easier.
For each project I actually have 3 separate Jenkins Jobs.
Master branch builder - this builds every commit to the master branch, tagging those that are successful with a version number and archiving the artifacts. Its basically executing "rake build"
Master branch deployer - this deploys successful builds to my pre-production/test server (by calling rake release). You can also run this job manually to deploy a specific build to the production Stackato app.
Pull Request builder - this builds every pull request commit, notifying GitHub of build success, and deploying each pull request to a separate test Stackato app (eg, "pr101-wdf.apps.stackato.me") - ie, running both "rake build" and "rake release" on each PR branch. This makes it really easy for people watching the pull request to access a demo of the new functionality (since each PR has its own installation and distinct URL), and thus make meaningful comments.
I see you've also created a Mono buildpack. What does it do for you that the "vanilla" Stackato Mono add-on doesn't?
Flexibility - I need to use the latest version of Mono; in a way that allows me to create background workers (i.e. not ASP.NET apps).
It also gives me a way to run my stack outside of Stackato (e.g. in my dev VM).
If you could add or change one thing in Stackato, what would it be?
My wish lists always come in a pack of three:
Enabling buildpacks to be pulled from a feature branch rather than just the default branch. For example, in stackato.yml I want to specify:
env: BUILDPACK_URL: git://github.com/mrdavidlaing/stackato-buildpack-wordpress.git#my-new-buildpack-feature
LXC containers and buildpacks give an incredibly flexible hosting environment. I feel that the current documentation emphasises runtimes & frameworks as the "standard", with a mention that "Heroku buildpacks also work". I think you should switch the emphasis, providing more guidance and samples on how to use and create buildpacks.
Finally, a community stackato buildpack server (like Heroku's vulcan) would be really useful for buildpack developers like myself.
How can people find out more about your Wordpress development workflow, or get involved?
By joining the wordpress-development-flow mailing list.
Subscribe to ActiveState Blogs by Email
Share this post: