Using Ansible Automation Platform is very handy to run Ansible playbooks in an orderly way. And Red Hat even offers a developer license so that it’s possible to test all features of AAP.
But one problem that I ran into, is that I often throw away machines and start from scratch again. As the developer license allows for 16 machines, I thought I was on the save side, as I have a maximum of 4, maybe 5 machines I use for testing.
As I was planning an Ansible Meetup about the Ansible Automation Platform (AAP, the successor of Ansible Tower) I was contemplating about a demo environment for the attendants. This can be done with ease as it it nothing more than clicky-di-click.
You can imagine that’s not the way I went :-). There is a simple rule in
life:
If you can automate it, automate it. The complete environment is
going to be a multipart environment, so that the attendants can
experiment and have an environment that slightly resembles real live.
When working for a customer I was installing an Ansible Automation Platform cluster and to keep track of all systems I decided to create a nice message of the day, of course with cowsay.
Something like this:
___________________________
< Member of the AAP Cluster > | Host name : thunderbolt
--------------------------- | Host alias : cn01
\ ^__^ | Function : Ansible AAP Control node
\ (oo)\_______ | Location : Amsterdam
(__)\ )\/\ | IP address : 192.168.63.194
||----w | | VMware name : EXDTONKE01
|| ||
Early this week a co-worker asked if it was possible to access the Ansible command-line in a playbook. It seems that is not the case, in a normal, clean Ansible environment.
But in the meantime I was creating a playbook that served multiple
purposes, stopping and starting services. These playbooks are completely
the same, except for the start and stop keywords. Of course I could
have solved that with a variabele, either hardcoded or as an extra
variable on the commandline. But, where is the fun in that :-)
In our work environment we have role-based access for passwords (of course). But as we deploy all systems with Ansible, we could end up that someone with only deploy permission ends up with access to all passwords. It’s obvious that we don’t want that, so I started checking in to Ansible’s ability to have multiple vault passwords.
Starting with Ansible 2.4 and above, vault IDs are supported.
Since Ansible version 2.5 there is a lot of discussion and confusion
about the loop syntax. There is also discussion if with_…: will be
replaced by loop: deprecating the with_… keywords. Even Ansibles
documentation is not clear about this.
Should I use loop: or with_…:, in fact nobody really knows. What
would the correct syntax be?
---
- name: Loops with with_ and lookup
hosts: localhost
connection: local
gather_facts: no
vars:
people:
- john
- paul
- mary
drinks:
- beer
- wine
- whisky
tasks:
- name: with nested
debug:
msg: "with_nested: item[0] is '{{ item[0] }}' and item[1] is '{{ item[1] }}'"
with_nested:
- "{{ people }}"
- "{{ drinks }}"
- name: nested and loop
debug:
msg: "nested_loop: item[0] is '{{ item[0] }}' and item[1] is '{{ item[1] }}'"
loop:
- "{{ people }}"
- "{{ drinks }}"I am a long time Ansible user and contributor (since 2012) and I have been struggling with a decent setup for a multi-environment case. I have been designing and re-designing a lot, until I came up with this design. And what a coincidence, a customer wanted a setup that was exactly this. So this concept is a real world setup, working in a production environment.
Did I get your attention? Read after the break, but take your time. it is a long read.
Some time ago I created a playbook to show the content of a rendered
template. When you keep digging in the Ansible documentation, you
suddenly stumble over the template lookup-plugin. And then it turns
out that my playbook is a bit clumsy.
A nicer and shorter way to do it:
---
#
# This playbook renders a template and shows the results
# Run this playbook with:
#
# ansible-playbook -e templ=<name of the template> template_test.yml
#
- hosts: localhost
become: false
connection: local
tasks:
- fail:
msg: "Bailing out. The play requires a template name (templ=...)"
when: templ is undefined
- name: show templating results
debug:
msg: "{{ lookup('template', templ) }}"
A couple of days ago a client asked me if I could solve the following problem:
[Read More]They have a large number of web servers, all running a plethora of PHP versions. These machines are locally managed with DirectAdmin, which manages the PHP configuration files as well. They are also running Ansible for all kind of configuration tasks. What they want is a simple playbook that ensures a certain line in all PHP
inifiles for all PHP versions on all webservers.
During my last Ansible training the students needed to create some Ansible templates for them selfs. As I do not want to run a testing template against some, or all, machines under Ansible control I created a small Ansible playbook to test templates.
This is the playbook:
---
#
# This playbook renders a template and shows the results
# Run this playbook with:
#
# ansible-playbook -e templ=<name of the template> template_test.yml
#
- hosts: localhost
become: false
connection: local
tasks:
- fail:
msg: "Bailing out. The play requires a template name (templ=...)"
when: templ is undefined
- name: do template
template:
src: "{{ templ }}"
dest: "/tmp/{{ templ }}"
- name: get template
command: cat "/tmp/{{ templ }}"
register: tmplt
- name: show template
debug:
msg: "{{ tmplt.stdout.split('\n') }}"
- name: remove template
file:
path: "/tmp/{{ templ }}"
state: absent
Last Saturday I attended Loadays in Antwerp, Belgium.
After listening to Jan Piet Mens’s talk about Ansible, I was up for it.
At 11:30 sharp, I started my own presentation for an almost packed room. It’s called Ansible, why and how I use it and you can find it on SpeackerDeck.
It was a lovely talk, with a very knowledgeable crowd.
Please, have a look at it and if you have any questions, let me know.
Last couple of days I attended Configuration Managememt Camp in Ghent, Belgium. On Monday morning we started of with presentations of Mark Burgess (CFEngine), Luke Kanies (Puppet) and Adam Jacob (Chef). Good talks about the future of things.
After lunch it got nerdy ans I joined the Ansible room, to see how things went and at 17:00 I started my own presentation for a completely packed room. It’s called `Ansible, why and how I use it' and you can find it on SpeackerDeck.
Today I’m attending the first full day Ansible configuration meeting. This meeting is in Antwerp, Belgium, a drive of almost 2 hours. Thanks to Multi Mho (Maurice Verheesen) I didn’t need to drive, he wanted to try out his nice, new car. It drives perfectly and we arrived about 30 minutes early.
For a first meeting of a new tool there where a lot of attendants, amongst others (and I don’t want to forget anybody, so I won’t even try to give a complete list), but below are the people I think that where there.
Playing with Ansible I did get the idea to make a
nice welcome message when you log in to a server. This message needs to
be placed in a file, which is configured in /etc/ssh/sshd_config with
the banner option. I call this file /etc/issue.
Of course I want to deploy this file with Ansible, so I first defined
an entry in the hosts file. This looks like this:
# Settings for master [master] master # Variables for master [master:vars] location=cow shed room=ESX5i issueremarks=This is the master Ansible server. Please be carefull!!