Faça deploy de Go na Nodion

Faça deploy de Go passo a passo

1. Escute em PORT A Nodion define PORT para o processo web; escute nessa porta, em todas as interfaces. O r.Run() do Gin sem endereço já usa PORT. Com Echo, Fiber ou Chi, passe ":" + port manualmente. main.go

   package main
   
   import (
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   	}
   	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   		w.Write([]byte("ok"))
   	})
   	log.Fatal(http.ListenAndServe(":"+port, nil))
   }

2. Um binário por cada pasta cmd/ Sem uma pasta cmd/, a Nodion compila a raiz do módulo num único binário. Caso contrário, cada cmd/<name> com ficheiros Go passa a ser um binário próprio, e o pacote da raiz deixa de ser compilado. Se houver apenas um binário, o processo web executa-o. Se houver vários, executa o que se chama server, api, web ou app; se nenhum tiver esse nome, executa o primeiro. Cada um dos outros binários passa a ser um tipo de processo com o mesmo nome.

   cmd/server/main.go
   cmd/worker/main.go
   cmd/migrate/main.go

3. Verifique as definições de build Os binários são compilados com CGO_ENABLED=0 e -ldflags "-s -w". Se uma dependência precisar de cgo, como mattn/go-sqlite3, defina CGO_ENABLED=1 no separador Environment com a opção Build. Uma variável GOFLAGS_LDFLAGS com a opção Build substitui as ldflags, por isso inclua aí -s -w se quiser mantê-las.
4. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea e escolha o branch e a região EU Central. Mantenha a estratégia de build em Buildpacks; se o repositório tiver um Dockerfile, o formulário escolhe Dockerfile em vez disso.
5. Associe o PostgreSQL e execute as migrações No separador Environment, associe uma base de dados da mesma região; DATABASE_URL chega no próximo deploy, e os drivers PostgreSQL como o pgx aceitam este URL tal como está. Em runtime, os seus binários estão no PATH, por isso um binário cmd/migrate pode correr como passo de release, uma vez por build, antes de a nova versão arrancar. Procfile

   release: migrate

A ter em conta

• Workers sem ProcfileUm binário de cmd/worker passa a ser o tipo de processo worker. No separador Processes, adicione um processo chamado worker sem porta e deixe o comando vazio; esse processo executa o binário. Dê ao binário web o nome server, api, web ou app, para que o processo web não escolha outro.
• Sempre o Go mais recenteA linha go em go.mod e um ficheiro .go-version não selecionam uma toolchain mais antiga: cada build usa a versão mais recente do Go que a Nodion compilou. Execute também a sua CI com o Go mais recente.

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

• Porque criámos os nossos próprios buildpacks no Ubuntu 26.04 Os nossos buildpacks seguem a especificação Cloud Native Buildpacks, mas a stack, os buildpacks de linguagem e as versões de runtime são nossos. Eis porquê.
• Dockerfile vs buildpacks: qual deve escolher? Ambos transformam o seu código numa imagem de contentor. A diferença está em quem escreve os passos do build, e isso determina o controlo, a manutenção e as atualizações de segurança.

Go na Nodion: perguntas e respostas