Meta

223 readers

1 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 3 years ago

MODERATORS

tmpod

[IMPORTANTE] Atualizações, correções e migração do servidor (self.meta)

submitted 1 year ago* (last edited 1 year 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

you are viewing a single comment's thread
view the rest of the comments

[–] tmpod 1 points 1 year 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 1 year 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 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.