TP blog

Pano de fundo

2024-07-13T00:00:00Z

Um pouco atrasado com esta publicação, não porque tenho a disciplina de escrita de um puto de 5 anos, mas porque penso que agora seja altura perfeita para resumir esta minha aventura.

De qualquer forma, fica aqui a minha experiência ao criar e gerir este blog/portefólio.

O porquê disto tudo

Sempre gostei de ler/perder-me em blogs e publicações sobre aspetos técnicos relativos a nichos no desenvolvimento de software ou em tecnologia no geral.

Quando leio estes textos sagrados, uma vontade de fazer algo, seja estúpido, produtivo ou simplesmente inútil, cresce em mim, tendo inspirado vários projetos meus, mesmo que tenham, na sua maior parte, morrido na praia ou nunca visto a luz do dia.

No entanto, apesar da taxa de sucesso destes projetos, do trajeto, que escolho para cada um deles, costumo tirar algo interessante ou frutífero que depois acabo por revisitar.

Ao criar este meu cantinho da internet, dos frutos que vou tirando aqui ou ali, queria deixar uma semente, tal e qual como a que muitas vezes me faz levantar e como referi criar algo, assim contribuindo para este estranho ciclo.

Escolha de frameworks

Tendo decidido criar esta coletânea de paredes de texto que agora estão a ver, fui procurar as ferramentas para o fazer.

A minha experiência no desenvolvimento de web não é muita, mas existe e foi dai que parti.
Normalmente este tipo de blogs, são feitos com recurso a geradores de websites estáticos, que a partir de uma planta ou template pegam no seu conteúdo numa estrutura simples como markdown, latex ou até mesmo html e criam várias páginas.

No meu caso escolhi e uso markdown, pela sua simplicidade, nada de tags dentro de tags ou quer que seja que latex faça.

A minha experiência com este tipo de ferramentas, é baseada nas contribuições que fiz a algum tempo para o futuro (acho eu) website do meu grupo de Linux da universidade ( GLUA, se quiserem conhecer fica aí a ligação, essa malta é espetacular ). Ai utilizei Hugo, foi interessante e aprender uma sintaxe para templates como nunjucks foi útil, no entanto, achei muito a papinha da forma como o Hugo funciona á volta, e promove a utilização de temas.
Provavelmente poderia simplesmente ignorar todas essas indicações e fazer algo, como intendia, do zero, mas para isso, seria preciso ler atentamente a documentação, uma coisa que como sou estúpido não faço, e pôs-me á procura de alternativas.

Nessa minha pesquisa encontrei 11ty, e fiquei surpreendido o quão simples é, sem falar que é bastante rápido e por omissão oferece uma liberdade estupenda. Com isto, um toque de tailwind( nunca mais utilizo CSS puro ) e um ou dois plugins tinha tudo o que precisava e assim comecei a meter mãos á obra.

Desenho/Protótipo

Por muito que gostaria de dizer que sou um desenvolvedor responsável e tenho sempre reservada uma etapa para o planeamento e desenho daquilo que quero fazer, não, mergulho de cabeça e espero pelo melhor.
Aqui como muitas vezes acontece, mergulhei e bati com a cabeça. Depois de uma ou duas horas a fazer e refazer coisas aleatórias ou a olhar para uma cegante pagina em branco, percebi que se calhar era melhor tirar um tempito para realmente desenhar e estabelecer mais ou menos bases do que queria fazer.

A tela

Normalmente para websites simples utilizo, simplesmente, papel e caneta, porém, numa das minhas cadeiras na universidade utilizei figma e gostei da forma de como pouco ou nada tinha de pensar na localização dos componentes e seguir apenas a, meio que detalhada, planta.
Quando fui criar a minha conta, o nosso senhor, Richard Stallman, sussurrou-me ao ouvido e indicou-me penpot, que ao contrário do figma é FOSS (Software livre).

Do nada a algo

Neste ponto tinha o meu objétivo, as ferramentas e uma tela onde esboçar o dito cujo, mas não tinha se quer ideia do que fazer então procurei referencias onde me pudesse encostar.

Aqui estão algumas que gostei:

Desta pequena amostra, qualquer um poderia facilmente adivinhar que adoro sites minimalistas, paredes de textos vindas dos anos 90, e estariam absolutamente corretos.

Tendo estes como pilares comecei a construir o meu castelo.

A primeira coisa que fiz foi decidir a temática, e escolhi um tema arcaico, com uma estética e fontes que remetem a de um terminal. A partir daí, o resto simplesmente segui os meus instintos e fiz aquilo que gostaria de ver num blog.

Na escolha das cores, não vou mentir, copiei a palete nordica, não sei porquê, mas adoro este esquema de cores, faz me sentir confortável e com que os meus olhos deslizem como manteiga a ler.

Os únicos aspetos que acho que têm o seu mérito, se algum ..., são a navegação, onde decidi fazer da barra de navegação tapete e metê-la como um sticky footer, e o header com meu nome e email que acho que ficou engraçado.

Quando comecei a desenhar isto tudo, pensava que o resultado final ia ser completamente diferente, mas como podem ver esse não é o caso:

Não sei se isto diz alguma coisa sobre o lado artístico, ou quão má a minha criatividade é.

Mãos á obra !

Depois destes esboços feitos, deixei este projeto repousar durante um bom bocado, mas mesmo enferrujado com a ferramenta, 11ty, tailwind e outros, as plantas realmente permitiram-me avançar com o projeto.

Primeiro tentei navegar pelos projetos iniciais que o 11ty tinha na sua documentação, para projetos esqueleto na minha opinião tinham dependências a mais e desnecessárias, pelo que os descartei.
Eu apenas queria, como disse, usar tailwind e alguns plugins do 11ty nada de complicado.

Sem nada por me guiar fui então a ler a documentação e dar uso ao teclado

Honestamente, nem foi assim tão complicado, a documentação é relativamente fácil de compreender e avancei bastante rápido ( quem diria que a documentação ajuda ), tive de aprender um bocado de nunjucks e tentar perceber mais ou menos como tailwind funciona, mas outra vez, isso também não foi problema.

No 11ty tudo são templates, mesmo o próprio conteúdo, para processar um template noutro utilizamos filtros, e foi isso que essencialmente deu mais trabalho, criar ditos filtros na configuração, eleventy.js:


    eleventyConfig.addFilter('MarkdownFilter', function(content) {

	content = content.replace(/<p>/g, '<p class="mt-2 mb-4  [&:has(img)]:flex  [&:has(img)]:my-14  [&:has(img)]:md:h-96 [&:has(img)]:justify-center ">');
	content = content.replace(/<h1>/g, '<h1 class="font-extrabold md:text-8xl py-3 text-7xl underline ">');
	content = content.replace(/<h2>/g, '<h1 class="md:text-7xl text-6xl py-2 underline">');

    ...

Este filtro markdown pode ser aplicado nos templates desta forma :

<div class="text-xl md:text-2xl">
  { { content | MarkdownFilter | safe } }
</div>

E parecendo que não em um pouco mais que o uma semana tinha mais ou menos tudo pronto, só falta o mais difícil, o conteúdo.

Meter o blog no ar

Entre a fase de desenho e realmente meter mão á obra, referi que deixei o projeto repousar por um bocado, isto porque sou preguiçoso, estava ocupado com outras coisas, ou estava a construir e perceber como dar selfhost daquilo que preciso.

Nessa jornada de selfhost, aprendi que para realmente hospedar o meu website, teria de expor o endereço IP para o exterior ou utilizar um VPS com um reverse proxy redirecionando o trafico para o meu servidor.

Claro que não queria expor o meu IP então explorei a segunda opção e descobri algo . . . VPS são caras para caraças. De maneira alguma iria pagar 8€ mês, por um projeto que poderia hospedar em algo como netlify, domínio customizado, de graça.

Para esclarecer não estou a descartar o uso de uma VPS, mas para mim de momento não faz sentido, se ainda tivesse que hospedar algo mais no publico, como, por exemplo, serviços tipo pastebin ou algo colaborativo como mattermost ou alguma office suite, mas de momento não preciso.

Antes meter o anel no netlify, fui procurar por alternativas e houve uma que realmente me despertou o interesse, Surge.sh, nada de painéis de administração ou websites complicados, apenas uma cli e uns quantos comandos e tinhas o website no ar. Só não optei por esta alternativa porque o plano gratuito não suporta dominios customizados, no entanto caso precise de hospedar um website aleatório para um pequeno projeto estará no topo das minhas opções.

Um pouco desiludido, lá segui com netlify, criei uma conta, adicionei os meus domínios e meti no ar este website com a netlifly-cli.

TODOS e Conclusão

Ainda tenho uma outra coisa que quero ajustar e explorar, como o template de RSS que apesar de funcional está uma porcaria, reparar pequenos problemas que encontrar com o filtro de markdown e talvez organizar a configuração do 11ty.
Mas por agora está novo ! :D

Se disto tiro alguma coisa, é respeito por quem tem de escrever como profissão e que escrever é difícil, apesar de me estar a adequar aos poucos ao ofício.

Em suma, é bom ter este meu cantinho da internet, para me expressar e dar os meus bitaites, mesmo que dê algum trabalho.

Adeus cloud

2024-05-23T00:00:00Z

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.