Supondo que seu aplicativo não precise de acesso de gravação aos dados do aplicativo (o que realmente não deveria), fazemos o seguinte:
Nós dividimos os usuários em duas classes - node-<app>-runtime
e node-<app>-data
. <app>
sendo o nome do aplicativo. Ambos fazem parte de um grupo node-<app>
. Esses não são os nomes reais que usamos para os intrometidos por aí.
Nós fazemos o seguinte:
1) Para construir o aplicativo, sempre construímos em uma máquina separada e temos um script npm dist
que coloca apenas os arquivos necessários para executar o aplicativo em um diretório /dist
e envia uma cópia desse diretório para o nosso servidor de implantação. A vantagem disso é dupla - sabemos exatamente o que está acontecendo na implantação e podemos nos certificar de que qualquer desvio de dados nos diretórios node_modules
, .git
e outros dados não sejam adicionados às máquinas de produção. Isso também significa que quando o GitHub / Npm / etc. desce, não quebra o escalonamento automático, etc. - nosso servidor de implantação apenas fornece o tarball pré-construído.
2) Usamos nosso sistema de gerenciamento de configuração para criar um diretório de log em um local padronizado que pode ser gravado por node-<app>-runtime
com permissões 640. O caminho é fornecido para o aplicativo por uma Variável de Ambiente padrão. Nosso daemon de processamento de registros os seleciona automaticamente e os envia para um servidor remoto.
3) Nosso sistema de implantação coloca os arquivos do aplicativo em um local específico e os define para serem de propriedade de node-<app>-data
com permissões 640. O caminho é fornecido para o aplicativo por uma Variável de Ambiente padrão.
O único outro conselho que eu tenho é sempre ter certeza de que você está definindo NODE_ENV=production
. Muitos módulos de nó usam essa convenção para desativar os símbolos de depuração ou melhorar o desempenho ( express
vem à mente).