All my posts about Ansible
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....
It has been a while as I have been busy writing, I thought I would spend some of my freetime having a very quick play with Ansible AWX↗ , which is the Open Source version of Ansible Tower↗ . I created the following Vagrantfile to launch a CentOS 7↗ server; Ansible AWX 1/3 # -*- mode: ruby -*- # vi: set ft=ruby : VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "centos/7" config....
I am not sure if this a bug or not, but I spent an hour scratching my head today trying to figure out why part of playbook which was working seemingly suddenly stopped. I have a playbook which executes each morning to create a staging version of a site from the previous night’s snapshots. Each weekday morning at 0730am it … Bootstraps an AWS environment (VPC, ELB and all the other acronyms) Launches a RDS instance from the previous nights snapshot Launches an instances and deploys an application and then creates an AMI Creates an auto-scaling group and launches three instances using the new AMI behind an ELB The base operating system is Red Hat Enterprise Linux 7 which does not ship with any AWS tools installed by default, so before the tasks which start interacting with the instance and application I run the following;...
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↗ ....
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....