DevOps

If you’ve tried running Packer with CentOS on AWS, you probably noticed this:

    sudo: sorry, you must have a tty to run sudo

I’m not talking about launching an EC2 instance, uploading the zip with WordPress and going through the installer. I’m talking about immutable infrastructure, scalable, self-healing setup of WordPress within AWS.

I have recently passed Red Hat’s EX407 (Red Hat Certificate of Expertise in Ansible Automation exam) and I wanted to share my experience for anyone else who might be looking into getting that certificate. At the time of my exam, I was only a second (publicly visible) person in the UK who had that certificate. Probably because it was only made available in summer this year.

The purpose of every deployment pipeline is… a deployment. So this final part of the series, will focus on just that. If you missed the intro, check out the video where I describe a typical pipeline here. The other parts of this series are part 1: test phase and part 2: build phase.

Once we create an AMI that we’d like to deploy, performing a rolling update on existing instances is fairly easy. Usage of Auto scaling groups and CloudFormation makes it even easier - since AWS Auto scaling groups support the rolling updates out of the box.

Or, if your applications requires blue-green deployments, using CloudFormation is almost essential.

Welcome to the second part of my series on deployment pipelines. If you missed the intro, check out the video where I describe a typical pipeline here. The other parts of this series are part 1: test phase and part 3: deployment onto an environment.

After the test phase of the pipeline, once the quality of the code has been checked, we must build a deployable artefact for this version (commit) of the code. In case of AWS, this would be an AMI (Amazon Machine Image), which can then be deployed as a new instance in our environment.