Este é um cenário de planejamento ilustrativo para um construtor independente, não uma história de cliente ou um resultado de capacidade medido. O aplicativo registra empréstimos de equipamentos para um pequeno clube: um membro autenticado pode ver itens disponíveis, criar um empréstimo e devolvê-lo. Um registro importa mais do que um diagrama de implantação sofisticado, então o primeiro design deve tornar falhas de gravação e perda de dados fáceis de investigar.
Escolha a arquitetura mínima útil
Use um processo de API, um banco de dados e um proxy reverso para o endpoint HTTPS público. Mantenha o banco de dados acessível apenas pelo caminho local ou privado pretendido. Dê ao aplicativo sua própria identidade de sistema operacional, com acesso aos arquivos de que precisa. Mantenha os arquivos de implantação separados dos dados persistentes para que um lançamento não substitua o banco de dados ou os uploads.
Compartilhar uma instância mantém a configuração e a investigação gerenciáveis para uma primeira implantação. Também vincula os componentes ao mesmo limite de reinicialização, disco e falha. Aceite essa troca deliberadamente. Se o aplicativo exigir recuperação independente ou o banco de dados competir consistentemente com a API, considere separá-los antes de aumentar tudo de uma vez.
Orce para o momento de pico
Não dimensione apenas para um processo ocioso. A planilha abaixo usa permissões de planejamento inventadas para demonstrar o cálculo. Elas não são medições deste aplicativo, benchmarks ou requisitos mínimos. Substitua-as por observações do seu runtime e banco de dados, incluindo uma implantação representativa.
| Trabalho compartilhando a instância | Permissão de planejamento | O que observar |
|---|---|---|
| Sistema operacional e proxy | 300 MiB | Atividade de fundo normal e registro em log |
| Processo da API | 350 MiB | Requisições representativas, não apenas a inicialização |
| Banco de dados | 400 MiB | Conexões, consultas e trabalho de manutenção |
| Margem de implantação | 450 MiB | Qualquer processo ou etapa de compilação sobrepostos |
| Envelope de planejamento combinado | 1,500 MiB | Compare com a memória utilizável real |
O Construir plano inicial atualmente especifica 2 vCPU, 2 GB de RAM e 50 GB SSD. Esses números o tornam uma configuração a investigar para esta planilha, não prova de que a stack se ajusta. GB de catálogo e leituras de MiB de uma ferramenta são unidades diferentes; inspecione os totais reais do sistema. A estimativa de memória disponível do Linux considera memória recuperável relevante, então pouca memória livre por si só não é um veredito de dimensionamento. Veja a explicação do kernel sobre MemAvailable e os guia de medição.
CPU e disco precisam de decisões separadas. Registre durações de requisições e esperas do banco de dados antes de adicionar vCPU. Orce disco para o sistema operacional, lançamentos retidos, crescimento do banco de dados, logs e trabalho de recuperação temporário. Um recurso de upload cria um problema de armazenamento diferente de um pequeno registro estruturado; dê a ele um limite de tamanho e uma decisão de retenção.
Conheça o custo inicial
O exemplo a seguir usa o Build com seus recursos padrão e nenhuma opção recorrente adicionada. Seu subtotal mensal é $14.00 USD. Os valores são gerados a partir do catálogo atual do configurador, então a tabela de preços acompanha o checkout.
| Período de serviço | Antes de salvar | Salvo | Pagar uma vez |
|---|---|---|---|
| 1 mês | $14.00 | $0.00 (0%) | $14.00 USD |
| 3 meses | $42.00 | $0.00 (0%) | $42.00 USD |
| 6 meses | $84.00 | $23.52 (28%) | $60.48 USD |
| 12 meses | $168.00 | $84.00 (50%) | $84.00 USD |
Um período semestral ou anual reduz o total inicial deste catálogo em relação a pagar o subtotal mensal sem desconto pelo mesmo número de meses. Isso não adiciona recursos, não estabelece um preço de renovação nem torna uma arquitetura não testada adequada. Escolha um período com o qual você possa se comprometer, revise detalhes de serviço e cobrança, e reserve separadamente para um domínio, quaisquer serviços externos e taxas de rede.
Verifique uma requisição completa
Antes de abrir o aplicativo para seus usuários pretendidos, confirme o acesso ao servidor e o acesso de recuperação, instale um runtime suportado e registre o lançamento que você implanta. Uma definição de serviço deve identificar o executável, o diretório de trabalho e o usuário do runtime. A configuração do systemd Restart= controla o comportamento de falha especificado; um loop de reinicialização ainda precisa de diagnóstico. Veja o manual do serviço e os passo a passo de implantação.
Teste localmente primeiro, depois pelo nome real HTTPS a partir de outra conexão. Com o Caddy, o gerenciamento automático de certificados depende de uma configuração de nome válida e de um método de validação funcional; os desafios comuns HTTP e TLS-ALPN precisam das portas de entrada acessíveis 80 e 443, respectivamente. Veja os pré-requisitos do Caddy HTTPS. Um sucesso local não pode descartar um problema de DNS ou proxy, como o guia de caminho de requisição explica.
Torne a verificação da aplicação específica: crie um item de equipamento descartável, empreste-o, confirme que uma segunda requisição vê o resultado armazenado e depois devolva-o. Verifique a autorização, bem como um endpoint de saúde simples. Registre as respostas esperadas antes do teste e mantenha credenciais e dados de membros fora dos logs compartilhados para solução de problemas.
Comprove uma pequena recuperação
Faça backup do banco de dados com um método adequado ao mecanismo e ao objetivo de recuperação. O PostgreSQL documenta abordagens separadas de lógica, sistema de arquivos e arquivamento contínuo; a escolha certa depende de como você precisa recuperar. Veja sua visão geral de backup. Se fotografias de itens forem enviadas, inclua esses arquivos e o relacionamento com seus registros no banco de dados.
Execute um exercício de restauração em um banco de dados e diretório de teste separados. Encontre um item conhecido e seu arquivo correspondente, depois verifique se a aplicação consegue ler ambos. Anote o backup selecionado, o carimbo de data/hora dos dados, as etapas necessárias e o resultado real. O primeiro guia de restauração desenvolve este exercício. Uma seleção opcional de backup de catálogo não prova que essa recuperação no nível da aplicação funciona.
Tome a próxima decisão com base em evidências
Mantenha o design simples enquanto seu comportamento medido e requisitos de recuperação se adequarem. Investigue uma aplicação parada ou avisos de recursos antes de assumir que um plano maior é a resposta. Escolha Malásia, Romênia ou Suíça para o servidor, depois confirme alocação de recursos, local de backup e escopo do serviço. Este cenário não estabelece instalação, capacidade de requisições ou prazo de entrega.
Configure Build e revise cada opção. O link abre o plano inicial; verifique o período selecionado e quaisquer escolhas salvas antes de continuar. Obter detalhes de pagamento não instala a aplicação de empréstimo de equipamentos.
Documentação utilizada
Referências primárias para esta página. Consulte a documentação da versão instalada em seu próprio ambiente.