Eseguire Docker, CI/CD e oltre 10 servizi self-hosted su ZimaCube 2

Pipeline CI/CD

• Runner self-hosted GitHub Actions — costruisci e distribuisci container Docker direttamente nel mio ambiente locale
• Workflow di deployment automatizzati attivati a ogni push

Storage e dati

• Pool ZFS che coprono 3× HDD e 3× unità NVMe
• Workflow di backup locale con unità di backup dedicate
• Storage di media e dataset con supporto snapshot

Networking

• Doppia Ethernet 2.5Gb abbinata a router WiFi 7
• Routing tramite reverse proxy verso tutti i servizi
• Tunnel criptati per accesso remoto

8GB di RAM: la sorpresa inaspettata

Ecco la parte onesta: quando ho visto che la configurazione base includeva 8GB di DDR5, il mio primo istinto è stato ordinare subito un upgrade della RAM. Invece, ho deciso di testare fino a che punto la configurazione stock potesse arrivare realisticamente prima di spendere altri soldi.

I risultati mi hanno sorpreso.

Anche con oltre 10 container Docker — inclusi un reverse proxy, tunnel criptati, monitoraggio, runner CI/CD, hosting CMS e servizi di storage — il sistema non ha mai mostrato segni di rallentamento. L’uso della memoria è rimasto gestibile. I tempi di avvio dei container sono stati rapidi. La reattività dei servizi è rimasta eccellente.

Questo dice molto sia sull'efficienza dei moderni carichi di lavoro container Linux sia sull'architettura della piattaforma. I pool di archiviazione NVMe significano che lo swap è realmente utilizzabile quando necessario, e la larghezza di banda della memoria DDR5 mantiene l'I/O dei container reattivo.

Ho ancora in programma di espandere la memoria in futuro — soprattutto man mano che aggiungo più carichi di lavoro AI — ma l'esperienza di base è stata molto più performante di quanto mi aspettassi.

Docker CI/CD: COSTRUISCI → DISTRIBUISCI → AUTOMATIZZA → RIPETI

Uno degli usi più importanti per me è il CI/CD basato su Docker. Ecco come funziona il flusso di lavoro sullo ZimaCube 2:

1. Invio il codice su GitHub
2. Un runner GitHub Actions self-hosted sullo ZimaCube 2 prende in carico il lavoro
3. Il runner costruisce l'immagine Docker localmente
4. Il nuovo container viene distribuito nel mio ambiente self-hosted
5. Nginx Proxy Manager instrada il traffico verso il servizio aggiornato
6. Cloudflare Tunnel garantisce l'accessibilità da qualsiasi luogo

Questo è esattamente il tipo di flusso di lavoro per cui volevo questa macchina. Niente più compromessi tra un NAS per l'archiviazione, una macchina separata per il calcolo e un altro sistema per CI/CD.

Architettura di archiviazione che ha senso

Il design a doppio pool è ciò che rende possibile questo livello di consolidamento:

Il pool veloce è dove risiede Docker. Immagini dei container, volumi e dati di runtime sono tutti su NVMe RAID 1, il che significa che l'avvio dei container e le operazioni di I/O sono davvero veloci. Il pool bulk gestisce l'archiviazione a lungo termine — file multimediali, archivi e dataset che non necessitano della velocità NVMe.

Questa separazione significa che non devo mai scegliere tra capacità e prestazioni.

Prestazioni termiche sotto carico continuo

Una delle caratteristiche più impressionanti dello ZimaCube 2 è stata la prestazione termica. Anche durante l'esecuzione di container Docker, pool di archiviazione, proxy inversi, servizi di monitoraggio, infrastruttura CI/CD e applicazioni self-hosted, il sistema è rimasto sia silenzioso che fresco.

Il telaio in metallo, il design del flusso d’aria, i dissipatori NVMe inclusi e la disposizione interna dei componenti contribuiscono tutti a questo. Per un dispositivo infrastrutturale compatto sempre acceso, il profilo termico è davvero eccellente.

Rispetto ai vecchi server rack che usavo prima, la differenza in termini di calore prodotto, consumo energetico, rumore e ingombro fisico è abissale.

Networking: Dual 2.5GbE in pratica

Le porte Ethernet dual 2.5Gb si abbinano perfettamente all’infrastruttura di rete moderna. Abbinate a un router WiFi 7 e a uno switch 2.5GbE:

• Trasferimenti file veloci da e verso i pool di storage
• Networking container reattivo tra i servizi
• Accesso remoto fluido tramite Cloudflare Tunnel
• Nessun collo di bottiglia per carichi di lavoro simultanei

Per un dispositivo infrastrutturale compatto, la doppia 2.5GbE è molto importante — significa che l’accesso allo storage non è limitato da un singolo collegamento gigabit.

Costruisci la tua piattaforma self-hosted con ZimaCube 2 →

Domande Frequenti

D1. Quanti container Docker può eseguire il ZimaCube 2?

Con la configurazione stock da 8GB DDR5, Michael esegue più di 10 container tra cui proxy inverso, CMS, gestore password, monitoraggio, runner CI/CD e servizi di storage — con margine di riserva. Il pool di storage NVMe garantisce un I/O veloce dei container anche sotto carico simultaneo.

D2. Il ZimaCube 2 può eseguire runner GitHub Actions?

Sì. I runner GitHub Actions self-hosted funzionano bene sul ZimaCube 2. Michael li usa per costruire e distribuire container Docker direttamente nel suo ambiente locale self-hosted — una pipeline CI/CD completamente locale.

D3. 8GB di RAM sono sufficienti per un homelab Docker?

Per i carichi di lavoro containerizzati — Docker, proxy inversi, tunnel, monitoraggio e servizi di storage — 8GB sono sorprendentemente sufficienti. I container Linux moderni sono efficienti in termini di memoria, e lo storage NVMe fornisce uno swap veloce quando necessario. Puoi sempre aggiornare in seguito tramite lo slot SODIMM.

D4. Qual è il vantaggio di avere due pool di storage (HDD + NVMe)?

Il pool NVMe gestisce carichi di lavoro ad alta I/O come Docker, VM e archiviazione applicazioni con bassa latenza. Il pool HDD offre uno storage di massa economico per media, backup e dataset. Questa separazione significa che non devi mai sacrificare la capacità per le prestazioni.

D5. Il ZimaCube 2 supporta Cloudflare Tunnel?

Sì, e funziona bene. Combinato con Nginx Proxy Manager e la rete dual 2.5GbE, puoi esporre i tuoi servizi self-hosted in modo sicuro senza aprire porte sul router.