Portainerist Ansible’ini: kuidas ma pääsesin homelabi hoolduskarussellist

Aastate jooksul olen jõudnud ühe üsna lihtsa, kuid väga olulise tõdemuseni: homelab on suurepärane koht uute tehnoloogiate ja avatud lähtekoodiga projektide katsetamiseks, kuid ilma selge plaani ja kodukorrata muutub selle haldamine ajapikku väga koormavaks.

Minu kodulabor oli pikka aega tüüpiline näide sellest, mis juhtub siis, kui iga uus projekt ehitatakse üles vastavalt hetkevajadusele.

Aastate jooksul tekkis keskkond, kus:

• osa LXC konteineritest jooksis Ubuntu peal
• osa Debiani peal
• osa Alpine Linuxi peal
• mitmes LXC konteineris jooksis korraga mitu teenust
• Docker hostide haldamiseks kasutasin Portainerit
• igasse Docker hosti oli paigaldatud Portainer Agent

Esialgu tundus see kõik mõistlik. Iga uus lahendus lahendas mingi konkreetse probleemi. Pikemas perspektiivis muutus aga hooldusprotsess väga keeruliseks.

😫 Kvartaalne hoolduspäev

Ühel hetkel oli mul kalendris kord kvartalis meeldetuletus:

"Kodulabori uuendused"

Ausalt öeldes ei olnud see sündmus, mida ootasin.

Tüüpiline hoolduspäev nägi välja umbes selline:

1. Uuenda Portaineri docker konteineri ennast.
2. Uuenda Portainer Agenti kõikides hostides.
3. Uuenda Docker containerid Portaineri kaudu.
4. Uuenda operatsioonisüsteemid.
5. Kontrolli, et midagi katki ei läinud.
6. Uuenda Proxmoxid.
7. Kontrolli backup'eid.
8. Kontrolli teenuseid.

Probleem seisnes selles, et iga host oli natuke erinev.

Debiani uuendamine käis ühtemoodi.

Alpine Linux teistmoodi.

Mõnes masinas jooksis üks teenus, mõnes kaks teenust korraga.

Iga hooldusring tähendas hulgaliselt käsitööd ning pidevat kontekstivahetust.

Mida suuremaks kodulabor kasvas, seda rohkem hakkas hooldus muutuma kohustuseks, mitte hobiks.

🔄 Standardiseerimine

Lõpuks sain aru, et probleem ei olnud tööriistades.

Probleem oli selles, et infrastruktuur ei olnud ühtne.

Alustasin järk-järgult keskkonna standardiseerimist.

Loobusin portainerist selleks et õppida selgeks mis moodi toimivad dockeri käsud.

Kõik Dockeris töötavad teenused kolisin eraldi LXC konteineritesse.

Kõigi uute konteinerite operatsioonisüsteemiks valisin Debian 13, kolisin kõik dockerid oma eraldiseisva LXC konteinerisse.

Iga teenus sai:

• oma LXC konteineri
• oma non-root kasutaja
• sudo õigused ainult vajadusel
• oma kodukataloogi
• oma Docker Compose stacki

Struktuur näeb välja järgmine:

/home/user1/jellyfin/
/home/user1/pihole/
/home/user1/uptime-kuma/

Teenuse kataloog sisaldab:

• docker-compose.yml faili
• konfiguratsiooni
• andmeid
• mount pointe

Lisaks paigaldasin igasse hosti lazydockeri.

Debianis lisasin ka shelli alias'e, mis võimaldab TUI kohe käivitada:

lazydocker

Kui on vaja logisid vaadata või mõnda containerit käsitsi kontrollida, on vajalik tööriist alati olemas.

🚀 Minu Ansible rollout kodulaboris

Kui infrastruktuur sai lõpuks standardiseeritud, oli Ansible kasutuselevõtt üllatavalt lihtne.

Minu puhul algas kõik ühest eraldi haldus-LXC konteinerist.

1. Haldusserver

Lõin eraldi Debian 13 LXC konteineri, mille ainus eesmärk on infrastruktuuri haldamine.

See tähendab, et kõik playbookid, inventuurifailid ja SSH võtmed asuvad ühes kohas.

2. Ansible paigaldamine

sudo apt update
sudo apt install ansible sshpass -y

Kuigi kasutan täna SSH võtmeid, on sshpass olnud kasulik esialgse seadistamise ajal.

3. SSH võtme genereerimine

ssh-keygen -t ed25519

Ed25519 on kiire, kaasaegne ja minu jaoks täiesti piisav kodulabori tarbeks.

4. Võtme kopeerimine hostidesse

ssh-copy-id ansible1@192.168.1.10
ssh-copy-id ansible1@192.168.1.11
ssh-copy-id ansible1@192.168.1.12

Pärast seda saab Ansible hostidesse sisse logida ilma parooli sisestamata.

5. Inventory faili loomine

Fail inventory.ini kirjeldab kogu infrastruktuuri.

[proxmox]
pve01 ansible_host=192.168.1.10
pve02 ansible_host=192.168.1.11

[lxc]
dns01 ansible_host=192.168.1.101
zabbix01 ansible_host=192.168.1.102
nginx01 ansible_host=192.168.1.103

[all:vars]
ansible_user=ansible1
ansible_become=true
ansible_become_method=sudo

Hostide grupeerimine võimaldab hiljem käivitada playbooke ainult konkreetsete süsteemide vastu.

6. Ühenduse kontroll

Enne playbookide käivitamist tasub kontrollida, et ühendused töötavad.

ansible all -i inventory.ini -m ping -K

Parameeter -K tähendab, et Ansible küsib sudo parooli privilegeeritud tegevuste jaoks. SSH ühendus toimub võtmega, kuid süsteemi uuendamiseks on siiski vaja SUDOt.

Kui kõik hostid vastavad edukalt:

SUCCESS => pong

on keskkond tööks valmis.

📚 Playbookid, mida täna kasutan

Debian süsteemide uuendamine

---
- name: Update Debian systems
  hosts: all
  become: yes

  tasks:

    - name: Update package cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Upgrade packages
      apt:
        upgrade: dist

    - name: Remove unused packages
      apt:
        autoremove: yes
        purge: yes

Reboot ainult vajadusel

---
- name: Reboot if required
  hosts: all
  become: yes

  tasks:

    - name: Check reboot-required file
      stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Reboot server
      reboot:
      when: reboot_required.stat.exists

Docker Compose stackide uuendamine

---
- name: Update per-host Docker Compose stacks
  hosts: docker_hosts
  become: yes

  tasks:

    - name: Pull latest images
      community.docker.docker_compose_v2:
        project_src: "{{ stack_path }}"
        pull: always

    - name: Recreate containers if needed
      community.docker.docker_compose_v2:
        project_src: "{{ stack_path }}"
        state: present
        recreate: auto

    - name: Remove unused images
      community.docker.docker_prune:
        images: yes

🧪 Igapäevased käsud

Kõikide Debian hostide uuendamine

ansible-playbook -i inventory.ini update.yml -K

Ühe konkreetse hosti uuendamine

ansible-playbook -i inventory.ini update.yml --limit netbird -K

Kasulik siis, kui soovin esmalt testida uuendust ühe teenuse peal.

Vajadusel reboot

ansible-playbook -i inventory.ini reboot.yml -K

Taaskäivitab ainult need süsteemid, mis seda tegelikult vajavad.

Docker stackide uuendamine

ansible-playbook -i inventory.ini docker-update.yml --limit docker_hosts -K

Tõmbab uued image'id, uuendab compose stackid ning eemaldab kasutamata Docker image'id.

⏱️ Tulemus

Kõige suurem võit ei ole olnud tehnoloogiline.

Kõige suurem võit on olnud aeg.

Dockerite uuendamine.

Operatsioonisüsteemide uuendamine.

Proxmoxi uuendamine.

Teenuste kontrollimine.

Kokku võis sellele kuluda 60min.

Täna võtab sama töö tavaliselt umbes 15–20 minutit.

Suurem osa tegevustest on automatiseeritud.

Hostid on standardiseeritud.

Teenused on ennustatavad.

Ja kõige olulisem - kodulabor on jälle koht, kus saab uusi asju õppida ja katsetada, mitte keskkond, mille hooldamine muutub omaette projektiks.