Começando
Já sentiu curiosidade sobre como funcionam os nós Catalyst do Decentraland? Já quis executar seu próprio nó e se sentiu sobrecarregado sem saber por onde começar? Está criando conteúdo para o Decentraland e acha difícil realizar todo o ciclo de desenvolvimento e testes em servidores de produção?
Se você está (ou já esteve) nessa situação, não tema mais. Este tutorial ajudará no processo de planejamento, explicará o que você precisa decidir e então o guiará passo a passo na inicialização do servidor. Além disso, caso algo não saia conforme o planejado, há uma seção de solução de problemas no final com alguns dos problemas mais comuns e como corrigi-los.
Pronto? Mãos à obra.
Requisitos de hardware
Os servidores da Decentraland Foundation são implantados na Amazon AWS em t2.xlarge instâncias. Portanto, enquanto esses servidores são destinados ao uso público, o seu próprio pode funcionar com especificações bem menores, dependendo do uso pretendido.
Uma AWS EC2 t2.xlarge possui o seguinte hardware:
4 vCPUs.
16 Gb de RAM
E para armazenamento de arquivos + armazenamento de DB, um SSD / HDD com 2 Tb de capacidade deve ser mais que suficiente. No momento desta escrita, os servidores da fundação estão usando um pouco mais de 1 Tb para todo o armazenamento.
Pré-requisitos de software
O seguinte é necessário para executar o catalyst-owner:
Sistema operacional Linux / MacOS
Docker / docker-compose
Git
LiveKit Cluster
Algumas opções a considerar antes de começarmos
Você quer que seu nó seja exposto publicamente na Internet? Se sim, você precisará de uma instância exposta à internet e de uma URL pública para se conectar a ela.
O nó será usado para o desenvolvimento de cenas, wearables, etc.? Nesse caso, as especificações de hardware podem ser bem menores, pois provavelmente será acessado por uma ou duas pessoas, não por centenas de usuários.
Você quer sincronizar todos os tipos de entidade? Se estiver usando isso para desenvolver cenas, provavelmente você vai querer pular a sincronização de profiles, pois eles consomem muito tempo, largura de banda e, mais importante, espaço em disco, e não te trarão benefício para esse objetivo.
LiveKit
Um cluster LiveKit externo é necessário pelo serviço Comms do Catalyst para orquestrar as comunicações entre jogadores. Para isso, há duas opções: usar uma conta LiveKit Cloud ou executar seu próprio cluster LiveKit.
A recomendação é configurar Livekit Cloud account que vem com um nível gratuito que pode gerenciar 100 usuários, ou pagar pelo serviço conforme o tráfego. Essa abordagem é mais fácil, pois não exige provisionar infraestrutura extra e o serviço pode gerenciar o escalonamento. Caso contrário, será necessário provisionar um cluster LiveKit. LiveKit faz um ótimo trabalho com a documentação deles:
Caso queira se aprofundar nos detalhes técnicos necessários para suportar comunicações baseadas em transporte LiveKit, confira o ADR-70 New Communications Architecture.
Guia passo a passo
A primeira coisa a fazer é clonar o catalyst-owner repositório do GitHub
Uma vez feito isso, é hora de configurar as variáveis de ambiente para o nó e fazer quaisquer alterações conforme apropriado.
Agora, usando seu editor de texto favorito, faça as alterações necessárias nesses arquivos. Por exemplo, configurar o EMAIL variável de ambiente com um email válido é obrigatório para que você possa receber atualizações sobre expiração de certificados do Certbot.
Também pode ser necessário configurar seu valor particular para CATALYST_URL especialmente se o seu servidor for exposto publicamente na Internet. Para uso em sua máquina local, o padrão de http://localhost servirá.
Serviço Comms
Uma vez que o cluster LiveKit esteja disponível, você precisará definir as variáveis específicas do LiveKit para o serviço Comms funcionar, por exemplo:
O ROOM_PREFIX variável é opcional e pode ser configurada para identificar salas LiveKit criadas pelo Catalyst. Isso é útil se mais de um Catalyst estiver usando o mesmo LiveKit Cluster.
Content Server
Há uma variável chamada CONTENT_SERVER_STORAGE que define a pasta local que o content server usará para armazenamento. O padrão é CONTENT_SERVER_STORAGE=./storage. Você pode alterar esse valor para armazenar arquivos em outro lugar, ou pelo menos certificar-se de que a pasta referenciada exista. Pode ser necessário criá-la assim:
Há outra variável interessante SYNC_IGNORED_ENTITY_TYPES que permite ignorar certos tipos de entidade durante o processo de sincronização. Se você for usar o servidor Catalyst para desenvolvimento, talvez não precise que todos os tipos de conteúdo sejam sincronizados. Você pode definir a var env SYNC_IGNORED_ENTITY_TYPES="profile,store" para que apenas scenes e wearables sejam trazidos dos servidores DAO. Isso economizará muito tempo, largura de banda e espaço em disco no seu servidor.
💡 Para uma lista mais exaustiva de variáveis de ambiente suportadas, consulte o Environment variables seção abaixo.
Iniciar o nó Catalyst
Depois que todas as variáveis de ambiente forem configuradas, é hora de iniciar o nó. Isso deve ser tão simples quanto executar o init.sh script na pasta raiz.
Se tudo correu bem, agora temos um nó Decentraland completo em execução. Você pode abrir o navegador e digitar a URL. Se estiver usando o padrão, deve ser http://localhost.
Podemos verificar os logs do content server com este comando docker:
Mesmo que o servidor agora esteja em execução, ele não está 100% pronto para entrar em operação. Ele precisa sincronizar o conteúdo a partir dos outros servers of the DAO para que possa oferecer a mesma experiência aos usuários conectados a ele. A sincronização pode levar muito tempo. Em uma boa conexão com a internet, 6 horas devem ser bastante comuns. Então... é hora de tomar um café, tirar uma soneca, dormir bem e voltar amanhã.
Uma forma de saber se a sincronização está completa consiste em verificar os resultados do endpoint de status do content: http://localhost/content/status (use sua URL aqui).
Enquanto synchronizationState estiver Bootstrapping, o nó suspenderá temporariamente a aceitação de novos deployments. Essa medida garante que nenhuma nova entidade seja implantada até que o nó esteja atualizado dentro da rede DAO. Uma vez que o status mude para Syncing, isso indica que o nó conseguiu se atualizar e agora está recebendo continuamente as últimas atualizações. Esse é o estado saudável em que o nó está totalmente funcionando e aceitando novos deployments.
Se você for mais do tipo linha de comando, pode procurar nos logs da imagem docker do content server por esta mensagem: Starting to sync entities from servers pointer changes. Quando você vir esse texto, o content server estará totalmente sincronizado e pronto para uso completo.
Environment variables
A seguir está uma lista abrangente de todas as variáveis de ambiente do content server com seus valores padrão, conforme registrado nos logs do content server durante a inicialização:
Usando seu nó para produção
Se você quiser executar seu próprio servidor e ajudar a escalar a rede, antes de tudo isso é incrível, a comunidade e a fundação realmente apreciam você fazê-lo.
Nesse caso, você terá que passar pelo processo de solicitar aprovação ao DAO para ingressar na rede visitando this link. Você também pode solicitar uma doação de MANA para cobrir as despesas de infraestrutura e gerenciamento.
É importante que as especificações do seu hardware estejam mais alinhadas com o que foi sugerido acima nos requisitos de hardware, pois o servidor será usado por qualquer membro da comunidade para entrar no Decentraland.
Especificações da API
Para mais detalhes sobre as APIs para content, lambdas e comms servers você pode consultar o API specs.
Solução de problemas/FAQ
Algumas coisas podem dar errado ao iniciar seu servidor. Aqui estão alguns dos problemas mais comuns encontrados ao longo do tempo e como corrigi-los.
A porta 5432 está sendo usada pelo postgres local
Se você executar o nó em uma máquina usada para desenvolvimento, ou se ela já estiver hospedando outros serviços, há grande chance de já existir um servidor de banco de dados postgres em execução nessa máquina. Então a porta 5432 já estará ocupada.
A maneira mais fácil de resolver isso é parar o postgres que já está rodando localmente e então reiniciar o container postgres do docker usando docker start postgres.
Se você tem conhecimento em docker compose, pode começar a mexer em docker-compose.yml e variáveis de ambiente para tentar fazê-lo funcionar em uma porta diferente. Para manter as coisas simples aqui, vamos evitar esse caminho neste tutorial.
A porta 80 está sendo usada pelo nginx local
A mesma coisa pode acontecer com a porta 80 (e até com a porta 443). Se você estiver executando o nginx na máquina local, há grande chance de que as portas 80/443 já estejam vinculadas a esse serviço, então o container Docker do Catalyst não poderá usá-las.
Novamente, a abordagem mais simples seria parar o serviço nginx local e então reiniciar o container docker usando docker start nginx. Ou, alternativamente, você precisa usar docker-compose.yml e .env para fazê-lo funcionar em uma porta diferente.
Documentos adicionais para referência
Se você quer entender melhor o que um servidor Catalyst faz, quais serviços ele inclui, etc., você pode consultar o repositório architecture https://github.com/decentraland/architecture que explica as partes em detalhe.
Se você gostaria de contribuir com o código dos servidores Catalyst, certifique-se de verificar o contributing guide para aprender sobre nosso processo de desenvolvimento, como propor correções de bugs e melhorias, e como construir e testar suas alterações.
E finalmente, se você precisar contatar a equipe, pode fazê-lo via Discord ou submetendo GitHub issues.
Atualizado