Packer, Ansible, CentOS and requiretty
If you’ve tried running Packer with CentOS on AWS, you probably noticed this:
sudo: sorry, you must have a tty to run sudo
Notes from our work with AWS, DevOps and security: news and new features, fixes for common problems, and how we solved real client issues.
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.
For an updated ready-to-use CloudFormation template of this code, see newer post: Complete code: cross-region RDS recovery .
Amazon RDS is a great database-as-a-service, which takes care of almost all database-related maintenance tasks for you - everything from automated backups and patching to replication and fail-overs into another availability zones.
Unfortunately all of this fails if the region where your RDS is hosted fails. Region-wide failures are very rare, but they do happen! RDS does not support cross-region replication at the moment, so you cannot simply create a replica of your database in another region (unless you host the database on an EC2 instance and set up the replication yourself). The second-best option, to make sure you can restore your service quickly in another region, is to always have a copy of your latest database backup in that region. In case of RDS, that can mean copying automated snapshots. There is no option for AWS to do it automatically, but it can be easily scripted with AWS Lambda functions.
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.