Todos os guias
NODE.JS API

VPS para um Node.js API: lista de verificação de implantação e dimensionamento

Escolha um VPS para um Node.js API por suporte em tempo de execução, supervisão de processo, uso de memória real, comportamento proxy, segredos, acesso ao banco de dados e recuperação testada.

Iniciar com o tempo de execução da aplicação e as suas dependências

Um VPS para um Node.js API precisa de um ambiente compatível e um proprietário de administração. Grave os requisitos de tempo de execução, pacote lockfile, dependências nativas, banco de dados e trabalhadores. Escolha uma versão suportada do Active LTS ou Manutenção LTS compatível com o projeto e, em seguida, verifique o executável usado pelo processo implantado.

Decida se o API é executado diretamente no Linux ou em um container. Uma escolha de distribuição não instala seu aplicativo ou banco de dados Node.js. A preparação do Docker é uma opção inicial de ambiente; o código de aplicação, compatibilidade de tempo de execução e o API que ainda precisam ser implementados e verificados após a entrega.

Compare os ambientes Linux VPS para o seu API

Definir a supervisão do processo, inicialização e desligamento

Iniciar o API em um terminal SSH interativo não é um ciclo de vida completo de produção. Escolha um supervisor: por exemplo, systemd para uma implantação direta ou o tempo de execução do contêiner para contêineres. Grave o executável, diretório de trabalho, conta de serviço e fonte de configuração. Verifique o arranque sem o seu ambiente de shell interactivo.

Teste uma falha de processo controlada e uma reinicialização planejada. Revisão reinicie regras e diagnósticos para que um erro persistente não se torne um loop inexplicável. Um processo em execução novamente não é a prova de que o banco de dados está conectado ou que o API está pronto. Teste terminação graciosa: pare de aceitar o novo trabalho, lide com pedidos em voo de forma adequada e feche as conexões da aplicação antes do tempo limite do supervisor.

Role a tabela horizontalmente, se necessário.

Gravar a implantação do API e as suas verificações de aceitação
ParteDecisão de registoProvas a recolher
Tempo de execuçãoRequisitos de liberação e aplicação Node.js suportadosO processo supervisionado usa o executável pretendido
Ciclo de vida do processoSupervisor, conta e política de reinícioInicialização, recuperação de falhas e desligamento foram testados
Ponto de entrada públicoEndpoint de domínio, proxy e aplicação privadaHTTPS e pedidos reais API usam o caminho pretendido
Base de dados e trabalhadoresLocalização, credenciais, concorrência e propriedade de dadosConexões, escrita e trabalhos comportam-se sob carga representativa
RecuperaçãoLançamento, configuração, cópias de dados e escopo de retrocessoUma restauração separada reconstrui um API funcional

Revisão Docker VPS preparação para uma implantação de container

Escolha RAM e CPU do comportamento de solicitação

Meça memória, requisite latência e erros sob uma mistura representativa de terminais API. Incluir tamanhos de carga útil, chamadas de banco de dados simultâneas e qualquer tarefa de fundo que compartilhe o servidor. Node.js process.memoryUsage relatórios RSS e V8 heap information; heapUsado sozinho não descreve o processo completo, suas alocações nativas ou os outros serviços em execução no VPS.

Um limite de espaço antigo V8 controla apenas parte do uso da memória e não deve consumir toda a alocação do host. Mais vCPUs também não fazem um callback bloqueado em um loop de evento executado em paralelo. Investigar trabalho síncrono caro, consultas e concorrência antes de interpretar um endpoint lento como uma necessidade para um servidor maior. Se você executar deliberadamente vários processos, meça suas contagens de memória e conexão combinadas.

Aplicação de tamanho, banco de dados e memória do trabalhador em uma pilha Docker

Verificar o proxy público e o limite privado da aplicação

Defina qual componente recebe solicitações públicas e qual endpoint atinge o API internamente. Ao usar um proxy reverso, configure o endereço de escuta do aplicativo, o destino do proxy e as regras de confiança deliberadamente. Não assuma que os cabeçalhos de clientes ou esquemas enviados são confiáveis de cada fonte. Reveja os limites de solicitação-corpo e os timeouts em ambos os lados para os endpoints que você realmente fornece.

Teste uma requisição autenticada, um erro de validação esperado, um upload maior se suportado e uma operação de longo prazo se a aplicação exigir uma. Verifique o nome de host e o comportamento do cliente HTTPS, incluindo as regras de origem do navegador, quando relevante. Manter os parâmetros de gestão e de base de dados fora da rota pública pretendida. A lista de verificação Nginx abrange a configuração do host e do certificado; estas verificações verificam como o API se comporta por trás dele.

Se o Nginx retornar o 502, compare seu log de erro upstream com o log da aplicação. Verifique se o API está em execução e ouvindo no endereço e porta configurados, então teste esse endpoint a partir do contexto de rede do proxy. Em recipientes separados, o localhost refere-se ao próprio ambiente de cada recipiente; o montante pretendido pode necessitar do seu nome de serviço. Investigue essa conexão falhando antes de mudar o firewall público ou escolher um VPS maior.

Validar o roteamento de host Nginx, HTTPS e a implantação de proxy

Mantenha a configuração e credenciais ao alcance do processo

Liste as variáveis de ambiente e outras configurações que o API requer, com um proprietário documentado para cada segredo. Node.js pode ler variáveis de inicialização através do process.env, mas escolher variáveis de ambiente não fornece criptografia, rotação ou controle de acesso. Mantenha o material secreto fora do diretório do site público, do repositório de origem e das respostas do aplicativo.

Execute o aplicativo com as permissões que ele precisa ao invés de usar privilégios de administrador por padrão. Verifique se a conta de serviço pode ler sua configuração pretendida e escreva apenas os dados necessários. Redigir fichas e cargas sensíveis de logs. Mantenha o inspetor de depuração fora do caminho de produção pública e revise atualizações de dependência através do processo de lançamento testado da aplicação.

Incluir o banco de dados, fila e uploads na recuperação

Decida se o banco de dados e a fila são locais ou externos, e configure os limites de conexão em torno do processo escolhido e a contagem de trabalhadores. Ensaiar a indisponibilidade do banco de dados e uma repetição do trabalhador sem criar ações comerciais duplicadas. Um endpoint de saúde API que só confirma um processo em execução pode não dizer que a dependência crítica necessária pelos usuários está disponível.

Um conjunto de recuperação precisa da liberação implantável, configuração necessária, dados do banco de dados e quaisquer uploads ou estado de trabalho durável. Proteger as credenciais, garantindo que um operador autorizado possa reconstruir o serviço. Teste a restauração longe da produção e identifique o trabalho perdido após o backup selecionado. Recrear um processo Node.js ou puxar sua imagem não restaura registros de aplicativos.

Construir e testar um conjunto completo de recuperação de aplicativos

Aceitar a versão usando verificações API reais

Antes de direcionar os clientes para uma implantação, verifique o domínio, autenticação, permissões, erros e fluxos de trabalho reais de leitura/escrita. Verifique a inicialização após o reinício, logs utilizáveis e uma reinicialização controlada. Gravar o resultado com o identificador de libertação e o ambiente testado.

Manter o retorno separado da reversão do banco de dados. Retornar à liberação anterior do aplicativo pode ser inseguro após uma alteração de esquema incompatível ou registros recém-escritos. Planeje essa decisão com o desenvolvedor do aplicativo e, em seguida, reveja os recursos VPS atuais e cotação contra a carga de trabalho medida. Hospedagem de pagamento e entrega de serviço permanecem separados da aceitação de seu próprio API.

  • O tempo de execução suportado e a inicialização supervisionada correspondem aos requisitos da aplicação.
  • Pedidos representativos e trabalhadores se encaixam na alocação de recursos medidos.
  • Foram testados roteamento público, autenticação e dependências privadas.
  • Segredos, recuperação de dados e a decisão de rollback do banco de dados têm um proprietário.
  • Nenhuma reivindicação de preparação de aplicativos depende apenas de um processo em execução.
Compare as configurações do Linux VPSOutros guias