this post was submitted on 13 Aug 2023
13 points (88.2% liked)

Meta

217 readers
7 users here now

Para discussões e dúvidas relacionadas com esta instância de Lemmy, bem como requisições de novas comunidades e promoções a moderador.

Requisições

Comunidades

Para efeitos de segurança, a livre criação de comunidades foi desativada, e como tal, é necessária a publicação de uma requisição nesta comunidade, caso alguém pretenda começar um novo espaço.
A publicação deve ter um título no formato Requisição de nova comunidade: <nome>, onde <nome> deverá ser substituído pelo nome da comunidade. O corpo deve conter uma justificação, explicando o porquê da requisição.

Por exemplo,

Requisição de nova comunidade: batatas

Gostava de ter um espaço dedicado à discussão e partilha de informação relacionada com os variadíssimos tubérculos que existem.
Moderadores

No caso das comunidades originais nas quais ainda só exista um administrador da instância como moderador, e no caso de alguma comunidade não ter nenhum responsável ativo, é possível requisitar a atribuição do cargo. Para tal, e de forma semelhante à secção anterior, deve ser feita uma publicação nesta comunidade com título e corpo adequados.

founded 2 years ago
MODERATORS
tmpod
13
[IMPORTANTE] Atualizações, correções e migração do servidor (self.meta)
submitted 10 months ago* (last edited 10 months ago) by tmpod to c/meta
10 comments fedilink hide all child comments
 

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

top 10 comments
sorted by: hot top controversial new old
[–] Generator 2 points 10 months ago (1 children)

Curiosidade, porquê o Ubuntu 20.04!? Era a melhor opção, ou preferência?

Não é o (LTS) mais recente, também nunca percebi o fascínio pelo Ubuntu, a não ser por alguma compatibilidade com algum software.

Corro Debian a vários anos, e nunca foi problema com compatibilidade, e também (agora) tem um ciclo de versões de dois em dois anos, sendo 'rock solid'.

Alpine só uso em docker, o mínimo possível para o trabalho que faz, parece-me uma boa escolha, 'footprint' pequeno, estável mas nem sempre tem os pacotes de software necessários, tendo que usar Debian para imagens do Docker.
Em 'bare metal' nunca foi coisa que usei.

[–] tmpod 3 points 10 months ago (1 children)

Porquê Ubuntu? Porque era o OS com o qual eu estava mais familiarizado para servidores. Arch parecia-me demasiado bleeding edge para servidor, e na altura eu ainda nunca tinha experimentado Alpine.

Porquê 20.04? Era o LTS mais recente na altura em que eu iniciei o servidor (em 2020!).

Agora, porquê Alpine? É focado em segurança, pequeno, é perfeito para um docker host (o problema de falta de pacotes é inexistente, apesar de eu não sequer partilhar da tua experiência), e tem uma boa cadência de atualizações. Sendo pequeno e simples, tb parte-se menos e é mais fácil arranjar cenas. Como o objetivo é correr contentores docker, não preciso de nada pipi no host OS, apenas algo que não se meta na frente :P

[–] Generator 2 points 10 months ago (1 children)

Arch em servidor só para dar dores de cabeça, constante atualização de software, pode criar problemas com as aplicações a correr, para não falar na segurança visto que usa as ultimas versões, nem sempre são as mais indicadas.

Já em desktop, uso já vários anos que perdi a conta (desde 2011 se não estou em erro), mas também estou constantemente a fazer pequenas alterações, já num servidor que se quer é instalar e esquecer.

[–] tmpod 1 points 10 months ago

Pois exatamente. Eu tb prefiro Arch em computadores pessoais, mas para servidores só me pareceu resultar em trabalhos desnecessários.

[–] wounn 2 points 10 months ago (1 children)

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 1 points 10 months ago (1 children)

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 1 points 10 months ago (1 children)

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 1 points 10 months 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.

[–] wiki 1 points 10 months ago (1 children)

Obrigado pelo update. Aproveito para dizer que ultimamente as coisas têm estado muito mais estáveis para mim :)

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.

Por curiosidade e para saber que tipo de bitaites mandar:

Qual é o objectivo de usares Object Storage? É para fazeres offload desse armazenamento para outro servidor, para teres crescimento elástico do armazenamento, both, outra coisa?

Faço a mesma pergunta em relação à CDN. Que tipo de coisas é que queres CDNizar, e porquê?

[–] tmpod 1 points 10 months ago

Aproveito para dizer que ultimamente as coisas têm estado muito mais estáveis para mim :)

Folgo em sabê-lo! Ump assinho de cada vez x)

Qual é o objectivo de usares Object Storage?

O grande objetivo é reduzir a complexidade de manutenção dos ficheiros multimédia. Vão ocupando block storage que, apesar de eu ter preços mais baratos que o normal, é mais caro que object storage e requer mais atenção da minha parte. Além disso, o meu sistema de backups, assente no borg, está a começar de fraquejar seriamente perante o volume astronómico de ficheiros existentes na diretoria do pict-rs. Cada backup está agora a demorar 1 hora ou mais, é ridículo. Outro fator é a distribuição dos ficheiros que, com object storage e CDN, consigo ter melhores tempos de resposta, especialmente para o Brasil, e reduzir a carga no servidor, melhorando o resto tb.

Faço a mesma pergunta em relação à CDN. Que tipo de coisas é que queres CDNizar, e porquê?

A ideia era colocar o CDN e uma camada de caching à frente dos vários recursos estáticos, como as cenas do pict-rs e frontends.

Fico curioso para ouvir os teus bitaites hehe