Administrador do Discourse auto-hospedado há 10 anos pergunta: por que não limpeza do launcher como parte da reconstrução?

Instalação
1

Olá a todos. Meu nome é Lee e eu hospedo o Discourse por conta própria intermitentemente desde 2013. Lembro-me de ter que me virar com o rbenv para sequer começar. Lembro-me de ter que compilar o nginx com Phusion Passenger para fazer as coisas funcionarem. Lembro-me de discutir com o @sam provavelmente dez anos atrás que mudar para Docker era ceder à fraqueza do desenvolvedor “funciona no meu diretório inicial e no meu pesadelo de dotfiles” (e estar completamente errado!). Lembro-me da primeira vez que ouvi a frase “bike-shedding”. Para citar o homem, eu lembro de tudo.

Depois de estar ausente por vários anos, tive a ocasião de voltar a hospedar o Discourse por conta própria como substituto para comentários nativos do WordPress em um site de meteorologia da área de Houston que normalmente tem cerca de 10 mil PV/dia, mas durante furacões, pode ter cerca de 2 milhões de PV/dia para cerca de 1 milhão de visitantes únicos. Lutamos com os comentários nativos do WordPress por anos, mas a partir da última quarta-feira, estamos no ar com o Discourse auto-hospedado. (E em Graviton3, nada menos! Sério, simplesmente funciona e é ótimo.)

Aqui está o ponto que estou chegando: é 2025, e como um auto-hospedeiro, ainda estou lidando com o gerenciamento manual do meu espaço de imagem docker. Apresento uma história sobre /dev/root, contada em trechos de código, após menos de uma semana em produção:

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G   21G  9.6G  69% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G   21G  9.6G  69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[um monte de linhas redigidas]

....
Total reclaimed space: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G  6.9G   24G  23% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G  6.9G   24G  23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #

Eu amo vocês. Eu amo o Discourse. Estou casado com o produto e pretendo continuar usando-o mais ou menos para sempre.

Mas, tipo… só, por quê. Por que é 2025 e eu, pessoalmente, por minha própria conta, ainda estou me virando com launcher cleanup? Por que o gerenciamento de imagens não é uma função inerente do launcher?

Novamente, eu amo vocês. Escolhi o Discourse para o SCW porque acredito no que vocês construíram e adoro usá-lo. Mas tipo… metade do volume de boot da minha pobre AMI está ocupada com lixo inútil que poderia — pelo menos se eu entender o lado técnico das coisas — ser gerenciado automaticamente.

Não quero reclamar — apenas estou voltando depois de alguns anos longe da cadeira de administrador. Eu amo a detecção de spam por IA e a triagem por IA, especialmente em um fórum de meteorologia onde posts politicamente carregados sobre mudanças climáticas (a favor ou contra) são uma característica regular. Obrigado por tudo <3

7 curtidas
2

Ótimo te ver de volta, Lee!

Aconteceu a mesma coisa no meu site auto-hospedado esta semana. Os backups estavam falhando e eu deixei isso passar por uma semana ou mais porque estava fora e não tinha acesso ao meu laptop. Assim que voltei, executei a limpeza e recuperei muito espaço em disco, e os backups puderam ser executados novamente.

4 curtidas
3

Olá, que bom te ver por aqui novamente!

Parte disso é que tem sido “bom o suficiente” - nós não o usamos internamente em nosso hospedagem, pois rotacionamos frequentemente contêineres e imagens, então nossa cadência é muito diferente do que um site auto-hospedado pareceria.

A outra explicação aqui é que, entre o launcher e o docker, nenhum sistema quer assumir total responsabilidade pelo cronograma de remoção de dados - o cronograma para excluir dados do usuário deve estar sob o controle total do usuário.

Eu encontrei alguns problemas em sites auto-hospedados onde a limpeza também limpa a nova base do discourse que eu precisava construir, levando a um terrível problema de ovo/galinha. Não ter isso notado por ser executado automaticamente provavelmente seria um obstáculo para tentar descobrir.

Uma sugestão simples aqui poderia talvez ser agendar um docker system prune ou launcher clean por sua conta e risco. Poderia funcionar?

6 curtidas
4

Porque às vezes ele pode excluir o único contêiner que você tem funcionando.
Você poderia simplesmente executá-lo toda vez antes de executar uma reconstrução, enquanto todos os seus contêineres em funcionamento ainda estão rodando.

1 curtida
5

Boa ideia — às vezes as respostas simples são as melhores. Obrigado, e assim o farei!

6

Como posso/podemos responder sim ao executar ./launcer cleanup via cron? Quero dizer, para mim, contêineres não são um grande problema, mas imagens órfãs são.

1 curtida
7

Não há razão para fazer isso com cron, você cria novas imagens apenas quando cria uma com launcher. Você só precisa fazer isso antes ou depois de criar uma imagem.

Se você quiser evitar os prompts do launcher, pode fazer isso com os comandos docker, como sugerido acima. Aqui está um (mas leia o manual para saber o que ele faz, para ter certeza de que é o que você quer):

/usr/bin/docker image prune -a -f
1 curtida
8

Tenho que conferir isso. Obrigado.

Não sei mais nada, mas hoje, novamente, a reconstrução falhou porque eu tinha menos de 5 GB de espaço livre. Claro, cleanup fez o trabalho, e isso não foi nada além de um pouco irritante. E ainda assim, eu gostaria de não ver tais situações.

E aqui mostra o quão pouco eu entendo como o docker funciona :joy: Se eu entendi direito aquelas imagens, que foram destruídas porque não eram usadas por nenhum contêiner, não eram imagens no sentido de figuras como eu sempre pensei :face_with_peeking_eye: :rofl:

2 curtidas
9

A resposta direta é que você poderia usar echo y | launcher cleanup para enviar “y” antecipadamente.

A resposta indireta é que a limpeza real do launcher (depois que é equivalente) é feita com estes dois comandos:

docker container prune --force --filter until=24h
docker image prune --all --force --filter until=24h

e o prompt ao qual acho que você está se referindo é para remover diretórios antigos de dados do postgres:

rm -rf /var/discourse/shared/standalone/postgres_data_old*

Você poderia remover a dependência do launcher e usar esses comandos diretamente.

2 curtidas
10

Na verdade, estou me referindo às perguntas que recebi ao executar ./launcher cleanup. Primeiro, ele remove todos os contêineres que estão parados. Em seguida, oferece a exclusão de todas as imagens que não são usadas por pelo menos um contêiner — e essa parte é a que libera espaço para mim, perto de 40 GB da última vez.

É por isso que fiquei bastante confuso, pois não conseguia entender por que tinha tantas imagens órfãs (jpg, png etc.). Mas estamos falando aqui de imagens totalmente diferentes, certo?

Sim, eu faço reconstruções pelo menos duas vezes por semana. Ou, mais recentemente, quando estava caçando um plugin de mau comportamento, fiz pelo menos uma dúzia de reconstruções.

Se ele fará uma nova imagem toda vez, eu não sei.

11

Cada reconstrução é uma nova imagem - portanto, elas se acumulariam se não fossem limpas.

O Launcher atualmente só solicita a limpeza ao executar outros comandos quando o espaço em disco está baixo.

1 curtida
12

O que pode ser um problema se você o estiver executando com um script; o script simplesmente ficará travado esperando uma resposta (acho que é por isso que se usa yes para direcionar a ele). Eu apenas faço uma limpeza se o disco tiver menos de 10 GB livres.

1 curtida
13

Aqui está talvez uma solução alternativa que pode funcionar para mim. Estou a levantá-la aqui caso seja útil para outros.

Estou a considerar adicionar uma configuração data-root a /etc/docker/daemon.json, para ver se isso força o docker a colocar as suas imagens — as imagens do Discourse, neste caso, já que nada mais está alojado na máquina — num local menos crítico que não exploda o meu volume de arranque.

A pesquisa no meta por threads anteriores sobre isto dá-me alguns resultados que não me dizem muito, e antes que eu cause o colapso da minha instância de produção do Discourse num monte de brasas fumegantes, queria perguntar para ver se isto é viável :slight_smile:

14

Eu adotei uma abordagem diferente e montei um sistema de arquivos separado em /var/lib/docker

No meu caso, por motivos muito específicos do site, escolhi sistemas de arquivos separados para cada um de /var/discourse/shared, /var/discourse/shared/data, /var/discourse/shared/app/uploads/default/original e /var/lib/docker — mas se você quiser apenas ter /var/discourse como um sistema de arquivos separado, você provavelmente poderia criar o diretório /var/discourse/share/docker e fazer um bind-mount dele em /var/lib/docker (obviamente fazendo isso com o sistema em repouso e movendo os arquivos conforme necessário).

4 curtidas
15

Essa é uma ideia ainda melhor do que mexer nas entranhas do docker. Obrigado!!

1 curtida
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.