Faça deploy de Static sites and SPAs na Nodion

Faça deploy de Static sites and SPAs passo a passo

1. Faça commit de um lockfile e de um script de build Faça commit do seu lockfile; sem ele, o build falha. A Nodion executa o script build e usa a pasta de saída do seu framework: dist/ no Vite, build/ no Create React App, dist/<projeto>/browser no Angular, public/ no Gatsby e _site/ no Eleventy. package.json

   "scripts": {
     "dev": "vite",
     "build": "vite build"
   }

2. Defina as variáveis de build O seu bundler escreve variáveis como VITE_*, REACT_APP_* ou GATSBY_* nos ficheiros durante o build, por isso precisam da opção Build no separador Environment. Todo o seu conteúdo é público, por isso nunca coloque segredos nelas.
3. Indique outras pastas de saída no static.toml Outros geradores também funcionam: a Nodion procura um index.html em dist, build, out, .output/public, public e _site. Se o seu escrever noutro sítio, como faz o VitePress, adicione um static.toml junto ao package.json. Este ficheiro também faz com que a Nodion trate o repositório como site estático quando não o detetaria. fallback indica o ficheiro servido para caminhos que não existem. static.toml

   output-dir = "docs/.vitepress/dist"
   fallback = "index.html"

4. HTML simples não precisa de build Um repositório com um index.html na raiz e sem package.json é servido tal como está. A Nodion exclui .git, os ficheiros .env e alguns ficheiros de chaves comuns, mas considere público tudo aquilo de que faz commit e mantenha os segredos fora do repositório.
5. Crie a aplicação e faça push No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central e escolha o tamanho mais pequeno. Cada push faz o build de uma nova release, e o tráfego passa para ela assim que / responde, algo de que o seu index.html se encarrega.

A ter em conta

• As rotas do lado do cliente funcionamOs caminhos que não correspondem a nenhum ficheiro recebem o seu index.html, por isso as rotas do React Router, do Vue Router e do Angular continuam a funcionar quando a página é recarregada. O fallback não pode ser desativado; fallback no static.toml apenas troca o ficheiro.
• Sem processos do Procfile, sem código de servidorOs processos do Procfile não têm efeito num site estático, e só a pasta de saída é publicada. Uma linha release: seria executada na mesma, mas numa imagem que só contém os ficheiros gerados, por isso não a inclua. Se o seu repositório for um servidor Node.js com um script de build, leia o guia de Node.js para saber como a Nodion distingue os dois casos.
• Angular SSRA Nodion faz o build dos projetos Angular como sites estáticos, mesmo com @angular/ssr, por isso a renderização do lado do servidor não é executada. Para SSR, use um Dockerfile.
• Hugo e JekyllA Nodion não executa builds de Hugo nem de Jekyll. Faça o build do site localmente, faça commit da pasta gerada (public/ ou _site/) e defina-a como Base directory da aplicação: uma pasta com um index.html e sem package.json é servida tal como está. Em alternativa, faça o build do site num Dockerfile.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Ambientes de pré-visualização: uma aplicação por pull request Uma cópia em execução da sua aplicação para cada pull request: para que servem os ambientes de pré-visualização, onde se complicam e como a Nodion os gere.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

Static sites and SPAs na Nodion: perguntas e respostas