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

  • wounn@lemmy.pt
    2·
    1 year ago

    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 ;)

    • tmpod@lemmy.ptOPMPortuguês
      1·
      1 year ago

      Alpine para base OS parece-me violento. Exemplo: https://martinheinz.dev/blog/92

      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…

      R2 para Object Storage não seria uma opção mais barata?

      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!

      • wounn@lemmy.pt
        1·
        1 year ago

        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…

        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.

        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).

        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.

        • tmpod@lemmy.ptOPMPortuguês
          1·
          1 year ago

          Acho que o que é verdade neste artigo para docker também o é para o host OS

          Do artigo:

          Finally, this DNS issue does not manifest in Docker container. It can only happen in Kubernetes

          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.

          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.

          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.