Skip to content

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.py

goship 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

ChaveO que faz
appnome do app; sem ela, o nome do diretório
orgorganização do projeto, no lugar do goship org use
projectprojeto 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
platformgo, python, nodejs ou static, usada ao criar o app
dockerfileconstrói a partir desse arquivo em vez de uma plataforma
environmentambiente 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
planplano usado ao criar o app; goship plans lista os do ambiente
envvariá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ção

No 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 migrate

Processos

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.py

Um 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: 8888

Deploy 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.