API de Streaming da Instância Mastodon em Subdomínio Separado: Configuração

Ao executar uma instância do Mastodon, a API de streaming lida com atualizações em tempo real, como novas postagens e notificações. Por padrão, essa API roda no mesmo domínio da interface web. Você pode melhorar o desempenho e a segurança movendo a API de streaming para um subdomínio separado, como streaming.suainstancia.com. Este artigo explica como configurar o Nginx e o Mastodon para servir a API de streaming a partir de um subdomínio dedicado.

Executar a API de streaming em um subdomínio separado reduz a carga no servidor web principal e permite escalar o serviço de streaming de forma independente. Também isola as conexões WebSocket do tráfego HTTP principal, o que pode melhorar a confiabilidade geral. Esta configuração requer acesso ao seu servidor Mastodon, um nome de domínio e a capacidade de editar arquivos de configuração do Nginx.

Este guia aborda os pré-requisitos, as alterações de configuração do Nginx e as atualizações das variáveis de ambiente do Mastodon necessárias para habilitar um subdomínio de streaming separado. Ele pressupõe que você tenha uma instância do Mastodon funcionando em um único domínio e esteja confortável em editar arquivos de configuração do servidor.

Por que Usar um Subdomínio Separado para a API de Streaming

A API de streaming no Mastodon é responsável por entregar dados em tempo real aos clientes por meio de conexões WebSocket. Isso inclui atualizações de timeline, notificações e outros eventos ao vivo. Quando a API de streaming roda no mesmo domínio que a aplicação web principal, todo o tráfego HTTP e WebSocket compete pelos mesmos processos de trabalho do Nginx e recursos do servidor.

Ao mover a API de streaming para um subdomínio separado, você obtém três benefícios. Primeiro, você pode escalar o serviço de streaming de forma independente, executando vários processos de streaming ou até mesmo dedicando um servidor separado a ele. Segundo, você reduz o risco de conexões WebSocket interferirem com requisições HTTP regulares, o que pode causar timeouts ou carregamento lento de páginas. Terceiro, você pode aplicar políticas de segurança diferentes, como limitação de taxa ou regras de firewall, especificamente para o subdomínio de streaming.

Pré-requisitos para Esta Configuração

Antes de começar, certifique-se de ter o seguinte:

• Uma instância do Mastodon funcionando com acesso administrativo via shell
• Seu próprio nome de domínio com acesso ao gerenciamento de DNS
• Nginx instalado e configurado como proxy reverso para o Mastodon
• Capacidade de editar arquivos em /etc/nginx/sites-available/ e /home/mastodon/live/.env.production
• Privilégios de root ou sudo no servidor

Passos para Configurar a API de Streaming em um Subdomínio Separado

Os passos a seguir assumem que seu domínio principal do Mastodon é social.exemplo.com e você deseja usar streaming.social.exemplo.com para a API de streaming. Substitua estes pelos seus nomes de domínio reais.

1. Crie um registro DNS para o subdomínio de streaming
   No painel de controle do seu provedor de DNS, adicione um registro A para streaming que aponte para o endereço IP do seu servidor. Se você usar um CNAME, aponte para seu domínio principal. Aguarde a propagação do DNS, que geralmente leva alguns minutos.
2. Abra o arquivo de ambiente do Mastodon para edição
   Faça login no seu servidor via SSH. Navegue até o diretório live do Mastodon: cd /home/mastodon/live. Abra o arquivo .env.production com um editor de texto como nano: sudo nano .env.production.
3. Defina a variável STREAMING_API_BASE_URL
   Adicione ou atualize a seguinte linha no arquivo:
   STREAMING_API_BASE_URL=https://streaming.social.exemplo.com
   Isso informa ao Mastodon para anunciar a API de streaming no subdomínio separado. Salve o arquivo e saia do editor.
4. Crie um novo bloco de servidor Nginx para o subdomínio de streaming
   Crie um novo arquivo de configuração: sudo nano /etc/nginx/sites-available/streaming. Cole o seguinte bloco de servidor, ajustando o server_name e o proxy_pass conforme necessário:

   server {
       listen 443 ssl http2;
       listen [::]:443 ssl http2;
       server_name streaming.social.exemplo.com;
   
       ssl_certificate /etc/letsencrypt/live/social.exemplo.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/social.exemplo.com/privkey.pem;
   
       location / {
           proxy_pass http://127.0.0.1:4000;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }
   

   Se seus certificados SSL estiverem armazenados em outro local, atualize os caminhos de acordo. Salve e saia.

5. Habilite o novo bloco de servidor Nginx
   Crie um link simbólico para habilitar o site: sudo ln -s /etc/nginx/sites-available/streaming /etc/nginx/sites-enabled/.
6. Teste a configuração do Nginx
   Execute sudo nginx -t para verificar se a sintaxe está correta. Se você vir algum erro, revise o arquivo em busca de erros de digitação.
7. Reinicie o Nginx
   Aplique as alterações reiniciando o Nginx: sudo systemctl restart nginx.
8. Reinicie o serviço de streaming do Mastodon
   Reinicie o serviço de streaming para que ele pegue a nova variável de ambiente: sudo systemctl restart mastodon-streaming.

Após esses passos, todas as requisições da API de streaming serão servidas a partir de streaming.social.exemplo.com. Você pode verificar isso inspecionando as ferramentas de desenvolvedor do seu navegador em busca de conexões WebSocket direcionadas ao novo subdomínio.

Erros Comuns de Configuração e Como Evitá-los

Conexões WebSocket Falham Após Alterar o Subdomínio

Se os clientes não conseguirem estabelecer conexões WebSocket, a causa mais comum é a falta dos cabeçalhos Upgrade e Connection na configuração do proxy Nginx. Certifique-se de que seu bloco de servidor inclua proxy_set_header Upgrade $http_upgrade; e proxy_set_header Connection "upgrade";. Sem esses cabeçalhos, o Nginx não encaminha a solicitação de upgrade WebSocket para o processo de streaming do Mastodon.

Incompatibilidade de Certificado SSL para o Subdomínio de Streaming

Se você usar um único certificado curinga para social.exemplo.com, ele cobre automaticamente o subdomínio de streaming. Se você usar certificados separados, deve obter um para o subdomínio de streaming. Um certificado ausente ou expirado faz com que o navegador recuse a conexão WebSocket. Use o Certbot para emitir um certificado para o subdomínio de streaming, se necessário.

Variável de Ambiente Não Entra em Efeito

Após editar o .env.production, você deve reiniciar o serviço mastodon-streaming. Um simples reload não aplica a nova variável. Execute sudo systemctl restart mastodon-streaming para garantir que o serviço leia a configuração atualizada.

Comparação: API de Streaming no Domínio Principal vs Subdomínio Separado

Item	Domínio Principal	Subdomínio Separado
Complexidade da configuração	Baixa – sem DNS extra ou blocos Nginx	Média – requer registro DNS, bloco Nginx e variável de ambiente
Isolamento de recursos	Nenhum – streaming compartilha recursos com a aplicação web	Completo – pode escalar streaming independentemente
Estabilidade do WebSocket	Pode degradar sob alta carga HTTP	Isolado do tráfego HTTP, mais estável
Granularidade da política de segurança	Mesmas políticas para todo o tráfego	Pode aplicar limitação de taxa ou regras de firewall por subdomínio
Esforço de manutenção	Mínimo	Requer atualizar duas configurações se o domínio mudar

Com a configuração de subdomínio separado, sua instância do Mastodon pode lidar com mais usuários simultâneos e atualizações em tempo real sem afetar o desempenho da interface web principal. A compensação é uma configuração um pouco mais complexa que você deve manter ao atualizar a instância ou alterar domínios.

Agora você pode servir a API de streaming a partir de um subdomínio dedicado, o que melhora a escalabilidade e o isolamento. Em seguida, considere configurar um processo de streaming dedicado com múltiplos workers ajustando a variável de ambiente STREAMING_CLUSTER_NUM. Para configurações avançadas, você pode até hospedar o serviço de streaming em um servidor separado, apontando o proxy_pass para um endereço IP remoto.