Az openSUSE Leap által adott 3.6 verziójú Python szavatossága már rég lejárt, és bár a rendszer stabilan működik vele, bizonyos Python-appoknál gondot okoz a régi verzió. (Érdekes, hogy a Python-környezet állandó nagy változásai ellenére is töretlennek tűnik a nyelv népszerűsége.) Az Ansible Core repóbeli verziója 2.9, amely természetesen ezt az ősi Pythont használja, de alap esetben elég és jól működik.
Repóból elérhető a python311 és kapcsolt részei. Hogyan tudunk Python 3.11-et használó Ansible Core 2.16-ot (latest) futtatni, hogy kipróbáljunk olyan Ansible plugineket, amelyek igénylik az újabb verziókat?
VENV
Ehhez Python virtual environmentet hozunk létre, és pip által telepítjük az Ansible-t. Szokás szerint fish-ben dolgozunk, a venv aktiválása eltér bash-hez képest, de a Python ad hozzá fish-scriptet. A ~/dev/ansible/
mappa lesz az Ansible-projektjeink otthona.
$ mkdir ~/dev/ansible
$ cd ~/dev/ansible
$ python3.11 -m venv .venv
$ source .venv/bin/activate.fish
$(.venv) python3.11 -m pip install ansible
Az elvárt verziót, illetve elérési utat kell látnunk mind Ansible, mind Python esetén:
$(.venv) ansible --version
Hozzuk létre az Ansible felhasználói szintű konfigját: ~/.ansible.cfg
(egy újabb csomag, amely nem veszi figyelembe az $XDG_CONFIG_HOME-ot).
[defaults]
ansible_home = ~/.local/share/ansible/
collections_path = ~/dev/ansible/.collections/
[inventory]
enable_plugins = host_list, script, auto, yaml, ini, toml, hetzner.hcloud.hcloud
hcloud inventory
A fenti konfigban már felkészültünk a Hetzner Cloud dinamikus inventory-jának használatára. Mire való e plugin? Statikus IP-lista helyett lekérdezi a VPS-eink címét a Hetznertől.
Galaxyval telepíthető. A függőségeit kézzel kell telepíteni:
$(.venv) ansible-galaxy collection install hetzner.hcloud
$(.venv) python3.11 -m pip install -r .collections/ansible_collections/hetzner/hcloud/requirements.txt
Az előkészületek után hozzunk létre egy Ansible-projektet, amellyel kipróbáljuk az új környezetünket és az inventory plugint. Itt myproject a Hetzner Cloud projektünk neve, ehhez kell API tokent generálnunk (lásd itt).
$(.venv) mkdir debian-up
$(.venv) cd debian-up
$(.venv) nano hosts.myproject.hcloud.yml
A ~/dev/ansible/debian-up/hosts.myproject.hcloud.yml
tartalma:
---
plugin: hetzner.hcloud.hcloud
api_token: "abcdefg123456abcdefg123456"
Megnézhetjük a lekérdezett tartalmát:
$(.venv) ansible-inventory -i hosts.myproject.hcloud.yml --list
Egy olyan playbookkal tesztelünk, amely apt upgrade
-et futtat. A ~/dev/ansible/debian-up/upgrade.yml
tartalma:
---
- name: Upgrade Debian servers
hosts: all
gather_facts: yes
remote_user: myuser
become: true
tasks:
- name: Update apt-cache
apt: update_cache=yes force_apt_get=yes cache_valid_time=7200
- name: Upgrade all packages
apt: upgrade=dist force_apt_get=yes
- name: Check if a reboot is needed
register: reboot_required_file
stat: path=/var/run/reboot-required get_checksum=no
- name: Reboot
reboot:
connect_timeout: 5
reboot_timeout: 300
pre_reboot_delay: 0
post_reboot_delay: 30
test_command: uptime
when: reboot_required_file.stat.exists
Futtassuk a playbookot:
$(.venv) ansible-playbook -i hosts.myproject.hcloud.yml upgrade.yml
Playbook helyett futtathatunk ad hoc parancsokat is:
$(.venv) ansible -i hosts.hcloud.yml all -b -a "fail2ban-client status sshd"
Végezetül kiléphetünk a venv-ből (ez egy fish function, amely a fenti activate.fish
-ből származik):
$(.venv) deactivate
SSH port
A fentiekben leírt módszer akkor működik, ha minden VPS a 22-es porton szolgáltat SSH-t. Ha egységesen más a port, akkor a projektbeli ansible.cfg
-ben módosíthatunk.
[defaults]
remote_port = 2233
Ha a port VPS-enként különbözik, akkor az ~/.ssh/config
lehet segítségünkre.
Host mydomain.hu 123.123.123.111
Port 2233
Host 123.123.123.222
Port 2244