Simone/local-ci-cd-system
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
081f7e1d16a44de3d98dfc91143c19ec63f4d787
local-ci-cd-system/plans/idea-2-linux-host.md
T

14 KiB
Raw Blame History

Idea 2 — Adattare il sistema a girare su host Linux (Mint)

Stato: proposta / valutazione. Target host: Linux Mint (kernel ≥ 6.x, su hardware compatibile con virtualizzazione hardware; KVM/Intel VT-x presenti su i9-10900X).

1. Obiettivo

Spostare l'host CI/CD da Windows 11 + VMware Workstation Pro a Linux Mint, mantenendo:

  • act_runner / Gitea (identici, già cross-platform — act_runner ha build Linux)
  • workflow YAML invariati
  • template VM Windows e Linux operative come build target
  • artifact layout su filesystem locale

Cambia: hypervisor, transport layer di management, percorsi, eseguibili amministrativi, gestione credenziali.

2. Fattibilità

2.1 Bivio strategico: quale hypervisor su Linux?

Opzione Pro Contro Verdetto
A. VMware Workstation Pro Linux Comando vmrun identico (binario /usr/bin/vmrun, senza estensione .exe); VMX dei template riutilizzabili 1:1 (zero conversione); guest tools invariati; dal 2024 free per uso personale e commerciale (Broadcom). Roadmap di lungo periodo incerta dopo acquisizione Broadcom; dipendenza da binari proprietari su un OS open source. Richiede aggiornare i default hardcoded del wrapper Resolve-VmrunPath (C:\Program Files (x86)\...\vmrun.exe → /usr/bin/vmrun). Path a basso attrito se si vuole minimizzare il rischio di porting (zero conversione template, zero rewrite di _Common.psm1 oltre al path).
B. KVM + libvirt + QEMU Open source, supportato nativamente da Linux Mint; tooling solido (virsh, virt-install, virt-clone); cloud-init friendly. Conversione VMDK→qcow2 obbligatoria (qemu-img convert); riconfigurare guest Windows (driver virtio); riscrivere completamente lo strato vmrun. Raccomandata per il lungo periodo.
C. VirtualBox Cross-platform, simile a Workstation. Performance inferiore a KVM; snapshot meno robusti; meno usato in CI. Sconsigliata.
D. Proxmox VE UI di management, API REST. È un OS dedicato, non gira "sopra" Linux Mint. Vedi Idea 3 (è simile a ESXi).

Le sezioni seguenti assumono Opzione B (KVM) salvo dove indicato — è lo scenario di porting più impegnativo e quindi quello da pianificare in dettaglio. Se si sceglie A (Workstation Pro su Linux), la maggior parte del tooling resta invariato: cambiano solo path (F:\CI\ → /var/lib/ci/), service manager (Windows Service → systemd), credential store e shell (PS 5.1 → pwsh 7 o Python — vedi Idea 1).

2.2 Mappa di adattamento (assumendo Idea 1 già completata o in corso)

Componente attuale Equivalente Linux + KVM
vmrun clone -snapshot=BaseClean ... linked virsh snapshot-create + virt-clone --reflink (qcow2 CoW)
vmrun start <vmx> virsh start <domain>
vmrun stop <vmx> hard virsh destroy <domain>
vmrun deleteVM virsh undefine <domain> --remove-all-storage
File .vmx Domain XML libvirt (definizione VM)
WinBuild2025.vmdk winbuild2025.qcow2 (base) + overlay qcow2 per ogni clone
F:\CI\BuildVMs\ /var/lib/ci/build-vms/ (o pool storage libvirt dedicato)
F:\CI\Artifacts\ /var/lib/ci/artifacts/
F:\CI\Templates\ /var/lib/ci/templates/
F:\CI\keys\ci_linux /etc/ci/keys/ci_linux (perms 600, owner ci-runner)
Credential Manager BuildVMGuest secret-tool (libsecret/GNOME Keyring) o file .env cifrato (age/sops)
WinRM HTTPS verso guest Windows Identico (lato guest non cambia nulla)
SSH verso guest Linux Identico
act_runner come Windows Service systemd unit act-runner.service
Task Scheduler (Register-CIScheduledTasks.ps1) systemd timers (*.timer + *.service)
PowerShell 5.1 PowerShell 7 (pwsh) o Python (vedi Idea 1)
vmnet8 (NAT 192.168.79.0/24) default libvirt network (NAT 192.168.122.0/24) o bridge dedicato

2.3 Conversione dei template VM (lavoro una-tantum)

Template Windows (WinBuild2025/2022)

  1. Spegnere VM su Workstation, esportare .vmx + .vmdk.
  2. Convertire: qemu-img convert -O qcow2 WinBuild2025.vmdk winbuild2025.qcow2.
  3. Iniettare driver virtio (network, storage) nel guest Windows prima della conversione (offline injection via virt-v2v oppure boot manuale con ISO virtio-win.iso e installazione driver).
  4. Importare con virt-install --import --disk path=winbuild2025.qcow2,bus=virtio --os-variant=win2k25.
  5. Validare WinRM accessibile da host Linux (Test-WSMan equivalente con pwsh o pypsrp).
  6. Spegnere, creare snapshot di base: virsh snapshot-create-as winbuild2025-template BaseClean.

Template Linux (LinuxBuild2404)

  1. Esportare e convertire VMDK → qcow2 (più semplice, driver virtio già presenti).
  2. Importare con virt-install --import ....
  3. Già usa SSH + chiave: nessun cambio lato transport.
  4. Snapshot BaseClean-Linux.

Linked clone su KVM

  • qemu-img create -f qcow2 -b /var/lib/ci/templates/winbuild2025.qcow2 -F qcow2 /var/lib/ci/build-vms/<jobid>.qcow2
  • Crea overlay CoW (equivalente di linked clone Workstation).
  • Performance migliore se il filesystem è XFS con reflink=1 o BTRFS.

2.4 Permessi e utenti

  • Utente di servizio ci-runner (uid dedicato), membro di libvirt e kvm.
  • act_runner gira come ci-runner via systemd (User=ci-runner).
  • Sudoers limitati per operazioni privilegiate (es. virsh net-start).
  • Storage pool libvirt con ownership corretta (/var/lib/ci).

2.5 Networking

  • Bridge br0 se serve raggiungibilità diretta dei guest dal host Gitea remoto, oppure NAT (default libvirt) + DHCP statico via libvirt dnsmasq se Gitea sta sulla stessa LAN.
  • Replicare la convenzione "1 IP per job concorrente" già in uso.

2.6 Rischi specifici

Rischio Severità Mitigazione
Guest Windows non parte dopo conversione (driver virtio mancanti) Alta Iniezione driver prima della conversione, oppure boot in safe mode + install.
Performance I/O dei clone qcow2 inferiore a VMware linked clone in alcuni scenari Media Filesystem CoW (BTRFS / XFS reflink) + cache=none + aio=native su disco.
vmrun workflow / convenzioni codificate in AGENTS.md errori #9 #10 non più applicabili Bassa Documentare nuovo set di "errori frequenti KVM" (es. virtio drivers, SELinux).
Linux Mint kernel non sempre allineato al supporto VMware Workstation se si sceglie A Media Solo se si va opzione A: vincolarsi a kernel LTS testato.
Burn-in concorrente saturazione I/O diversa su qcow2 vs VMDK Media Ripetere Test-CapacityBurnIn su nuovo host prima del go-live.
WinRM HTTPS da host Linux verso guest Windows ha cipher mismatch occasionali Bassa Usare pypsrp con auth='credssp' o auth='negotiate'; testato in lab.
Conversione VMDK + sysprep del Windows template può rompere attivazione / licenza Media Validare licenza Windows e tooling unattended con la nuova HW signature.

2.7 Vincoli che spariscono / che restano

Spariscono:

  • Limitazioni PS 5.1 (AGENTS.md tabella PS7+) — su Linux si usa pwsh 7 o Python.
  • Necessità di Credential Manager con bug noti sotto SYSTEM account.
  • autounattend.xml solo per refresh del template Windows (operazione rara).
  • Errori #9 (snapshot con .vmem) e #10 (getGuestIPAddress bloccante) sono specifici di vmrun — non più applicabili.

Restano / si trasformano:

  • Necessità di gestire snapshot in stato "powered off".
  • IP collision per machine-id identico nei clone Linux (#11): identico comportamento sotto KVM con dnsmasq DHCP.
  • Errore #12 (stderr nativa + $ErrorActionPreference='Stop') sparisce se si esce da PowerShell, altrimenti resta.

3. Stima volumi / sforzo (relativa)

Area Indicatori dimensione Complessità
Conversione template Windows → qcow2 + virtio 2 VM (2025, 2022) Alta
Conversione template Linux → qcow2 1 VM Bassa
Riscrittura _Common.psm1 → wrapper virsh/libvirt ~300 righe Media
Riscrittura _Transport.psm1 (WinRM) ~240 righe Bassa
Adattamento New-BuildVM / Remove-BuildVM / Invoke-CIJob ~2.000 righe Media
Riscrittura Setup-Host.ps1 → script bash + systemd ~400 righe Media
Register-CIScheduledTasks.ps1 → systemd .timer units 6 task → 6 timer Bassa
Adattamento workflow YAML (path Windows → POSIX) 5 file Bassa
Documentazione (HOST-SETUP.md, AGENTS.md, BEST-PRACTICES.md) ~5 file md Media
Validazione e2e: smoke + section 3.3 + capacity burn-in piano test esistente Alta

Sequenza obbligata:

  1. Decidere hypervisor (A vs B).
  2. Convertire template Linux (più semplice, fa da PoC).
  3. Convertire un template Windows e validare WinRM da Linux.
  4. Riscrittura tooling (idealmente in Python — vedi Idea 1).
  5. Migrazione storage F:\CI\ → /var/lib/ci/.
  6. Switch act_runner.

4. Pro / Contro

Pro

  • Elimina i vincoli PS 5.1 (tabella in AGENTS.md).
  • Stack open source completo (no licenze VMware Workstation se si va KVM).
  • systemd + journalctl per service management e log centralizzati.
  • Filesystem CoW (BTRFS/XFS reflink) → clone disco ~istantanei, equivalente o migliore di linked clone Workstation.
  • Linux Mint ha buon supporto desktop per debug interattivo del runner.
  • Disaccoppia dal futuro incerto di VMware Workstation (Broadcom).

Contro

  • Migrazione "tutta o niente" del host: non si può avere CI/CD attivo su Win e su Linux in parallelo se il template/storage layout è condiviso.
  • Conversione template Windows è il passaggio più rischioso (virtio, attivazione, eventuale re-provisioning toolchain).
  • Curva di apprendimento libvirt / virsh / domain XML.
  • Tutta la documentazione e AGENTS.md da riscrivere.
  • Test plan completo da rieseguire (smoke, e2e, burn-in).

5. Sinergia con altre idee

  • Idea 1 (Python): forte prerequisito. PS 7 su Linux è possibile, ma Python è più idiomatico per libvirt (binding libvirt-python) e per riusare paramiko / pypsrp cross-platform.
  • Idea 3 (ESXi): parzialmente alternativa. Se si va su ESXi, l'host CI resta comunque una macchina di management (può essere Linux Mint con Python + pyVmomi, oppure restare Windows). Il "dove gira l'host" e "dove girano le VM" si disaccoppiano.

6. Decision checklist

Procedere solo se almeno 2 dei seguenti sono veri:

  • Il vincolo Windows host è un problema concreto (licenze, policy aziendale, preferenza team).
  • Si è disposti a investire una settimana piena di test di conversione VMDK→qcow2.
  • Si è già completata (o si è disposti a fare in parallelo) l'Idea 1.
  • Si vuole rimuovere la dipendenza commerciale da VMware Workstation.

7. Path alternativo "minimo": dual-host

Se non si vuole migrare ma solo "supportare anche Linux Mint", una via meno invasiva:

  • Mantenere host Windows come primario.
  • Aggiungere un secondo runner Linux Mint che usa solo linux-build jobs (KVM o Workstation Linux), label linux-build:host-mint.
  • Workflow esistenti restano invariati; nuovi workflow possono selezionare il runner secondario per test sperimentali.
  • Stima: ~1/3 dello sforzo della migrazione completa, ma codebase divisa in due (PS Win + qualche script Linux ad hoc) — debito tecnico crescente.

Questa via ha senso solo come PoC temporaneo prima di una migrazione completa.

Reference in New Issue View Git Blame Copy Permalink