Task Runner + Survey Variables: delegando Ansible sem entregar a administração do Semaphore

Uma plataforma de automação só começa a escalar de verdade quando outras pessoas conseguem executar rotinas sem depender do autor do playbook.

Mas existe uma diferença grande entre:

deixar alguém executar uma receita pronta

e:

deixar alguém editar repositório, inventory, credencial, variável e template antes de clicar em Run.

Na plataforma Ansible + Semaphore que originou este artigo, a solução foi separar essas responsabilidades.

Operadores recebem um papel de Task Runner para executar templates preparados, enquanto a administração da automação permanece restrita.

O que o operador não precisa editar #

O modelo documentado evita que o operador comum altere:

• repositórios;
• inventories;
• Variable Groups;
• key store;
• templates.

Isso muda a experiência.

Em vez de entrar no Semaphore para “montar uma execução”, a pessoa escolhe uma operação conhecida e preenche apenas os dados daquela tarefa.

Survey é a interface operacional do playbook #

Um playbook pode ter dezenas de variáveis internas.

Isso não significa que todas devem virar campos na interface.

O Survey deve expor somente decisões que pertencem ao momento da execução.

Na documentação do projeto aparecem campos como:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

target
cliente/projeto
ambiente
motivo
ticket
dry_run
service_name
container_name
domain
confirmacao

A combinação muda conforme a receita.

Não pergunte o que o projeto já sabe #

Um erro comum é transformar toda variável em pergunta.

Se um projeto tem profiles cloud fixos, não faz sentido pedir ao operador toda vez:

1
2

AWS_PROFILE = ?
OCI_CLI_PROFILE = ?

Esses valores pertencem ao contexto do projeto e podem ficar em Variable Group.

O operador decide:

1
2
3
4

qual alvo?
qual ambiente?
qual serviço?
qual ticket/motivo?

Não qual credencial estrutural a plataforma deve usar.

Menos campos também é segurança #

Survey enorme cria dois problemas:

1. o operador precisa entender detalhes internos do playbook;
2. aumenta a quantidade de combinações inválidas.

Uma interface curta reduz ambiguidade.

Para um diagnóstico LOW, talvez baste:

1
2
3

target
motivo
ticket

Para uma mudança HIGH:

1
2
3
4
5
6

target
ambiente
motivo
ticket
dry_run
confirmacao

O risco da operação define quanto contexto precisa ser explicitado.

target merece tratamento especial #

Em Ansible, o alvo é parte do blast radius.

Um valor como:

1

all

pode ser perfeitamente aceitável num inventário read-only e perigoso num restart.

Então eu não trataria target como um texto livre sem regra em qualquer template.

Dependendo da operação, vale usar:

• opções predefinidas;
• grupos conhecidos;
• validação por regex/lista;
• --limit obrigatório;
• bloqueio de all;
• confirmação adicional para grupos amplos.

ambiente deixa a intenção visível #

Outro campo útil é:

1
2
3
4

dev
hmg
prod
teste

Mesmo que o inventory já encode ambiente, pedir essa confirmação pode ser útil em templates de mudança.

Não para duplicar configuração, mas para criar contexto explícito na execução e nos logs.

motivo e ticket parecem burocracia até o primeiro incidente #

Automação produz histórico técnico:

1
2
3
4

quem executou
quando executou
qual template
qual output

Mas isso não necessariamente explica por que.

Campos simples de motivo e referência ajudam depois:

1
2

motivo: corrigir configuração do agente
referência: CHG-1234

Quando a operação toca produção, esse contexto vale muito.

dry_run só deve existir se tiver semântica real #

Colocar um checkbox chamado dry_run que o playbook ignora é pior do que não ter.

O campo precisa mapear para comportamento real, como:

• --check quando suportado;
• consulta sem alteração;
• geração de diff;
• validação preflight;
• modo de simulação implementado pelo playbook.

Se módulos/shells não suportam check mode corretamente, isso precisa estar documentado.

Confirmação em mudança crítica #

O padrão do projeto prevê campo explícito de confirmação para HIGH/DANGER.

Uma checagem simples:

1
2
3
4
5

- name: Bloquear sem confirmação
  ansible.builtin.assert:
    that:
      - confirmacao | default('') == 'SIM'
    fail_msg: "Execução bloqueada. Informe confirmacao=SIM."

Ou equivalente no shell/preflight.

Não substitui RBAC.

Serve como uma segunda intenção explícita dentro do fluxo.

Task Runner reduz risco de mudança da receita #

Se um operador pode alterar o inventory momentos antes de executar um template, a aprovação do template perde valor.

Se ele pode alterar o repository/ref, pode executar código diferente do revisado.

Se pode editar key store, muda a identidade da automação.

O modelo Task Runner cria uma fronteira:

1
2

responsável técnico → constrói/revisa/publica receita
operador           → escolhe receita aprovada e parâmetros permitidos

Isso aproxima automação de um catálogo de operações.

O nome do template também é interface #

Uma convenção útil documentada no projeto:

1
2
3
4
5
6

Smoke - Ansible/AWS/OCI
Diagnóstico - Health Check
Diagnóstico - Logs Container
CHANGE - Reiniciar Container
CHANGE - Resize OCI
DANGER - Remover/Destruir Recurso

O nome já comunica intenção e risco antes de abrir o Survey.

Um Survey não corrige um playbook inseguro #

É importante não superestimar a interface.

Mesmo com Survey perfeito, o playbook precisa proteger:

• alvo vazio;
• variáveis inválidas;
• execução concorrente;
• estado inesperado;
• rollback;
• validação pós-mudança.

A interface reduz erro de entrada.

O playbook continua responsável por segurança operacional.

O que a fonte sustenta #

A documentação privada da plataforma registra:

• operadores definidos como Task Runner;
• intenção de não permitir edição de repository, inventory, Variable Group, key store ou template;
• padrão de Survey Variables;
• campos diferentes para LOW/MEDIUM/HIGH/DANGER;
• profiles cloud mantidos fora do Survey quando já pertencem ao Variable Group;
• confirmação explícita para operações críticas;
• critérios mínimos para liberar um template aos operadores.

O artigo não afirma que todo template existente já aplica todos esses controles; descreve o modelo documentado para a plataforma.

O principal aprendizado #

Delegar automação não deveria significar entregar uma shell web sobre produção.

O desenho que considero mais seguro é:

1
2
3
4
5
6
7
8
9

receita revisada
+
contexto fixo do projeto
+
Survey pequeno
+
permissão de execução
+
guardrails no playbook

Assim outra pessoa consegue operar sem precisar reconstruir — ou modificar — a automação antes de cada execução.