| View previous topic :: View next topic |
| Author |
Message |
Elleni
Veteran
Joined: 23 May 2006
Posts: 1270
|
 Posted: Mon May 08, 2023 6:38 am Post subject: question on ansible |
 |
|
I started playing around with ansible and was able to create my first playbook for updating yum based distros incl. showing services, where I can identify critical service(s) and ask wether update should be performed anyways and also identifying if a kernel update was performed thus a reboot is needed or not. Besides enabling mail notifications, I wonder if the following is possible and if somebody could help me on howto implement this.
I would love the same playbook would be able to determine if it is a yum based package manager involved, and if it is a apt based one do the same for those, and last but not least if its suse based do the needed updates using zypper. Any help would be greatly appreciated as I dont know yet how to proceed.
Edit - in case this fits better in other things in gentoo thanks @mod for a move there. |
|
| Back to top |
|
 |
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 361
|
| Posted: Mon May 08, 2023 9:28 am Post subject: |
|
|
I am not really experienced with Ansible. Nevertheless I share my thoughts.
I am pretty sure that this is possible. You have to check some conditions inside the playbook.
Although I would write two different playbooks for yum and dpkg based distros. You will need to "organise" the inventory file so that you have a "yum" group of hosts and a "dpkg" group of hosts and run for example the "playbook_yum.yml" with the "yum" hosts group.
Both approaches have advantages and disadvantages. |
|
| Back to top |
|
|
Elleni
Veteran
Joined: 23 May 2006
Posts: 1270
|
| Posted: Mon May 08, 2023 12:44 pm Post subject: |
|
|
| I know, I could do it that way but I would rather like to organize my inventory hosts file in a way where I group some testing servers and then a second group with the productive ones or with groups of the different department's server rather than with distrospecific groups. Thus I'd like to find a solution where the playbook queries the servers and depending on the distro chooses the right role / task to be executed. |
|
| Back to top |
|
|
spica
Apprentice
Joined: 04 Jun 2021
Posts: 282
|
| Posted: Mon May 08, 2023 7:18 pm Post subject: Re: question on ansible |
|
|
| Elleni wrote: | | I would love the same playbook would be able to determine if it is a yum based package manager involved, and if it is a apt based one do the same for those, and last but not least if its suse based do the needed updates using zypper. Any help would be greatly appreciated as I dont know yet how to proceed. |
ansible.builtin.package |
|
| Back to top |
|
|
Elleni
Veteran
Joined: 23 May 2006
Posts: 1270
|
| Posted: Mon May 08, 2023 8:15 pm Post subject: |
|
|
| That sounds great, thanks. I'll have a look. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3129
|
| Posted: Tue May 09, 2023 12:05 am Post subject: |
|
|
| Quote: | | group some testing servers and then a second group with the productive ones or with groups of the different department's server rather than with distrospecific groups |
There is intersect() filter, which allows you to find items common to 2 lists (groups), it's probably a bad solution to the problem at hand, but does come in handy sometimes.
Playbook executes a role on hosts, and also ansible-playbook accepts --limit option on command line. You can have one category of groups (e.g. testing/prod) to chose environment, and another category to define OS (and a role that needs to be launched). This is a sub-par solution too.
However, ansible also supports conditional execution based on a host variable (e.g. you can filter by OS type, which is queried during "collecting facts" phase) or evaluation of expression defined as a guard AFAIR there was some problem with the universal package: module, so using collected facts to trigger a conditional role may or may not be a better option. Also, debug: module allows you to print variables of interest at arbitrary points during playbook execution. Very useful for both, learning ansible and writing your own roles.
There is even very convenient block: directive, which allows you to define a group of tasks to be attempted and optionally another group of tasks to recover from errors should the first group fail.
Finally, inventory does not have to be included in a playbook. It can be a distinct directory tree (highly recommend making it a directory tree with hosts, host_vars and group_vars rather than a single ini file). If you have 2 environments, testing and prod, it makes sense to create 2 inventories for them. Separating things this way from the get-go will save you a lot of headaches down the line. You WILL make mistakes, don't let them accidentally blow EVERYTHING up. |
|
| Back to top |
|
|
Elleni
Veteran
Joined: 23 May 2006
Posts: 1270
|
| Posted: Tue May 09, 2023 1:43 pm Post subject: |
|
|
| Code: | cat roles/linux-os-patching/tasks/main.yml
---
# tasks file for linux-os-patching
- name: Update all installed packages for CentOS, Rocky and Fedora
when: ansible_distribution == "CentOS" or ansible_distribution == "Rocky" or ansible_distribution == "Fedora"
yum:
name: '*'
state: latest
update_cache: yes
update_only: no
register: package_update_status
- name: Show Update details
debug:
msg: "{{ package_update_status }}"
# Shutdown/stop any services before reboot if needed
- name: Pre-Reboot Scripts
debug:
msg: "Running Pre-Reboot scripts............."
- name: Reboot the machine (Wait for 5 min or 300 Sec)
reboot:
reboot_timeout: 300
test_command: uptime
when: package_update_status.changed
register: reboot_status
- name: Machine after reboot
debug:
msg: "{{ reboot_status }}"
- name: Update all installed packages for Debian and Ubuntu
when: ansible_distribution == "Debian" or ansible_distribution == "Ubuntu"
apt:
name: '*'
state: latest
update_cache: yes
force_apt_get: yes
register: package_update_status
- name: Show Update details
debug:
msg: "{{ package_update_status }}"
# Shutdown/stop any services before reboot if needed
- name: Pre-Reboot Scripts
debug:
msg: "Running Pre-Reboot scripts............."
- name: Reboot the machine (Wait for 5 min or 300 Sec)
reboot:
reboot_timeout: 300
test_command: uptime
when: package_update_status.changed
register: reboot_status
- name: Machine after reboot
debug:
msg: "{{ reboot_status }}"
- name: Update all installed packages for openSUSE Leap
when: ansible_distribution == "openSUSE Leap"
zypper:
name: '*'
state: latest
register: package_update_status
- name: Show Update details
debug:
msg: "{{ package_update_status }}"
# Shutdown/stop any services before reboot if needed
- name: Pre-Reboot Scripts
debug:
msg: "Running Pre-Reboot scripts............."
- name: Reboot the machine (Wait for 5 min or 300 Sec)
reboot:
reboot_timeout: 300
test_command: uptime
when: package_update_status.changed
register: reboot_status
- name: Machine after reboot
debug:
msg: "{{ reboot_status }}" |
But I found a bug, as the apt module was always reporting changed=1 thus those clients would reboot even if there was no update. Following this I tried and replaced LC_ALL=locale; by LC_ALL= 'C' in the following file: /usr/lib/python3.11/site-packages/ansible/modules/apt.py, which fixed the apt thing reporting changed=1 even if there was no update at all. Should I file a bug for this so we will get a patched future version in gentoo? I have setup my playbook following this yt vid btw just in case anyone is interested. So some of the sections are just placeholders which only print a message.
Next on my todo is:
- mailinfo
- maybe automatic creation of a backup or snapshot before the actual updates are executed. 
I am also looking for a way to just list/show updates without actually performing them ex. for critical servers. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3129
|
| Posted: Tue May 09, 2023 6:37 pm Post subject: |
|
|
Ansible does have a check (dry-run) mode which only prints what would have been done. It does actually run on the target. collects facts, runs tests, verifies state and reports tasks as ok, skipped or changed (or sometimes even failed), just like in a regular run but without applying any changes to the machine.
All standard modules support it and it can be added to your own, custom modules (and raw commands) if you care to do that. This does not guarantee that the whole role / playbook will run properly in check mode, since some tasks may implicitly depend on previous tasks actually changing state of the client in ways that ansible (the inventory management system) is not aware of.
Writing really good playbooks for complex tasks ain't easy. |
|
| Back to top |
|
|
|
Networking & Security
