I love creating things, articles, doodles, websites and lots of other things too. However, while I love creating, the last part of any creative endeavour is always turns our to be more energy intensive than you anticipated. Modern project management will try to teach you that you should allocate around 30% of the time for the last 10% of the project. I don’t really disagree. That final push over the line, the last tweak of a logo, that last commit to your code, or getting your web server live. All these final tasks have an annoying tendency to suck up more time than you wanted or anticipated. Darn them all for stealing your precious time! Regardless of your own personal creative irks, what we are going to talk about today is getting your web-server running via code. Infrastructure as code or IaC for you acronym loving people.

Let me ease you in gently.

What does infrastructure as code mean?

If there is a couple of things I have learned in life it is that acronyms are everywhere(especially in development circles) and that Wikipedia knows more than I do. If you really want the in-depth answer to 'What does infrastructure as code mean' then you should hop on over to the article at Wikipedia here. For anyone too lazy to click the link(shame on you), or if you don’t want to leave my beautiful page and website(well done you and your amazing taste), then I have made a short summary below.

Infrastructure as code is a process of provisioning and managing hardware through machine readable files. This has many benefits including the ability to be placed in version control, faster execution and reduced risk.

To summarise, using infrastructure as code can make it easier to build, provision, backup and test. Most importantly however, it makes it much easier for a team to use. By using infrastructure as code there are less possibilities of steps being missed or done incorrectly. You are going to be happier, sleep better, skip to work instead of skulking and many other benefits that I just do not have the time to mention here!

My experience with getting servers live

On my last big project I used a combination of vagrant and shell scripts to automate the build process locally. On the live server I used just shell scripts. Even though it was just a series of scripts it was all nicely stored in version control with a solid set of documentation and guides on each stage of the process. The problem was whenever I thought about going back to that project and trying to do it all again I started to panic. I would wonder if it would work exactly as I remembered it. This is why on my latest project I made a promise to myself. That promise was to make my life easier going forward, even if it took a bit longer to implement right now.

The right tools for the job

The first step was deciding what tools to use. I already knew and liked Vagrant, sure it could be slow if you tried to do any updates to the system, but it still had a piece of my heart. I was always a sucker for underdogs and Vagrant just conjures up visions of a plucky underdog with slightly scruffy style but a big smile. Had they named Vagrant something like ‘Launchpad’ I might not have been so enamoured with it. However, they didn’t and Vagrant is Vagrant. So, with Vagrant in my back pocket I needed something else to ease my server set-up, I had already tried Ansible and liked the idea of it. Although I found people were prone to giving birth to literally 9783 files all nicely nested in folders whose naming convention meant nothing to me and all to get a simple LAMP server up and running. If it was just 9782 files I might have been able to cope, however the extra 1 was too much and I had to take a break from Ansible.

Absence makes the heart grow fonder…

Roll on a few months and I was ready to give Ansible another try. I followed some simple tutorials and guides and to my surprise I started to think that maybe it would work. I believed I could get a LAMP stack, MEAN stack or whatever live without creating more files than people living in the capital of India. Ansible was going to be my friend, I was sure of it.

My new friends Vagrant and Ansible

Now I have Vagrant in one pocket and Ansible in the other, my pockets are pretty full, full of awesome tools that help me build beautiful(okay just average looking) infrastructure as code. I sleep better, I have a spring in my step and everywhere I look I see beauty and tranquillity. All this serenity and inner peace thanks to the power of IaC. Yay for Iac and those fantastic people creating this stuff! What could be next?

Now I have two friends who will never let my local and live servers down, they are dependable and trustworthy. All I needed was one more friend… A cloud provisioning tool! So now I am looking at how I can get Terraform to play nicely with my friends Ansible and Vagrant. I am 99% sure that as soon as I learn it there will be a new fancier tool out there, however I will not let that put me off. For the IaC fanatics(I know you’re out there just Terra-forming some beautiful Kubernates on a mountain of vagrant docker containers while staring into an ocean of AWS services), I refuse to fail you.