I am about to start a new PHP project, which of course means figuring out how the heck I'm going to run a PHP on my Mac. For the redesign of the Brooklyn Museum Website, we were serving pages from a PHP CMS and used MAMP. For local development, I had to fiddle around with
hosts files for a few frustrating hours. The MAMP setup ended up working fine but I was not in the mood to repeat that whole song and dance for this upcoming project.
I saw this as an opportunity to learn a new tool,Vagrant. I was drawn to Vagrant because I liked the idea of a completely isolated environment (Vagrant does this by creating an instance of virtual machine) that I could reset if something goes wrong.
I have this belief that learning a new development tool will magically make the project be more fun and go faster. A silver bullet. I always forget that in learning and configuring new tools always takes longer than I expected and can become its own mini-project (see yakshaving ).
Sometimes it's like getting a shiny, new kitchen gadget and thinking that this tool will make it easier and more fun to cook but then you realize how much of a hassle it is to wash the gadget, so you never use it again. You tell yourself that at least it's nice to have in case you ever do ever need it.
Customizing a bare Ubuntu environment was a primer on setting-up a web server. I had to make sure this environment mirrored the production environment as closely as possible. [Later, I learned that I could just export our production environment, an Amazon EC2 instance, as a
.box file, which Vagrant would see as a base box, but I was too lazy to configure multifactor authentication to use the AWS tools].
I was playing sysadmin and quickly remembered the lack of a knack I have for backend technologies and how due to temperament, I found sysadmin work annoying. I switched to using Homestead.
Homestead is preconfigured and so it was easy to drop in my files. The disadvantage of this was that it doesn't mirror the production server and any bugs that might occur on the production server might be an issue with the dev (Homestead) environment being out of sync with the production server.
I ended up partially abandoning Vagrant because I couldn't get it exactly the way I wanted and it was taking too much time. (also the lead developer strongly encouraged me to just do development on a dev instance). (I said partially because I might get back to it when I've recuperated some patience).
While I decided to not use Vagrant, I did learn something new. I also gained an appreciation for it as a development tool.
Takeaways from Using Vagrant
- a completely isolated environment
I didn't have to install dependencies on my machine that would conflict with past and future projects. Vagrant is really a wrapper for a VM environment like VirtualBox. All it does is boot up a virtual machine that you can configure without the fear of altering your computer's settings
- making mistakes aren't terrible
So, if you made a mistake configuring the dev environment or had a bad database query, you can just run
vagrant destroy or
vagrant reload to destroy the dev environment and reload it (the dev environment is really just a virtual machine)
- ability to share machines
vagrant package and share the generated
- doesn't preserve any dependencies you've installed
Let's say you start with a basic Ubuntu machine and then you run
sudo apt-get a billion times to get all your dependencies in a row. All the changes you've made to your Ubuntu instance get lost if you don't re-package the base
- doesn't preserve databases
Since all changes you've made to your machine get lost, it also means that any changes to databases get lost too. Unless you write some shell scripts that would run during provisioning
- slow to boot-up and most likely a resource hog
Vagrant creates a virtual computer on your computer, and if you don't have enough RAM, this might cause your computer to slow to a crawl.