Tenho tentado fazer o Discourse funcionar em um Raspberry Pi 4 há alguns meses e não tive sucesso.
Pareceu que talvez a imagem do Docker estivesse desatualizada, então desinstalei e reinstalei outras duas imagens do Docker e ainda assim não tive sucesso.
Levou alguns anos para a Raspberry Pi Foundation lançar a arquitetura de software correta porque eles ainda estavam desenvolvendo para hardware de 32 bits. Por favor, altere sua imagem para a versão arm64 atual. A boa notícia é que isso permitirá que você use todos os 8 GB de RAM se esse for o seu dispositivo.
Hmm, bem, esse é um kernel de 64 bits (aarch64), e ainda assim você teve uma mensagem do Docker reclamando sobre armv8. Eu não conheço esse território ou toda a história de como você chegou aqui… um conselho comum é fazer um backup seguro e restaurar em um sistema operacional e instalação do Discourse novos.
Espero que não seja o caso de que uma instalação bem-sucedida inevitavelmente terá problemas quando chegar a hora de atualizar.
lol, eu já fiz isso muitas vezes e estou preparado para fazer de novo.
Atualmente, estou em um Raspberry Pi 400 Rev 1.0 rodando Bullseye 64 lite.
Eu tentei Bullseye 64, 64 lite, 32 lite; e Bookworm 64. Se bem me lembro, recebo o mesmo erro que postei em cada caso.
Depois de investigar um pouco, um amigo sugeriu refazer o flash para Bullseye 64 lite e isso deveria corrigir o problema. Mas não corrigiu.
Nota lateral, quando executo o docker sudo docker run hello-world ele produz a mensagem esperada “Docker está funcionando”.
sudo docker info
Cliente: Docker Engine - Community
Versão: 24.0.7
Contexto: default
Modo de depuração: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Versão: v0.11.2
Caminho: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Versão: v2.21.0
Caminho: /usr/libexec/docker/cli-plugins/docker-compose
Servidor:
Contêineres: 2
Em execução: 1
Pausado: 0
Parado: 1
Imagens: 4
Versão do Servidor: 24.0.7
Driver de Armazenamento: overlay2
Sistema de Arquivos de Backup: extfs
Suporta d_type: true
Usando metacopy: false
Overlay Nativo Diff: true
userxattr: false
Driver de Log: json-file
Driver Cgroup: systemd
Versão Cgroup: 2
Plugins:
Volume: local
Rede: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inativo
Runtimes: io.containerd.runc.v2 runc
Runtime Padrão: runc
Binário Init: docker-init
Versão do containerd: 3dd1e886e55dd695541fdcd67420c2888645a495
Versão do runc: v1.1.10-0-g18a0cb0
Versão do init: de40ad0
Opções de Segurança:
seccomp
Perfil: builtin
cgroupns
Versão do Kernel: 6.1.21-v8+
Sistema Operacional: Debian GNU/Linux 11 (bullseye)
Tipo de SO: linux
Arquitetura: aarch64
CPUs: 4
Memória Total: 3.705GiB
Nome: raspberrypi
ID: 183a2a7a-8acf-40eb-9386-c99d70ee8ed3
Diretório Raiz do Docker: /var/lib/docker
Modo de depuração: false
Experimental: false
Registros Inseguros:
127.0.0.0/8
Habilitado Restauração ao Vivo: false
AVISO: Sem suporte para limite de memória
AVISO: Sem suporte para limite de swap
Não consigo fazer funcionar em um Raspberry Pi 4 com 8GB de RAM e um SSD conectado via USB como unidade única. Ele continua travando no seguinte (ou pelo menos, fico impaciente depois de uma hora de espera…)\n\n\nI, [2024-02-06T00:58:51.743994 #1] INFO -- : \u003e cd /var/www/discourse \u0026\u0026 su discourse -c 'yarn install --frozen-lockfile \u0026\u0026 yarn cache clean'\nwarning \"@discourse/lint-configs \u003e eslint-plugin-ember \u003e ember-eslint-parser@0.2.5\" has unmet peer dependency \"@typescript-eslint/parser@^6.15.0\".\nwarning \"@discourse/lint-configs \u003e eslint-plugin-ember \u003e ember-eslint-parser@0.2.5\" has incorrect peer dependency \"typescript@^5.3.3\".\nwarning \" \u003e @glint/environment-ember-loose@1.3.0\" has unmet peer dependency \"@glimmer/component@^1.1.2\".\n2024-02-06 01:15:58.966 UTC [64] WARNING: worker took too long to start; canceled\n2024-02-06 01:16:19.640 UTC [480] WARNING: autovacuum worker started without a worker entry\n2024-02-06 01:21:46.504 UTC [64] WARNING: worker took too long to start; canceled\n2024-02-06 01:22:18.863 UTC [481] WARNING: autovacuum worker started without a worker entry\n\n\nParece que ainda está fazendo coisas:\n\n\nTasks: 60 total, 7 running, 53 sleeping, 0 stopped, 0 zombie\n%Cpu(s): 20.8 us, 60.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 18.8 si, 0.0 st \nMiB Mem : 7807.7 total, 6783.7 free, 954.0 used, 70.0 buff/cache \nMiB Swap: 0.0 total, 0.0 free, 0.0 used. 6853.8 avail Mem \n\n PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND \n 3422 root 20 0 1928888 33180 2512 S 40.6 0.4 28:18.52 dockerd \n 9922 root 20 0 1105300 9984 2944 S 30.2 0.1 1:02.72 docker \n 3362 root 20 0 1934276 19060 1408 S 20.8 0.2 20:24.57 containerd \n 9416 ubuntu 20 0 1148560 298160 0 R 12.0 3.7 10:03.66 node \n 9158 dnsmasq 20 0 54992 2432 128 R 11.7 0.0 5:01.56 redis-server \n 8997 root 20 0 1238120 5704 256 S 10.7 0.1 9:06.51 containerd-shim \n 9504 ubuntu 20 0 569128 51532 0 R 8.8 0.6 5:20.97 node \n 9930 pollina+ 20 0 353212 5692 3328 R 6.8 0.1 0:06.97 postmaster \n 9931 pollina+ 20 0 352820 4156 2048 R 5.2 0.1 0:02.70 postmaster \n 9098 pollina+ 20 0 352844 3004 1024 R 2.3 0.0 0:15.75 postmaster \n 219 root 20 0 1259732 36000 20352 S 1.0 0.5 1:10.50 cloudflared \n 9658 root 20 0 9116 4864 2816 R 0.6 0.1 0:18.19 top \n\n\nSeria bom se a compilação incluísse uma barra de progresso.\n\nQual é a melhor maneira de:\n- descobrir o que ele está fazendo?\n- desligá-lo com segurança para tentar novamente? Tentei sudo shutdown --reboot 0 anteriormente, no entanto, isso destruiu o banco de dados postgres e tive que refazer a máquina.",“target_locale”:“en”}
Você pode pesquisar as mensagens que está recebendo no fórum e na internet. Além disso, tente mover isso para uma nova postagem em vez de uma resposta ao anúncio.
Essa etapa não é uma etapa de compilação, mas apenas de download de arquivos JS. É uma quantidade absurda de arquivos pequenos, então eu diria que é um caso patologicamente ruim para a solução de armazenamento incomum que você está usando?
Ok, vou deixar rodando por alguns dias então. Caso contrário, acho que em vez de um rpi4 com ssd, precisará ser um rpi5 com ssd.
ATUALIZAÇÃO:
Horas depois e mais leituras depois, decidi mudar o container lxd de usar um pool de armazenamento btrfs para usar um pool de armazenamento zfs. Depois de feito, ele conseguiu progredir além desse ponto em cerca de 5 minutos (enquanto com btrfs ele travava por cerca de uma hora antes que os workers começassem a falhar).
Ainda está construindo, no entanto, assim que terminar e eu conseguir importar o backup com sucesso e resolver o SSL do cloudflare, publicarei minha migração do discourse docker rodando dentro de um scaleway para o discourse docker rodando dentro de um container lxd dentro de um raspberry pi 4 + ssd.