Executar Docker, CI/CD e mais de 10 Serviços Auto-Hospedados no ZimaCube 2

Pipeline CI/CD

• Runners auto-hospedados do GitHub Actions — construir e implantar containers Docker diretamente no meu ambiente local
• Fluxos de trabalho de implantação automatizados acionados a cada push

Armazenamento e Dados

• Pools ZFS abrangendo 3× HDDs e 3× unidades NVMe
• Fluxos de trabalho de backup local com discos de backup dedicados
• Armazenamento de media e conjuntos de dados com suporte a snapshots

Rede

• Ethernet dupla de 2,5Gb emparelhada com router WiFi 7
• Roteamento por proxy reverso para todos os serviços
• Túneis encriptados para acesso remoto

8GB de RAM: O Desempenho Surpreendente

Aqui está a parte honesta: quando vi que a configuração de origem vinha com 8GB DDR5, o meu primeiro instinto foi encomendar imediatamente uma atualização de RAM. Em vez disso, decidi testar até onde a configuração de origem poderia ir realisticamente antes de gastar mais dinheiro.

Os resultados surpreenderam-me.

Mesmo com mais de 10 containers Docker — incluindo um proxy reverso, túneis encriptados, monitorização, runners CI/CD, alojamento CMS e serviços de armazenamento — o sistema nunca pareceu limitado. O uso de memória manteve-se gerível. Os tempos de arranque dos containers foram rápidos. A resposta dos serviços manteve-se excelente.

Isto diz muito sobre a eficiência das cargas de trabalho modernas de contentores Linux e a arquitetura da plataforma. Os pools de armazenamento NVMe significam que o swap é realmente utilizável quando necessário, e a largura de banda da memória DDR5 mantém o I/O dos contentores ágil.

Ainda planeio expandir a memória mais tarde — especialmente à medida que adiciono mais cargas de trabalho de IA — mas a experiência de base foi muito mais capaz do que esperava.

Docker CI/CD: CONSTRUIR → IMPLANTAR → AUTOMATIZAR → REPETIR

Um dos casos de uso mais importantes para mim é o CI/CD baseado em Docker. Aqui está como o fluxo de trabalho funciona no ZimaCube 2:

1. Eu envio código para o GitHub
2. Um runner GitHub Actions auto-hospedado no ZimaCube 2 apanha o trabalho
3. O runner constrói a imagem Docker localmente
4. O novo contentor é implantado no meu ambiente auto-hospedado
5. Nginx Proxy Manager encaminha o tráfego para o serviço atualizado
6. O Cloudflare Tunnel garante que é acessível a partir de qualquer lugar

Este é exatamente o tipo de fluxo de trabalho para o qual queria esta máquina. Sem mais andar a alternar entre um NAS para armazenamento, uma caixa separada para computação e ainda outro sistema para CI/CD.

Arquitetura de Armazenamento Que Faz Sentido

O design de pool duplo é o que torna este nível de consolidação possível:

O pool rápido é onde o Docker vive. Imagens de contentores, volumes e dados em tempo de execução estão todos em NVMe RAID 1, o que significa que a inicialização dos contentores e as operações de I/O são realmente rápidas. O pool bulk trata do armazenamento de longo prazo — ficheiros multimédia, arquivos e conjuntos de dados que não precisam da velocidade NVMe.

Esta separação significa que nunca tenho de escolher entre capacidade e desempenho.

Desempenho Térmico Sob Carga Contínua

Uma das partes mais impressionantes do ZimaCube 2 tem sido o desempenho térmico. Mesmo a correr contentores Docker, pools de armazenamento, proxies reversos, serviços de monitorização, infraestrutura CI/CD e aplicações auto-hospedadas, o sistema manteve-se silencioso e fresco.

O chassis metálico, o design do fluxo de ar, os dissipadores NVMe incluídos e a disposição interna dos componentes contribuem para isto. Para um dispositivo compacto sempre ligado, o envelope térmico é realmente excelente.

Comparado com os servidores de rack antigos que usava anteriormente, a diferença em calor gerado, consumo de energia, ruído e espaço físico é enorme.

Rede: Dual 2.5GbE na prática

As portas Ethernet dual 2.5Gb combinam na perfeição com infraestruturas de rede modernas. Emparelhadas com um router WiFi 7 e um switch 2.5GbE:

• Transferências rápidas de ficheiros para e a partir dos pools de armazenamento
• Rede de containers responsiva entre serviços
• Acesso remoto fluido através do Cloudflare Tunnel
• Sem gargalos para cargas de trabalho concorrentes

Para um dispositivo de infraestrutura compacto, o dual 2.5GbE é muito importante — significa que o acesso ao armazenamento não fica limitado a uma única ligação gigabit.

Construa a sua própria plataforma self-hosted com o ZimaCube 2 →

Perguntas Frequentes

P1. Quantos containers Docker pode correr o ZimaCube 2?

Com a configuração padrão de 8GB DDR5, o Michael executa mais de 10 containers incluindo proxy reverso, CMS, gestor de passwords, monitorização, runners CI/CD e serviços de armazenamento — com margem de sobra. O pool de armazenamento NVMe garante I/O rápido para containers mesmo sob carga concorrente.

P2. O ZimaCube 2 pode correr runners do GitHub Actions?

Sim. Os runners self-hosted do GitHub Actions funcionam bem no ZimaCube 2. O Michael usa-os para construir e implantar containers Docker diretamente no seu ambiente local self-hosted — uma pipeline CI/CD totalmente local.

P3. 8GB de RAM são suficientes para um homelab Docker?

Para cargas de trabalho em containers — Docker, proxies reversos, túneis, monitorização e serviços de armazenamento — 8GB chegam surpreendentemente longe. Os containers Linux modernos são eficientes em memória, e o armazenamento NVMe fornece swap rápido quando necessário. Pode sempre fazer upgrade mais tarde através do slot SODIMM.

P4. Qual é a vantagem de ter dois pools de armazenamento (HDD + NVMe)?

O pool NVMe lida com cargas de trabalho de alto I/O como Docker, VMs e armazenamento de aplicações com baixa latência. O pool HDD oferece armazenamento em massa económico para media, backups e conjuntos de dados. Esta separação significa que nunca sacrifica capacidade por desempenho.

P5. O ZimaCube 2 suporta Cloudflare Tunnel?

Sim, e funciona bem. Combinado com o Nginx Proxy Manager e rede dual 2.5GbE, pode expor os seus serviços self-hosted de forma segura sem abrir portas no seu router.