# `runner switch-instance`

Move um app ja deployado para outra instancia — o caso classico e um servidor que subiu como production mas na verdade e staging.

Disponivel desde v2.80.2.

# Por que nao basta trocar o state

A instancia entra no nome do container ({project}_{instance}_{versao}) e no arquivo de rota do Traefik. Trocar so o state.instance nao renomeia nada: o proximo deploy sobe o segundo conjunto ao lado do primeiro, que continua servindo pela rota antiga.

Por isso `runner edit --instance` recusa a troca quando ha container no ar — e aponta para ca.

# Sintaxe

runner switch-instance <app> --to <instancia>            # plano (dry-run)
runner switch-instance <app> --to <instancia> --force    # executa
runner switch-instance <app> --to staging --branch dev --force

# Flags

# O plano, antes de qualquer coisa

MIGRAÇÃO meu-app · production → staging

  1. state.instance = 'staging'
  2. deploy em 'staging' (health + rota)
  3. destroy de 'production':
       containers (1):
         - meu_app_production_v2-5-1
       arquivo(s) de rota do Traefik: 1

  O passo 3 só roda se o 2 passar no health. Deploy quebrado
  devolve o state ao original e não remove nada.

Nada foi alterado. Para executar: --force

# A ordem e deliberada

EDIT → DEPLOY → DESTROY, nesta ordem.

A alternativa natural (DESTROY → EDIT → DEPLOY) satisfaria a pre-condicao do edit sem truque, mas troca uma falha recuperavel por indisponibilidade: um deploy quebrado deixaria nada rodando.

Na ordem adotada, deploy quebrado devolve o state.instance ao valor original e a instancia antiga segue no ar — nada foi removido ainda.

Falhar na etapa 3 daria a impressao de que a migracao nao aconteceu — ela aconteceu; o que sobrou foi lixo a limpar.

# Por que e um comando do runner, e nao um encadeamento seu

Duas falhas que so o runner consegue fechar:

• O cron. fetch --deploy roda a cada 5 minutos, e entre um edit e um deploy feitos a mao cabe um ciclo inteiro: ele encontraria o state ja trocado e deployaria a instancia nova por conta propria. O switch-instance segura o AppLock nas tres etapas.
• O health. Quem autoriza destruir a instancia antiga e o health check da nova, que o pipeline conhece de primeira mao.

# No historico

O deploy da etapa 2 fica marcado com origem switch-instance — quem ler o audit depois distingue de um deploy comum.

# Ver tambem

• `runner edit` — a guarda que aponta para ca
• `runner destroy`
• instances
• `.deploy.yml` — declarar a instancia de destino