Como o título indica, executei sudo apt install apache2.
O servidor não inicia e este é o erro:
(98) Endereço já em uso: AH00072: make_sock: não foi possível vincular ao endereço [::]:80
(98) Endereço já em uso: AH00072: make_sock: não foi possível vincular ao endereço 0.0.0.0:80
nenhum socket de escuta disponível, desligando
AH00015: Não foi possível abrir os logs
Ação 'start' falhou.
O log de erros do Apache pode conter mais informações.
pam_unix(sudo:session): sessão encerrada para o usuário root
O processo de controle saiu, código=exited status=1
apache2.service: Falhou com o resultado 'exit-code'.
Falha ao iniciar o Servidor HTTP Apache.
Como posso resolver isso? Obrigado a todos antecipadamente.
Sim e não. Vamos dar um passo para trás e analisar isso.
Antes, parece que você estava rodando vários sites com o Apache. O Apache escutava nas portas 80 e 443 e então “proxyava” (redirecionava) as requisições como “hospitais virtuais”, permitindo que você rodasse muitos sites no mesmo servidor, todos escutando nas mesmas portas (80 e 443). Isso era “LAMP 101”… a maneira dos hosts virtuais.
Agora, digamos que você instale o Discourse da maneira oficial OOTB (Out of the Box). O Discourse OOTB tentará se vincular às mesmas portas e falhará, porque o Apache já está usando (vinculado a) essas portas. Você tem opções:
Rodar o Discourse em um socket de domínio Unix e configurar o Apache para fazer proxy reverso do aplicativo Discourse como um host virtual.
Nota: Eu testei isso e funciona; mas isso não é oficialmente (nem mesmo desoficialmente) suportado pelo Discourse.
Migrar do Apache para o nginx e rodar todos os seus servidores web a partir do nginx, também fazendo proxy reverso do aplicativo Discourse como um host virtual, usando um socket de domínio Unix para o aplicativo de produção Discourse-docker.
Nota: Isso também não é oficialmente suportado pelo Discourse; e a maioria das pessoas que rodam sites Apache achará um pouco “desafiador” portar todo o seu mod_rewrite do Apache2 e o mod de geo-ip codificado para o nginx; mas é possível, claro, especialmente se seus aplicativos forem construídos para ambos, nginx e Apache2 (isso é mais fácil, mas ainda não é oficialmente suportado).
Expor o contêiner Docker do Discourse em portas diferentes de 80 e 443.
Nota: Isso também não é (realmente) recomendado (mas é oficialmente suportado, conforme me lembro). No entanto, a maioria das pessoas não quer acessar um aplicativo web digitando números de porta como https://meu-grande-app-discourse.org:3334, então a maioria não faz isso em produção. Desenvolvimento é outra história.
Minha recomendação “sem conhecer todos os seus detalhes”, como alguém que tem muito LAMP e agora cada vez mais Discourse, é rodá-los em servidores separados (isso é oficialmente suportado pelo Discourse); mas se você estiver realmente apertado financeiramente e precisar rodá-los todos no mesmo servidor (ou apenas gostar de ter um único servidor grande e complicado), então você precisará aprender a configurar o Apache2 para fazer proxy reverso para um socket de domínio Unix para/do aplicativo Discourse.
Eu testei isso, e é possível configurar o Apache2 para fazer proxy reverso para o Discourse usando um socket de domínio Unix; mas essa solução não é oficialmente suportada (de forma alguma).
Nota: O link para configurar o Apache2 com o HAProxy foi uma solução que não consegui fazer funcionar facilmente; então eu abandonei (não há necessidade de usar apenas o HAProxy, existem “maneiras mais antigas” de fazer isso). No entanto, você pode estar melhor apenas seguindo este tutorial do Discourse:
Espero que isso ajude de alguma pequena forma, @nekodroid
Publicar em portas não padrão é 100% sem suporte. Já vi alguns tópicos em que, em vez de vincular a um socket, os proprietários do site alteraram as portas e usaram um proxy reverso para mapear de volta para 80/443, mas se o resultado final exigir :porta, então não é suportável.