Introdução
O Ansible pode estar instalado corretamente e ainda assim usar o inventário, o interpretador ou os privilégios errados. Um projeto confiável torna essas escolhas explícitas e confirma seu efeito em destinos reais.
Neste laboratório, você criará uma configuração de projeto, inspecionará os valores carregados, definirá o Python de destino pelo inventário e comparará a execução comum com a elevação explícita de privilégios em dois nós SSH preparados. Este ambiente independente fornece o Ansible e as conexões; não é necessário instalar pacotes nem alterar servidores SSH.
Criar e carregar a configuração do projeto
Nesta etapa, você criará uma configuração de projeto e confirmará que o Ansible realmente a carrega.
Você já instalou o Ansible no laboratório anterior. Este ambiente independente fornece a instalação compartilhada do curso para que você possa se concentrar na configuração. Abra o Terminal e selecione o espaço de trabalho:
cd /home/labex/project
O Ansible usa um único arquivo de configuração, escolhendo o primeiro disponível entre ANSIBLE_CONFIG, o ansible.cfg do diretório atual, a configuração do diretório pessoal do usuário e a configuração do sistema. Portanto, mudar de diretório pode alterar a configuração de projeto carregada. Uma variável de ambiente pode selecionar outro arquivo mesmo quando existe um arquivo no projeto.
O arquivo preparado connection-reference.cfg contém as configurações originais de conexão do treinamento. cat o exibe:
cat connection-reference.cfg
Ele seleciona o inventário do projeto e um arquivo de chaves de host confiáveis. O laboratório já criou as chaves e os nós; não altere seu login na plataforma nem o servidor SSH.
Crie o ansible.cfg abaixo. cat > grava a entrada padrão em um arquivo, substituindo o conteúdo existente. <<'EOF' inicia um here-document: cole todas as linhas até o EOF final. As aspas no marcador mantêm o texto literal. Os nomes de seções INI entre colchetes agrupam configurações, e cada linha name = value define uma opção.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory seleciona a lista de hosts. host_key_checking mantém as verificações de identidade do servidor ativadas. interpreter_python define o Python padrão do destino, não o interpretador do controlador. become = False mantém as tarefas comuns sem privilégios elevados. Os ssh_args preparados usam o arquivo known_hosts do treinamento, exigem chaves confiáveis e reutilizam conexões SSH de curta duração.
Exiba as informações de versão e configuração:
ansible --version
Encontre config file = /home/labex/project/ansible.cfg. O caminho do módulo pertence à instalação compartilhada do curso neste laboratório; seu exercício anterior de instalação usou um ambiente separado do aluno.
ansible-config dump mostra a configuração efetiva. --only-changed limita a saída às configurações diferentes dos padrões e identifica a origem de cada uma:
ansible-config dump --only-changed
Procure CONFIG_FILE() = /home/labex/project/ansible.cfg, um DEFAULT_HOST_LIST do projeto e INTERPRETER_PYTHON definido como /usr/bin/python3. A saída usa nomes internos de opções que podem diferir da grafia no INI. Apenas ler um arquivo não comprova que o Ansible o carregou.
Teste a configuração do projeto com o módulo ping Python que você já conhece:
ansible all -m ansible.builtin.ping
Tanto web1 quanto web2 devem retornar pong. Execute os comandos neste espaço de trabalho para manter ativa a configuração pretendida.
Definir o interpretador de destino no inventário
Nesta etapa, você definirá uma variável de conexão para os dois hosts e entenderá sua relação com o padrão do projeto.
Leia o inventário preparado:
cat inventory.ini
Ele tem dois destinos ansible_host distintos, seguidos por [all:vars]. As configurações após essa seção se aplicam aos dois hosts, incluindo ansible_user=automation e o caminho da chave privada de treinamento. Elas descrevem a conta SSH e a autenticação nos nós gerenciados.
Uma variável de conexão chamada ansible_python_interpreter substitui o padrão de configuração interpreter_python para seus hosts. Use-a quando um inventário precisar de um interpretador de destino específico. Um padrão correto não pode compensar uma variável de inventário que aponta para um executável inexistente.
printf imprime texto; \n significa uma quebra de linha. >> acrescenta sem substituir o inventário existente. Acrescente a variável de interpretador sob a seção [all:vars] existente:
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
Exiba novamente o inventário e encontre a nova configuração abaixo de [all:vars]:
cat inventory.ini
A instalação Python do controlador permanece inalterada. Esse caminho será executado separadamente dentro de cada nó gerenciado. Teste os dois destinos:
ansible all -m ansible.builtin.ping
Cada um ainda deve retornar pong e changed: false. Agora você tem uma configuração de interpretador funcional por inventário, além de um padrão do projeto. A saída de configuração descreve os padrões; as variáveis de conexão podem substituí-los durante a execução.
Comparar a execução comum e a elevada
Nesta etapa, você observará o usuário remoto real antes e depois da elevação explícita de privilégios.
O módulo command executa um programa no destino. -a fornece os argumentos do módulo; coloque id -un entre aspas para que o shell passe o programa e sua opção como uma única string de argumentos. id -un imprime o nome do usuário efetivo:
ansible all -m ansible.builtin.command -a 'id -un'
Os dois hosts devem informar automation. Essa é a conta do nó gerenciado selecionada pelo inventário, não o usuário labex do controlador.
--become solicita a elevação de privilégios para esta invocação. Os nós de treinamento permitem que a conta automation use sudo sem senha; o padrão do projeto ainda mantém a elevação desativada para execuções comuns:
ansible all -m ansible.builtin.command -a 'id -un' --become
Os dois hosts devem informar root. O módulo command do Ansible normalmente informa CHANGED quando executa um comando, mesmo para esta consulta de identidade somente leitura. Esse rótulo, por si só, não comprova que uma configuração do sistema mudou; interprete a saída stdout real e o status de retorno.
Repita sem --become:
ansible all -m ansible.builtin.command -a 'id -un'
A saída volta a ser automation. A elevação foi explícita para uma invocação, em vez de ser uma alteração permanente da conta de login. Deixe a elevação global desativada e mantenha inalterada a configuração de contas da plataforma.
Resumo
Você criou e carregou uma configuração de projeto, inspecionou os padrões efetivos e forneceu um interpretador de destino de maior prioridade pelo inventário. A execução real de módulos por SSH confirmou os dois destinos, e as consultas de identidade demonstraram a diferença entre o acesso comum de automation e o uso explícito de become. Essas verificações fornecem uma base para diagnosticar configurações de conexão sem alterar o acesso à plataforma.
