Providers e endpoints

Algumas tasks precisam alcançar algo vivo enquanto rodam: um banco para a migração, um proxy SOCKS para um cluster privado, um Redis descartável para um teste de ponta a ponta. O contrato declara essa necessidade com um único tipo:

dependencies:
  db:
    type: endpoint/tcp

O worker recebe um endereço pela variável que a implementação mapeia — DB (host:porta), mais DB_HOST e DB_PORT já separados — e nada além disso. Ele não consegue dizer de onde o endereço veio, e esse é o ponto: a task nunca muda entre ambientes; só a fiação muda.

Três origens, uma dependência

# Um endereço roteável — produção, um serviço na rede, qualquer coisa já alcançável.
db: "10.20.0.5:5432"

# Um serviço DESTA máquina — só em dev. `localhost` dentro de um container é o
# container; `host:` atravessa o engine de volta até a sua máquina.
db: host:5432

# Um provider — um container de serviço que vive e morre com o step.
db:
  provider: techlite/cloud-sql-proxy@^1.0.0
  inputs: { instance: "projeto:regiao:banco" }
  dependencies:
    gcpCredential: ${env.OREN_GCP_CREDENTIAL}

Ponha a divisão nas propriedades por ambiente: o arquivo de dev fia host:5432, o de CI fia um provider, produção fia o endereço real — e o oren.yaml não muda uma linha.

host: nunca chega ao CI

host: é local por definição — no CI, “o host” é o runner, e não há nada escutando lá. O oren generate recusa uma pipeline fiada em host:, apontando de volta para as properties.

O que é um provider

Um provider é um container conectado à rede do step, iniciado antes do worker e morto com ele. A porta aberta é o portão de prontidão: o step só começa quando o serviço aceita conexões. Nada sobrevive ao step — um banco descartável é descartado de verdade.

A referência pode ser:

• publicada — provider: techlite/gke-iap-proxy@^1.0.0, resolvida do catálogo pelo oren install como qualquer task;
• um documento local — provider: local/meu-proxy@^1.0.0, lido de .oren/registry/*.provider.yaml no projeto;
• inline — provider: { image: redis:7, port: 6379 }, identidade por digest, para o caso pequeno demais para merecer documento.

Um provider declara as próprias dependências — a credencial que o túnel precisa, que o contrato da task nunca menciona — e as entradas dele parametrizam o caminho até o serviço (qual bastion, qual zona). Ambas usam a mesma gramática de um step.

Compondo o endereço

Só dependências endpoint são legíveis em expressões, porque o valor delas é a única coisa que o pipeline precisa e possui por direito:

inputs:
  databaseUrl: "postgres://app@${dependencies.db.host}:${dependencies.db.port}/app"

address, host e port releem a fiação — com um literal você recebe o que escreveu; com um provider, o endereço que o runner atribuiu.

O que a autorização cobre

O portão de consentimento precifica o arranjo inteiro: a imagem do provider (cravada em digest pelo oren install, como a do worker), as dependências que o próprio provider consome, e — para host: — o fato de o step alcançar os serviços desta máquina. Trocar qualquer parte invalida a concessão, exatamente como trocar a imagem do worker.

Vendo tudo isso

oren explain <pipeline> -o pipeline.html

desenha a pipeline como cartões — as dependências, entradas e saídas de cada step, o provider ao lado do step que o consome, e os fios entre eles, com um cadeado onde um segredo viaja. oren trace desenha a última execução em cascata. Veja a referência da CLI.