Uma interface que pode ser revista
Uma role reutilizável precisa de tornar explícito o que recebe, que valores admite e que efeitos produz. No laboratório original, role_port tem default 8080 e a interface exige um inteiro dentro de 7070, 8080 e 9090. O corpo apenas escreve um ficheiro temporário; não abre uma porta de rede. Este contrato permite rever entradas antes da tarefa principal. Para uma role de middleware, documenta também significado, unidade e compatibilidade de cada parâmetro. Um inteiro válido pode continuar a ser inadequado para uma aplicação ou uma mudança concreta.
Seguir o valor efetivo até à origem
Três execuções controladas produzem 8080 com o default, 9090 com uma variável de inventário e 7070 com extra vars em JSON. O resultado ensina precedência no contexto observado, não uma regra baseada na última linha de um ficheiro. O laboratório também define policy_label no play e em vars da role: prevalece role-policy. Para um valor que os consumidores devem configurar facilmente, defaults é uma opção diferente de vars. Na revisão de uma mudança, regista as origens efetivas, incluindo o inventário e as entradas do pipeline, sem incluir segredos no relatório.
Validar entradas sem presumir uma transação
A entrada invalid-port é rejeitada pela validação da role e o ficheiro do corpo não é criado. Essa observação delimita a execução desta role. Não prova que nenhum passo anterior tenha alterado o ambiente. A documentação descreve ainda a validação de dependências antes da role que delas depende. Num pipeline fictício, uma preparação anterior pode já ter criado diretórios. Antes de repetir, identifica as tarefas realmente executadas e os efeitos existentes. Uma falha de interface informa sobre um contrato incumprido; não constitui um rollback global nem uma aprovação automática de limpeza.
Exposição dinâmica e confidencialidade
Com include_role e public=false, o default exposure_value existe dentro da role, mas não na tarefa seguinte. Com public=true, a observação anterior continua falsa e a seguinte passa a verdadeira. Esta exposição aplica-se às tarefas posteriores da inclusão dinâmica; não recalcula tarefas já executadas. O controlo também não protege automaticamente conteúdo emitido por debug. Para rever confidencialidade, usa marcadores fictícios e acompanha o percurso até logs e artefactos. Trata disponibilidade de variáveis e proteção de informação como requisitos distintos, com controlos próprios e acesso adequado ao output.
Compatibilidade e aceitação da role
Uma nova versão de uma role pode aceitar o mesmo tipo e mudar o significado do parâmetro. Revê o contrato, as dependências e os consumidores antes de atualizar a referência do pipeline. A validação de argumentos é apenas uma camada. Uma role que produz configuração precisa ainda de demonstrar que o candidato é adequado, que a publicação ocorreu no alvo correto e que o processo utiliza a geração pretendida. O laboratório não executa um serviço real, pelo que o ficheiro produzido só comprova seleção e escrita de valores neste executor local.
Oficina de aprovação de uma porta
No caso fictício, a mudança aprova 8080 e a firewall só permite essa porta. Um override seleciona 7070, que pertence às escolhas válidas da role. A ação adequada é suspender a aplicação e alinhar o valor efetivo com a decisão aprovada, ou obter uma alteração de âmbito com as dependências revistas. Prepara a evidência com versão da role, origens de variáveis e valor resultante. Em inglês, comunica: “The input passes role validation, but it differs from the approved port.” Esta formulação separa o comportamento técnico da decisão ainda necessária.
Role default: 8080; inventário: 9090; extra vars: 7070. Os três resultados foram escritos em ficheiros temporários por ansible-core 2.21.4, sem ligações a aplicações.
Armadilhas comuns
Confundir choices com autorização; usar vars para toda a configuração; presumir que public protege logs; interpretar uma validação falhada como reversão de tarefas anteriores.
Tópicos relacionados: Tarefas e estado pretendido · Orquestração por lotes · Falhas e recuperação
Uma interface verificável precisa de origem dos valores, limites explícitos e critérios de resultado. Passar a validação da role não demonstra ativação nem aprovação operacional.
Referência: Reusing Ansible artifacts: roles · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation