MWD03 – Provisioning a local development stack

In the previous post, we set up the Mac workstation and got it ready for modern web development.
In this chapter, we’ll discuss the next key step in setting ourselves up the right way to develop a web application, and this is about creating and provisioning a development environment.
Using Linux is not a crime!
VMs are fantastic
If you are planning to create your app using PHP, Java, Python and or Ruby, then there are 90% chances you will do that on a Unix/Linux powered stack. Otherwise, you would go for Windows, and anyway things would not be very different.
Before we throw money through the window renting a server on the cloud, let’s be practical and consider the most obvious option, which is to leverage your own local workstation to setup a virtual environment. Note again that I advise against using platform ports of xAMP (Apache-MySQL-PHP) and there are a few good reasons for that, along the lines of consistency:
  • Operating system discrepancies (starting with file systems)
  • Software versions
  • Files and folder permissions
  • Stability
This said, the best thing to do is to provision a virtual machine which replicates as closely as possible the target production environment. For this end, we use a virtualisation platform like Virtual Box, as proposed in the previous article, and can install with it any preferred OS stack. Let’s assume a CentOS 6.5 64bits for the example, but it could be anything else, including a custom and home brewed VM.
Fortunately for us, instead of downloading the ISO at, and going through the full install process, ready made boxes are available on the web, and I can mention the following repositories:
My Vagrant is rich
My Vagrant is rich!
Vagrant is an amazing, accessible and free utility, and I hardly see how the modern web developer could ignore it. It allows them to create and configure lightweight, reproducible, and portable development and staging environments, with the exact combination of services and utilities I need for my project. And obviously I will consistently use and refer to Vagrant hereafter, as I am now using it both in my hobbyist and professional lives.
The basics for Vagrant are very well explained on the official site, here:
To install Vagrant, just visit the page and download the right package for your OS:
Done, we are ready to provision our Linux stack for development (and possibly staging) purposes:
As I am a RedHat/Fedora/CentOS enthusiast, I go for a CentoS 5.5 64 bits stack, which I pick from the shelves of Vagrant Cloud (but could have been anywhere else):
This one has been setup with the Virtual Box Guest additions (an I have a specific short article to help you out with upgrading your VB guest additions in case you update Virtual Box).
Let’s first create a working folder:
     $ mkdir ~/sandbox/my_project
     $ cd ~/sandbox/my_project
Now I initialise my local Linux stack:
     $ vagrant init mixpix3ls/centos65_64
=> This immediately create a local .Vagrantfile in your project folder, which you can freely edit and tweak to suit you need, as we will see later.
One thing you might like to immediately do though is to organise proper web port forwarding by inserting the following line in this .Vagrantfile: “forwarded_port”, guest: 80, host: 8080
As you understand, this .Vagrantfile should later on be part of your GIT repository, as a way to share with your fellow developers what sort of server environment your app is supposed to run on.
For now, let’s just switch the Linux machine ON:
     $ vagrant up
It will take some time to download the gig of data corresponding to the image, just look at progress in your terminal window. But eventually your VM is up and running, and you can seamlessly SSH into it using the simple command:
     $ vagrant ssh
3 commands in total: Isn’t that amazingly straightforward?
In case you wonder where all this magic happens, beyond the 5kb .Vagrantfile stored in the project folder:
This is great but still a little bit bare bones for a web server, and we now have to continue provisioning the image at least with a web server and a database server.
Do you manual?
Do you manual?
The old dog and control freak in me can’t help, at least once, to do it the hard manual way, and that’s what it looks like:
$ sudo yum update # Careful because a Kernel update may ruin the Virtualbox Guest Tools
$ sudo yum install ntp
$ sudo service ntpd start
$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Australia/Sydney /etc/localtime #properly set server time to this part of the world we love
$ sudo yum install nano # I need my fancy text editor
$ sudo yum install httpd # This is Apache, and you could choose Nginx or Tomcat
$ sudo service httpd start
$ sudo chkconfig httpd on
$ sudo nano /etc/httpd/conf/httpd.conf # Change Admin email
$ cd /etc/httpd/conf.d
$ sudo mkdir vhosts
$ sudo yum install php php-mysql
$ sudo yum install php-* # all extensions, because I can’t exactly tell which ones I need for now
$ sudo nano /etc/php.ini # Change Memory parameters
$ cd /var/www/html
$ sudo nano /var/www/html/phpinfo.php
$ sudo tar -jxf phpMy*
$ sudo rm phpMyAdmin-4.1.13-all-languages.tar.bz2
$ sudo mv phpMyAdmin-4.1.13-all-languages/ phpMyAdmin
$ cd phpMyAdmin
$ sudo find . -type f -exec chmod 644 {} \;
$ sudo find . -type d -exec chmod 755 {} \;
$ sudo mv
$ sudo nano # Change blowfish secret
$ sudo rm -R setup
$ yum install php-mcrypt # these 2 lines are necessary to install MCrypt, and be able to deliver some reasonably serious work around cryptography
$ sudo yum install mod_ssl
$ sudo service httpd restart
$ sudo yum install mysql mysql-server
$ sudo service mysqld start
$ sudo mysqladmin -u root password ******
$ sudo chkconfig mysqld on
$ sudo yum install git
$ sudo nano /etc/conf/con.d/my_website.conf
$ sudo service httpd reload
Now just hit
=> to access MySQL via PHPMyAdmin
=> in your local browser, and you should see the magic happening, with the default Apache page.
It does not seem much, yet you might quickly spend 30min+ going through the above, if everything goes right and you do not inadvertently commit any typo.
Plus what you’ve just done, your fellow developers in the team would have to do it as well, as they VagrantUp their own local development environment: This is of course not acceptable.
One obvious and immediate countermeasure is to share the custom BOX we’ve just created with our peers via network or cloud storage. This is well covered by Vagrant here: . Your peers would simply have to use the box add command:
$ vagrant box add my-box /path/to/the/
$ vagrant init my-box
$ vagrant up
However, this is still a bit brute force and not fully flexible and future proof: What if I realise I need to add a specific service or configuration? I would have to update my box and to copy it again over the network for my peer developers, and moving around 1Gb of data is not the most elegant thing to do, is it?
Therefore we are looking for a more scripted and flexible way to provision our Linux stack on the fly.
In my next article, I will discuss a couple of simple enough yet professional solutions to provision your development environment in a robust and agile manner using either Chef or Puppet.
Next to MWD04 – Provisioning the stack with Chef