In all the years dealing with logic gates and Boolean algebra, I don’t think I’ve ever seen a clearer visual representation than this:
Got it from Facebook. If you know who is the author, please ping me.
All posts across the whole website belong to this category. They might also belong to some other categories as well, but this one holds all of them. Hence the descriptive name – All.
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.
I find this to be very true … So true, in fact, that I’m thinking to include it in the interview process.
By ways of CommitStrip.
Here are some great news from the Amazon AWS blog – the announcement of the Elastic File System (EFS):
EFS lets you create POSIX-compliant file systems and attach them to one or more of your EC2 instances via NFS. The file system grows and shrinks as necessary (there’s no fixed upper limit and you can grow to petabyte scale) and you don’t pre-provision storage space or bandwidth. You pay only for the storage that you use.
EFS protects your data by storing copies of your files, directories, links, and metadata in multiple Availability Zones.
In order to provide the performance needed to support large file systems accessed by multiple clients simultaneously,Elastic File System performance scales with storage (I’ll say more about this later).
I think this might have been the most requested feature/service from Amazon AWS since EC2 launch. Sure, one could have built an NFS file server before, but with the variety of storage options, availability zones, and the dynamic nature of the cloud setup itself, that was quite a challenge. Now – all that and more in just a few clicks.
Thank you Amazon!
I’ve been an Evernote user for years. I used to have the Premium account for the offline notebooks feature, but since they’ve enabled that on the Basic account too, I stopped paying. It looks like the times are changing once again. Here’s an excerpt from the email I received today:
In the coming weeks, Evernote Basic accounts will be limited to two devices, such as a computer and phone, two computers, or a phone and a tablet. You are currently over this limit, but will have at least 30 days to adjust. Plus and Premium accounts will continue to support access from an unlimited number of devices.
There’s also a link to this blog post.
So. Here are my options: