I’ve been dabbling in programming whenever I feel inspired with an idea and I feel like tinkering at my computer. I did a fair bit of PHP development over a dozen years ago, and I’ve had to relearn and –worse– unlearn a lot to get with the times. Anyway, it’s fun and challenging, but slow going. My ideas outpace my ability to execute them so I now find myself with a few unfinished projects lying around on my computer. Different projects have different environment requirements (e.g. web server, database setup) and I find it’s starting to get messy and confusing.
Taking a cue from the fine geeks I work with, I’ve started to look into virtualization so that I can simply set up the kind of “server” I need locally on my computer and isolate the configurations I need for my project to just that virtualized environment. This has several benefits:
- I can goof around with settings on the virtual environment without mucking up my own computer;
- I can set up as many environments as I have projects, with no settings from any one of them interfering with the others;
- I run Mac OS X for my every day computing needs and my preferred development tools, but can use the same flavour of Linux to actually run my application as the one running in the target environment, whether it Amazon’s AWS or a Raspberry Pi.
As I started googling the various options and approaches, I realized there is a lot of interesting stuff going on in this space. It’s a bit overwhelming actually, so I’m really writing this post to summarize the approach I think I’m going to take, now that I understand it. Let’s look at the components involved to start.
The Host Environment
That’s my computer. Actually, it’s probably going to consist of my desktop iMac and of my old MacBook Pro for days when I want to work offsite. Having more than one computer to work on is another good reason to virtualize the dev environment: it makes it portable and easy to set up on a different machine while working exactly the same way. I’m going work it so that my project files reside in a folder on my computer that is within my DropBox folder, always synced and backed up to the cloud. This folder will be shared by the guest environment.
The Guest Environment
This is the virtual server environment that will actually be executing the application I’ll be building. It will have access to the project directory in my host environment, and will run the files from there, so I only have one place to manage the files, without having to worry about deploying them whenever I need to see the effects of my code changes.
The Virtualization Package
This is the software that lets you run a virtual computer on your computer. I settled on the free VirtualBox virtualization package, though I seriously considered commercial packages like VMware and Parallels for their slick GUIs and performance. The deciding factor was that Vagrant, which I’ll tell you about shortly, includes a free VirtualBox provider, whereas I would have had to pay ~$80 for a VMware one, not to mention the cost of VMware itself. That’s more money than I should be spending on dabbling.
I found Vagrant when I searched Google for something like “virtualization for developers”. It’s easier to describe what it does than what it is. From their website: “Create and configure lightweight, reproducible, and portable development environments.” It basically automates setting up and launching a development environment so that you can issue a few terminal commands from your project directory to set up the virtual server for your project and SSH to it. Vagrant packages up “boxes” that are essentially disk images of base virtual environments with metadata about configuration. The “Vagrantfile” is a small text file that lives in your project folder and implements the box with settings for your project. The Vagrantfile includes all the information that Vagrant needs to find a copy online of the base box, so if you share your project folder with another developer, they just have to have Virtualbox and Vagrant installed, then type “vagrant up” on the command line, and that’s it. They’re running exactly the same environment you are.
This is software that automates setting up all of the programs, settings, permissions, etc. on the guest environment, and can keep it synced up with a master definition someplace. Vagrant supports Chef and Puppet, both popular configuration management systems. This great presentation recap does a really good job of explaining how it all ties together, but in a nutshell, at least with Chef, you can leverage pre-built and managed software installation and setup scripts (“Library cookbooks”) and combine them into an overall system config using “configuration cookbooks”. Vagrant automatically runs these to ensure your virtual environment has all the programs it needs, in an automated, repeatable, shareable way.
I’m really late to the version control game, mostly because I’ve always been a lone developer that hasn’t had to share the same code with others. That said, it’s a best practice even for solo coders to put their code into a version control system, so I’m going to learn how to do it. I’ve read up a bit on it, enough to know I’ll be going with Git. It’s got a bit of a learning curve from most accounts, but it’s pretty much the standard in the development community these days. I’m working on this tutorial. Anyway, I’m going to use Git to keep my virtual machine settings (the Vagrantfile, cookbooks and data_bags) under source control and an integral part of my individual projects.
Where I’m At
So to summarize a few days’ worth of learning, I’ve got DropBox, VirtualBox, Git and Vagrant all installed on my Mac. Next, in a folder someplace within my DropBox folder, I type the following in the terminal:
git clone https://github.com/Version2beta/vagrant-chef-composer.git
…and a bunch of magic happens. Vagrant spins up a VirtualBox instance of a 64-bit Ubuntu Linux server, and then runs the Chef recipes on it to configure it with an Apache web server, PHP, Composer and the Slim framework. It takes about 5 minutes to run, but you can just watch the commands scroll by in the terminal, or go grab a coffee.
When it’s done, you simply type:
and you’re logged into the virtual machine, all set up and waiting for you to run your next killer app on it. Or, you can type:
into your browser address bar and you’re looking at the empty web server directory, ready for your project.
What I’m Doing Next
I’ve procrastinated enough on environments. I think with all this I’m going to be organized enough and can get coding quickly on a solid basis. I need to build some Git expertise, so I’m going to spend some time with the Git tutorial and a few others out there. Then I’m going to do this tutorial on rapid prototyping in PHP with micro-frameworks, because ultimately, I want to program so I can rapidly build out my ideas, try them on real people, and then hand them off to real software engineers if a permanent build is needed.
OK, I’ve got to head out. More programming fun tomorrow!