← Ansible: automatizar alterações e recuperar serviços
10 / 12 · 60 MIN

Roles, interfaces e origem dos valores

Desenha interfaces configuráveis, interpreta precedência e separa validação de argumentos, âmbito de variáveis e autorização operacional.

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.

NA PRÁTICA

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

Leva esta ideia contigo

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.

Criar conta

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

Ansible é uma marca comercial de Red Hat, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Red Hat. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.