goship.yaml
Um arquivo na raiz do projeto que diz duas coisas: como o CLI faz o deploy, e como a plataforma constrói e roda o app. É opcional — sem ele, goship deploy funciona com o que consegue deduzir do diretório.
# goship.yaml
# — lido pelo CLI —
app: blog
org: acme
project: loja
# environment: staging # só quando não for o ambiente padrão da organização
platform: python # ou: dockerfile: Dockerfile
plan: app-small
env:
LOG_LEVEL: info
# — lido pela plataforma, no build e no deploy —
healthcheck:
path: /healthz
hooks:
build:
- python manage.py collectstatic --noinput
restart:
after:
- python manage.py migrate
processes:
- name: web
command: gunicorn app:app --bind 0.0.0.0:$PORT
- name: worker
command: python worker.pygoship init escreve a parte do CLI pra você, incluindo project: quando a organização tem mais de um projeto e environment: quando o ambiente escolhido não é o padrão da organização. Também são aceitos os nomes goship.yml, .goship.yaml e .goship.yml.
Configuração do CLI
| Chave | O que faz |
|---|---|
app | nome do app; sem ela, o nome do diretório |
org | organização do projeto, no lugar do goship org use |
project | projeto onde o app vive, no lugar do goship project use. Só vale quando o org do arquivo é a organização em uso (ou quando não há org) — veja Organizações e projetos |
platform | go, python, nodejs ou static, usada ao criar o app |
dockerfile | constrói a partir desse arquivo em vez de uma plataforma |
environment | ambiente do projeto onde o app vive, no lugar do goship environment use. Só vale quando o org e o project do arquivo estão vazios ou são a organização e o projeto em uso. Sem ela, vale a ordem de Login, organização, projeto e ambiente e, no fim, o ambiente padrão da organização |
plan | plano usado ao criar o app; goship plans lista os do ambiente |
env | variáveis de ambiente do app, aplicadas a cada deploy, como privadas. Segredos ficam melhor em --env-file. Não tem relação com environment, que é o ambiente do GoShip |
A chave environment diz onde o app vive; onde isso roda é o cluster do ambiente, e o arquivo não escolhe cluster. A chave antiga node, de quando o app escolhia a máquina, foi removida do CLI: um goship.yaml que ainda a tem segue funcionando, porque o CLI ignora a chave e avisa uma vez, nesta versão. Apague-a do arquivo. A mudança vale a partir da versão 0.14.0 da CLI.
Healthcheck
O deploy só troca a versão em produção depois que a nova responde. Se não responder, o deploy falha e a versão anterior continua no ar.
healthcheck:
path: /healthz
scheme: http # ou https
headers:
Host: blog.example.com
allowed_failures: 3 # falhas seguidas antes de reiniciar a unidade
interval_seconds: 10
timeout_seconds: 5
deploy_timeout_seconds: 120 # quanto o deploy espera a nova versão responder
force_restart: true # reinicia a unidade quando o check falha em produçãoNo lugar de path, command roda um comando dentro da unidade; saída 0 é saudável:
healthcheck:
command: ["/bin/sh", "-c", "pg_isready -h $DB_HOST"]startupcheck aceita os mesmos campos (menos deploy_timeout_seconds e force_restart) e vale só pro arranque: enquanto ele não passa, o healthcheck não conta. Use pra apps que demoram a subir.
Hooks
hooks:
build: # durante o build, dentro da imagem: o resultado fica nela
- npm run build
restart:
before: # em cada unidade, antes de ela (re)iniciar
- ./scripts/warmup.sh
after: # em cada unidade, depois que ela está no ar
- python manage.py migrateProcessos
Sem processes, vale o Procfile. Com os dois, processes ganha. Cada processo vira um conjunto próprio de unidades, que você escala separado (goship app scale).
processes:
- name: web
command: gunicorn app:app --bind 0.0.0.0:$PORT
healthcheck:
path: /ready
- name: worker
command: python worker.pyUm processo pode ter o seu healthcheck e startupcheck, e declarar portas além da padrão:
processes:
- name: web
command: ./server
ports:
- name: http
protocol: TCP
port: 80
target_port: 8888Deploy com Dockerfile
Num build de imagem, a plataforma lê a configuração de dentro da imagem, no diretório de trabalho. Então o Dockerfile precisa copiar o arquivo:
WORKDIR /app
COPY goship.yaml ./Compatibilidade com arquivos antigos
Projetos que já têm o arquivo de configuração de uma plataforma anterior continuam funcionando sem mexer em nada: o arquivo é lido como sempre foi, e as chaves da seção de plataforma acima são as mesmas. Quando o projeto tem os dois, vale a seção de plataforma do goship.yaml e o outro arquivo é ignorado.
Um goship.yaml que só tem chaves do CLI não toma o lugar de ninguém.