Install Ansible 2.0+ on Amazon AMI

Today, while upgrading some of my Ansible roles I’ve hit the problem.  Some of the newer roles require Ansible 2.0.  My Amazon AMI machine that runs the playbooks was still on version 1.9.  EPEL repository doesn’t seem to have the newer Ansible version yet.  Gladly, Google brough in this StackOverflow thread, which suggested installing Ansible with pip, not with yum.  This helped a lot:

rpm -e ansible
pip install ansible

It actually brought in Ansible v2.2 (see also Ansible v2.1), which is even better.

Amazon Linux AMI 2016.09

amazon ami 2016.09

AWS Blog lets us know that Amazon Linux AMI 2016.09 is now available.  It comes with a variety of updates, such as Nginx 1.10, PHP 7, and PostgreSQL 9.5 and Python 3.5.  Another thing that got quite a bit of improvement is the boot time of the Amazon Linux AMI instances.  Here’s a comparison chart:

amazon-linux-ami-launch-time-2016-09-whiteboard

Read about all the changes in the release notes.

P.S.: I’m still stuck with Amazon AMI on a few of my instances, but in general I have to remind all of you to NOT use the Amazon AMI.  You’ve been warned.

Top 13 Amazon Virtual Private Cloud (VPC) Best Practices

Cloud Academy Blog goes over top 13 Amazon VPC best practices – particularly good for those just starting up with the platform.  The article discusses the following:

  1. Choosing the Proper VPC Configuration for Your Organization’s Needs
  2. Choosing a CIDR Block for Your VPC Implementation
  3. Isolating Your VPC Environments
  4. Securing Your Amazon VPC Implementation
  5. Creating Your Disaster Recovery Plan
  6. Traffic Control and Security
  7. Keep your Data Close
  8. VPC Peering
  9. EIP – Just In Case
  10. NAT Instances
  11. Determining the NAT Instance Type
  12. IAM for Your Amazon VPC Infrastructure
  13. ELB on Amazon VPC

Overall, it’s a very handy quick list.

Serverlessconf 2016 – New York City: a personal report

Serverlessconf 2016 – New York City: a personal report – is a fascinating read.  Let me get you hooked:

This event left me with the impression (or the confirmation) that there are two paces and speeds at which people are moving.

There is the so called “legacy” pace. This is often characterized by the notion of VMs and virtualization. This market is typically on-prem, owned by VMware and where the majority of workloads (as of today) are running. Very steady.

The second “industry block” is the “new stuff” and this is a truly moving target. #Serverless is yet another model that we are seeing emerging in the last few years. We have moved from Cloud (i.e. IaaS) to opinionated PaaS, to un-opinionated PaaS, to DIY Containers, to CaaS (Containers as a Service) to now #Serverless. There is no way this is going to be the end of it as it’s a frenetic moving target and in every iteration more and more people will be left behind.

This time around was all about the DevOps people being “industry dinosaurs”. So if you are a DevOps persona, know you are legacy already.

Sometimes I feel like I am leaving on a different planet.  All these people are so close, yet so far away …

Forcing Amazon Linux AMI compatibility with CentOS in Ansible

One of the things that makes Ansible so awesome is a huge collection of shared roles over at Ansible Galaxy.  These bring you best practices, flexible configurations and in general save hours and hours of hardcore swearing and hair pulling.

Each role usually supports multiple versions of multiple Linux distributions.  However, you’ll find that the majority of the supported distributions are Ubuntu, Debian, Red Hat Enterprise Linux, CentOS, and Fedora.  The rest aren’t as popular.

Which brings me to the point with Amazon Linux AMI.  Amazon Linux AMI is mostly compatible with CentOS, but it uses a different version approach, which means that most of those Ansible roles will ignore or complain about not supporting Amazon AMI.

Here is an example I came across yesterday from the dj-wasabi.zabbix-server role.  The template for the Yum repository uses ansible_os_major_version variable, which is expected to be similar to Red Hat / CentOS version number – 5, 6, 7, etc.  Amazon Linux AMI’s major version is reported as “NA” – not available.   That’s probably because Amazon Linux AMI versions are date-based – with the latest one being 2016.03.

[zabbix]
name=Zabbix Official Repository - $basearch
baseurl=http://repo.zabbix.com/zabbix/{{ zabbix_version }}/rhel/{{ ansible_distribution_major_version }}/$basearch/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX

Officially, Amazon Linux AMI is not CentOS or Red Hat Enterprise Linux.  But if you don’t care about such little nuances, and you are brave enough to experiment and assume things, than you can make that role work, by simply setting the appropriate variables to the values that you want.

First, here is a standalone test.yml playbook to try things out:

- name: Test
hosts: localhost
pre_tasks:
- set_fact: ansible_distribution_major_version=6
when: ansible_distribution == "Amazon"
tasks:
- debug: msg={{ ansible_distribution_major_version }}

Let’s run it and look at the output:

$ ansible-playbook test.yml

PLAY [Test] *******************************************************************

GATHERING FACTS ***************************************************************
ok: [localhost]

TASK: [set_fact ansible_distribution_major_version=6] *************************
ok: [localhost]

TASK: [debug msg={{ ansible_distribution_major_version }}] ********************
ok: [localhost] => {
"msg": "6"
}

PLAY RECAP ********************************************************************
localhost : ok=3 changed=0 unreachable=0 failed=0

So far so good.  Now we need to integrate this into our playbook in such a way that the variable is set before the third-party role is executed.  For that, we’ll use pre_tasks.  Here is an example:

---
- name: Zabbix Server
hosts: zabbix.server
sudo: yes
pre_tasks:
- set_fact: ansible_distribution_major_version=6
when: ansible_distribution == "Amazon" and ansible_distribution_major_version == "NA"
roles:
- role: dj-wasabi.zabbix-server

A minor twist here is also checking if the major version is not set yet. You can skip that, or you can change it, for example, to examine the Amazon Linux AMI version and set corresponding CentOS version.