Infrastructure as Code 🤖

In my last post↗ I wrote about how I created an Azure DevOps pipeline using Ansible in a more “Terraform” way, however, although I have used Terraform and Azure DevOps quite a bit I realised I didn’t really have a template for a pipeline. Before we look at the pipeline itself I should point out that is uses the the Terraform Azure Pipeline extension by Microsoft DevLabs ↗ from the Visual Studio Marketplace↗ , if you are following along with this post please ensure that the extension is installed in your organisation before proceeding. ...

I thought it was was about time that I started to have a play with Azure DevOps a little more than I have been doing, one of the things I have always meant to look at in the past is using DevOps to run Ansible playbooks. However the Ansible Task↗ recommended by Microsoft has always put me off, the reason for this is that this task requires a Virtual Machine to run Ansible — this to me always seemed a little overkill. ...

Over the last few months I have been doing more and more work with Ansible to manage end to end deployments in Azure. For the most part Ansible’s core set of Azure modules work with no problems and more than do the job. However, with the rate which Microsoft are both adding new features and functionality it is difficult to keep up. The core Ansible modules rely on several Azure python libraries to be updated before the functionality can be added or introduced to the core module set. ...

I have been using Terraform over the last few months, having not used it in anger for quite a while↗ since the projects I have been working on have been more suitable for using Ansible↗ . However, as I am doing more and more with Microsoft Azure, I found the Ansible modules a little lacking, plus for someone of the projects I have had to use an orchestration tool which can natively run on Windows. ...

More and more I am having to not only think about how I would ensure that the infrastructure a service I am deploying on is highly available but also how I can manage its entire life-cycle in code. I have tried several tools for this such as Terraform↗ , Puppet and Ansible, however over the last six months or so I have settled on Ansible. After I first looked at it back in December 2014↗ it has come on quite a lot, especially after the version 2 release at the start of this year↗ . ...

As regular readers will know I really like the tools provided by Hashicorp↗ and today I found an excuse to use one. I needed to bring up a Virtual Machine in Microsoft Azure↗ . I hadn’t logged into Azure for quite a while so imagine my shock when I opened the dashboard, it’s not that great and the beta of the new one isn’t that brilliant either. It was so bad I tweeted about it …. ...

I have watched numerous videos and seen quite a few slide decks which cover tools such as Puppet, Chef & Ansible. I have witnessed an entire rack of servers PXE boot, installing their base operating systems, configuring their services and then finally checking out a copy of a production ready codebase. Even after seeing this several times the old school sysadmin in me still thinks this is witchcraft. In the world of dedicated servers or virtual machines this is great, however when it comes launching an auto-scaling instance in a service such as Amazon Web Services using orchestration tools in real-time could be the difference in your application staying online or failing. ...

All of the posts on orchestration on here have been about Puppet on CentOS however last week I had need to script an AWS architecture and then launch instances built with Packer↗ into it. After much swearing I managed to hack together a python script which used Boto↗ to create a launch configuration and register it with an auto-scaling group, I then used a second script which re-cycled instances behind the Elastic Load Balancer which were launched with the previous launch configuration. ...