Há três semanas atrás decidi criar este portefólio/blog, no entanto, queria dar selfhost do mesmo.
Embora tenho ido por outra rota de modo a não expor o meu IP ao exterior o bichinho do selfhost permaneceu.
Aqui deixo a minha jornada até onde hoje estou.

Escolha do hardware

Tendo feito a minha decisão, faltava a plataforma onde pôr o meu plano em prática.

Limpeza de primavera

Inicialmente comecei por vasculhar e arrumar gavetas e armários para ver o que tinha por casa, chegando à conclusão que todos os computadores que tinha estavam num dos seguintes 3 estados :

• Avariados
• Atualmente a ser usados
• Mau estado ou Inutilizáveis

Na última categoria tinha um Magalhães ( Intel Classmate PC) de primeira geração, a correr Linux Mint, com o disco a dar as últimas, que ainda estou a ponderar como trocar, estando os parafusos todos rafados de em puto tentar abrir aquilo com facas e o que tinha à mão. Além dessa relíquia, outro incrível achado foi um portátil Toshiba que crasha aleatoriamente pelo que duvido que a 1h de uptime chega-se.

Com um pouco de trabalho talvez consegui-se utilizar um deles, no entanto falham dois requerimentos que tenho.

• Tecnologia de virtualização (Intel VT-x or AMD-V)
• Consumo razoável

O segundo ponto talvez conseguisse atingir com um pouco de configuração de C-STATES, se é que os suportam assim que o primeiro ponto falhou não me dei ao trabalho de verificar.

A importância do primeiro ponto deve-se ao facto que pretendia correr o meu website e outros serviços, que poderia posteriormente dar selfhost, em contentores.

Caça aos gambozinos

Ok, dando a busca local por computação adequada terminada, vi que tinha que gastar uns trocos se realmente quisesse prosseguir.

Fui desesperado procurar por maquinas Intel de quarta geração para cima. Os preços que encontrei rondavam os 60~70 €, sendo a maioria torres HP, Dell, Lenovo, Fujitso , etc . . . provavelmente com origens em contextos empresariais.

Embora seja um preço acessível iria-me ver às negras para posteriormente dar upgrade de qualquer coisa que fosse, devido a uma selva de suportes, guindastes e outros mecanismos proprietários de hardware ao software. Torres da Lenovo e da Fujitso pareciam-me mais aceitáveis, mas ainda assim não me apetecia arriscar.

Deixando-me com duas opções, elevar a busca a níveis absurdos comprando peças individuais e montando um sistema low cost do zero ou . . . um rasberry pi que no futuro podia utilizar em outros projetos.

A escolha óbvia foi um Rasberry PI. Qual deles é que foi um pouco mais complicado sendo que o Rasberry PI 4 8GB, nos mercados a que tenho acesso, estava ao mesmo preço do Rasberry PI 5 4GB. Um com mais memória, no entanto, menos poder de processamento e outras funcionalidades como velocidades USB 3.0 aumentadas e um PCIE slot, que depois poderei usar para um SSD. Tendo isto em conta, em vez de gastar 60~70€ numa destas duas opções acabei por investir mais 20€ e escolhi o Rasberry PI 5 8GB.

Arquitetura

Tive uma semana para pensar como ia preparar a cama ao bicho, no entanto, só o comecei a fazer depois de o mesmo ter chegado.

Tendo já dois domínios preparados, um para o meu website e outro para os meus serviços, comecei a trabalhar.

Génese do famoso homelab

Para começar, ignorei completamente o acesso ao exterior e simplesmente meti os contentores a correr.

Embora tudo quanto fosse tutorial indicasse-me a utilizar Docker, eu utilizei Podman porque gosto do projeto e vai dar ao mesmo.

Quando o Podman começou a aparecer na cena, a sua carta na manga eram os rootless containers (era porque agora o Docker também já suporta) e foi o que inicialmente ia usar, porém estes rootless containers não podem ser mantidos pela root (quem diria!!!), pelo que para que os containers fossem reiniciados pelo sistema e mantidos sem qualquer intervenção, teriam de ser rootfull. Eu descobri isto após uma horita a tentar perceber o porquê de os meus serviços só estarem disponíveis com uma sessão de SSH aberta . . .

Outra coisa que aprendi tendo sempre desenvolvendo software para x86 é que algumas imagens de Docker não têm versão ARM, ou exigem que seja utilizada uma tag a especificar que uma versão para ARM seja utilizada. Tudo bem até aqui, agora dava jeito era avisarem isso em vez de obter um erro genérico Failed Exec ou algo parecido.

Para reiniciar os container a maior parte dos artigos/posts online aconselham a adicionar uma flag restart-always, o Podman tem um serviço systemd chamado podman-restart que fornece esta funcionalidade, no entanto, decidi ignorar isto e optar por uma integração do systemd com containers denominada de quadlets ou docker/podman-systemd, que a partir de ficheiros de configuração, faz com que o systemd trate de dar pull das imagens e o estado dos relativos containers.

Depois de algum tempo a escolher as imagens certas, criar os volumes, fazer a transição de rootless para rootfull e outros problemas 2–3 dias tinha os contentores a bombar nas suas portas.

Networking

Ok, contentores a trabalhar e portas definidas, a única coisa que faltava era uma forma uniforme de aceder ao vários serviços dentro e fora da rede de casa.

Solução á Papo seco

Pus-me ao trabalho e defini um IP estático no router para o meu servidor. Passando de seguida adicionar um A record, com o IP publico do meu servidor, ao meu domínio e subdomínios.

Por razões de segurança e penso que devido à falta de IPs desde o início da internet normalmente as ISPs vão trocando os IP publicos de redes domésticas. Com isto, cada vez que esta mudança ocorre os A records ficam desatualizados.

Felizmente existem clientes DDNS (Dynamic DNS), que consistem em daemons, que a partir de serviços de descoberta de IP públicos em conjunto com as APIs das entidades do registo de domínios atualizam, dinamicamente, os dados de um dado domínio. No meu caso e penso que no caso da maior parte das pessoas, ddclient serviu para o problema.

Tendo ddclient acedi ao meu router e, além da porta de SSH (porta aleatória, não 22), abri as portas 80 e 443.

Nessas portas 80 e 443 pus um contentor a correr nginx proxy manager (aka NPM), e configurei os endereços e as portas a que correspondem. Neste processo aprendi que nunca mais vou utilizar localhost, passando a optar por 127.0.0.1 .

Pensei em dar por concluída a minha aventura aqui, apesar disso, a sensação de que qualquer pessoa podia aceder aos meus serviços (embora tivessem de saber a password para cada um deles) não me deixou dormir.

Solução relativamente segura

À medida que ia fazendo pesquisas de como melhorar o meu homelab e que serviços hospedar, havia sempre malta a aconselhar a utilizar uma VPN para aceder a rede local, e aí usufruir das várias aplicações no servidor.

Pelo que não fiz mais nada instalei wireguard, abri a porta no router e fiz configuração para rotear o tráfico da interface virtual do wireguard para a do servidor, isto reencaminhando qualquer pedido de algum nó wireguard, connectado ao meu nó no servidor, seja reencaminhado para a rede local.

A partir dai foi só alterar todos os subdomínios para o IP estático do servidor e fechar as portas SSH, http e https.

Sendo que com isto desde que esteja conectado ao wireguard consigo aceder a todos os meus serviços, em qualquer lugar.

Para facilitar adicionar novos dispositivos, estou a utilizar wireguard-ui (wg-ui). É fácil de usar, porém, é preciso adicionar uns serviços systemd e fazer as configurações na interface web, em vez de diretamente nos ficheiros de configuração.

Desenho da arquitetura

Para quem quiser replicar, fica aqui um guia visual, que também está no meu repositório juntamente com outras configurações.

Um passo mais perto de ser autossuficiente

Além de ter aprendido uma coisa ou outra e todos os benefícios de agora ter um homelab, um dos aspetos mais importantes que atingi com este processo todo foi tornar-me um bocadito mais autossuficiente.

Numa época onde ensh*tificantion ou m*rdificação se tornou a norma, ter algo local, privado e que temos, com certa, garantia, que não nos vais extorquir por mais dois 2 € para satisfazer acionistas, que esperam algo, tão estúpido, como crescimento contínuo, num mundo finito, penso que mais essencial, é necessário.

De qualquer forma fico apenas feliz por dizer, adeus cloud.