Atualizações:
A migração está concluída! O servidor corre agora sobre o pequeno Alpine v3.18 :)
Boas!
Estou de volta com mais notícias :)
Desta vez trago atualizações, pequenas correções e um aviso importante!
Atualizações
Atualizaram-se todos os componentes para as suas respetivas versões mais recentes (a 12/08).
| Serviço | Versão |
|---|---|
| Servidor | lemmy v0.18.4 |
| Multimédia | pict-rs v0.4.2 |
| Base de dados | postgres v15.4 |
| Interface principal | lemmy-ui v0.18.4 |
| Voyager | voyager v1.8.0 |
| Alexandrite | alexandrite v0.7.0 |
| Mlmym | mlmym v0.0.27 |
| Métricas | netdata v1.42.0 |
Além disso, um novo documento de transparência financeira foi lançada (já há uns dias), relativo ao passado mês de julho, acessível aqui.
Correções
Melhorou-se e corrigiu-se a lógica de proxying, que incorretamente dirigia algum tráfego para os componentes internos errados. Assim, resolveu-se o problema dos símbolos em falta na interface Alexandrite.
Como sempre, para mais detalhes técnicos sobre estas alterações, deve-se consultar o repositório de deployment.
⚠️ Migração do servidor
De momento, todos os serviços correm num VPS (Virtual Private Server) com Ubuntu 20.04 LTS (kernel
5.4).
As atualizações (por vezes importantes) a certos componentes demoram bastante tempo a chegar, o
kernel está numa versão antiga (de 2019), carecendo de várias melhorias relevantes nas versões mais
recentes (especialmente 6+), e o Ubuntu tem muito "lixo" embutido, que só ocupa espaço e consome
recursos.
Assim, e tomando como exemplo outras plataformas, decidiu-se migrar os serviços para uma máquina com
Alpine Linux (atualmente v3.18), uma distribuição minimalista, focada em segurança e manutenção.
Esta máquina continuará a ser um VPS com as mesmas características (3 vCPU, 6GB RAM, 85GB SSD).
Está, também, a considerar-se migrar o armazenamento das imagens (do serviço pict-rs) para Object Storage, e colocar uma camada de caching/CDN em cima dos vários serviços expostos. A bunny.net parece ser a melhor oferta, e foi recomendada por várias pessoas com experiência na área. Essa rede de CDN tem nós em Portugal, porém o centro de armazenamento mais próximo é em Espanha. Isto significa que os dados de multimédia passariam a estar alojados fora de território nacional, porém, ainda servidos aos clientes pelo nosso servidor (o pict-rs ainda obriga a que todo o tráfego passe pelo serviço). Se se empregasse uma camada de caching/CDN, então algum tráfego (em particular, recursos estáticos como CSS e multimédia) poderia passar a ser servido maioritariamente pelos nós da bunny.net e não pelo nosso servidor.
Visto ser uma operação um tanto delicada e, para evitar perdas de dados (locais), vai-se desativar o
serviço durante a janela de manutenção. Espera-se não demorar mais que 3 horas, porém não damos
garantias.
Para mais informações e atualizações sobre o processo, devem consultar a página da manutenção: https://estado.lemmy.pt/maintenance/245046
Em caso de dúvida não hesitem em comentar e colocar questões, especialmente no que toca a esta migração!
Cumps,
~tmpod
Alpine para base OS parece-me violento. Exemplo: https://martinheinz.dev/blog/92
R2 para Object Storage não seria uma opção mais barata?
Tenho alguma experiência com o CDN da fastly e cloudflare. Se precisarem de alguma coisa apitem ;)
Tens mais alguma informação para fundamentar isso? O artigo que partilhaste fala em usar Alpine como base para imagens de Docker, e num contexto de Kubernetes. Os principais problemas levantados aí são cenas de DNS e ter que compilar coisas de raiz por usar musl em vez da mais popular glibc. Visto que o objetivo aqui é usar Alpine como host OS, nenhum destes problemas me parece ser relevante. Aliás, relativamente àqueles de usar Alpine como imagem base no Docker, confesso que nunca me deparei com nenhum...
Prefiro não usar Cloudflare. A BackBlaze é que tb tem bons preços, mas os datacenters deles são todos nos EUA, exceto um em Amesterdão. A bunny.net é uma empresa europeia e tem melhor distribuição geográfica, com vários centros na Europa e até um em São Paulo (interessante uma vez que temos bastantes utilizadores brasileiros tb).
Obrigado pelo feedback!
Não tenho qualquer experiencia em usa-lo como host. Acho que o que é verdade neste artigo para docker também o é para o host OS ou seja há diferenças para a grande maioria dos OS e isso pode ser um possível problema. O host também precisa de resolver DNS por exemplo.
Percebo! Não recomendo de todo a BackBlaze para S3 "rápido". Pela minha experiencia são extremamente lentos em comparação com a concorrência. A outra unica opção seria fazer selfhost e usar minio.
Do artigo:
Parece-me que é um problema específico ao ambiente de Kubernetes.
Conheço pessoas que usam Alpine como daily driver nos seus computadores pessoais e até plataformas que correm como host OS (por exemplo, o sourcehut), e nunca me apercebi destes problemas. Mas compreendo o que dizes.
Ui, não fazia ideia. Obrigado pelo aviso!
Quanto a self-hosting, pode ser uma opção tb, mas parece-me talvez mais prudente optar por um serviço externo, não? Menos uma coisa com que me tenho que preocupar, e assim posso focar-me nas partes mais cruciais do serviço.