Containers are all about automation -- Ansible is a great tool as well
Daniel Nashed – 26 April 2021 07:17:43
One of the most important aspects about containers and images, is that the environment is always the way you define it.
You can run the same changes first in a test/integration environment and apply it exactly in production on many environment.
It's also about standardization and making installations and updates easier.
My lab preparation for a container workshop tomorrow is installed fully automated.
Only the steps we want the participants to learn, will be manual.
The servers in the lab are created using my providers (Hetzner) REST services for their cloud API and also their DNS API.
It's a Notes databases using the new HTTP Request class.
But still after an automated installation including SSH key deployment, there are some manual steps to perform.
Ansible
Ansible is pretty interesting -- very flexible and powerful.
It also needs no additional software installed on those servers and operates over SSH.
You just install it on one machine define your target machines.
Depending what you want to do, Ansible isn't rocket science.
Let me share two of my playbooks I built over the weekend.
The first playbook just installs additional software and updates Linux.
The second playbook is more interesting. It replaces the default configuration from my lab preparation with the actual machine configuration.
Typos in hostnames, IP addresses can be quite difficult to troubleshoot in a work-shop.
So I defined default configurations, that will be automatically patched on each host :-)
The replace functionality looks simple. But the devil is in the detail.
Ansible is very powerful. But even the basic modules can be a lot of fun to configure..
The following example uses the lab SSH key to authenticate.
Installation on one workstation takes 5 min including defining the "lab" hosts.
And you can just run playbooks via:
ansible-playbook myplaybook.yml
So similar to a Dockerfile defining a container, Ansible can be used to manage servers to be exactly how you want them to look like.
In my case I update all 15 servers in the lab at once with one statement.
This was the last missing puzzle piece for a fully automated lab environment.
-- Daniel
Install Packages and updates the machine
#!/bin/ansible-playbook
- hosts: lab
remote_user: root
vars:
ansible_ssh_private_key_file: /local/ansible/lab_ec_key.pem
order: sorted
gather_facts: false
tasks:
- name: install epel-release
yum:
name: epel-release
state: latest
- name: install software
ansible.builtin.package:
name:
- nano
- mc
- jq
- wget
state: latest
- name: update the system
yum:
name: "*"
state: latest
Patch lab configuration files
#!/bin/ansible-playbook
- hosts: lab
remote_user: root
vars:
ansible_ssh_private_key_file: /local/ansible/lab_ec_key.pem
gather_facts: True
tasks:
- name: find replace files
raw: find /local/github/domino-docker/lab -type f -name "*yml" -o -name "*.json"
register: reg_files
- name: replace hostname
replace:
dest: "{{ item }}"
regexp: "master.domino-lab.net"
replace: "{{ inventory_hostname }}"
loop: "{{ reg_files.stdout_lines }}"
- name: replace IP
replace:
dest: "{{ item }}"
regexp: "1.2.3.4"
replace: "{{ ansible_default_ipv4.address }}"
loop: "{{ reg_files.stdout_lines }}"
- Comments [0]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}