this post was submitted on 13 Aug 2023

13 points (88.2% liked)

Meta

224 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

top 10 comments

sorted by: hot top controversial new old

[–] Generator 2 points 1 year 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 1 year 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 1 year 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 1 year ago

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

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

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