Introdução
A Small Frame Studio precisa que Ava e Noah trabalhem em dois hosts preparados enquanto Maya mantém seu acesso e suas notas. Você criará contas de pessoal dentro do escopo com Ansible, usará suas identidades SSH reais e transformará uma declaração individual em uma lista reutilizável da equipe.
Você precisa de navegação básica no terminal e prática lendo um pequeno inventário e playbook do Ansible. Este laboratório explica os conceitos necessários de conta Linux, chave SSH, permissões, lookup e loop antes do uso. Todas as chaves de treinamento, identidades confiáveis dos hosts e a coleção separada estão preparadas.
Dê a Ava um login funcional
Nesta etapa, você criará uma conta do curso em dois hosts do estúdio, autorizará sua chave de treinamento e usará essa identidade para salvar um arquivo real de trabalho.
A Small Frame Studio armazena notas editoriais diferentes em web1 e web2. Maya já trabalha nos dois; Ava precisa de acesso sem perder o trabalho de Maya. Os alvos preparados são dois contêineres SSH que compartilham o kernel da VM de treinamento, não VMs independentes. O Ansible roda no controlador e se conecta como a conta automation preparada. As contas da equipe existem apenas dentro desses alvos do curso.
Abra Controller. Ele começa no diretório do projeto. Este comando também permite voltar após entrar no diretório errado:
cd /home/labex/project
Leia o inventário e os dados aprovados da equipe com cat, que exibe arquivos sem alterá-los:
cat inventory.ini
cat approved-staff.json
A lista final contém studio_ava e studio_noah para os dois hosts. Começaremos com Ava e depois ampliaremos o mesmo trabalho para uma lista. Mantenha essas entradas aprovadas, o inventário e as configurações SSH preparadas inalterados.
SSH autentica um usuário em um host remoto. Uma chave pública pode ser instalada no alvo; a privada correspondente fica no cliente e comprova sua posse. Aqui, training-keys/ contém chaves novas e descartáveis de treinamento, nunca credenciais pessoais reais. Arquivos terminados em .pub são públicos; o nome correspondente sem esse sufixo é privado. Não copie chaves privadas para os alvos nem imprima seu conteúdo.
Leia a configuração preparada do cliente:
cat clients.conf
Cada alias, como web1-maya, seleciona alvo, usuário do curso e chave privada. -F clients.conf diz ao ssh para usar essa configuração do projeto. Ela fixa chaves de host confiáveis, desativa pedidos de senha e reutilização de conexões e oferece somente a identidade escolhida. A chave do host identifica o servidor; a pública do usuário autoriza a pessoa. São funções diferentes. Não desative nenhuma verificação de confiança.
Primeiro observe uma identidade funcional da equipe. O texto entre aspas simples é um comando executado no host remoto. O ponto e vírgula separa ali dois comandos: identificar o usuário e depois ler o arquivo local de trabalho.
ssh -F clients.conf web1-maya 'id -un; cat work/briefing.txt'
Ele imprime studio_maya e as notas do estúdio Riverside. Leia o outro host com uma conexão nova:
ssh -F clients.conf web2-maya 'id -un; cat work/briefing.txt'
A identidade é a mesma, mas as notas são diferentes, do estúdio Hill. Preserve os dois arquivos. Agora a conexão de Ava deve falhar porque sua conta e autorização ainda não existem:
ssh -F clients.conf web1-ava 'id -un'
Espere Permission denied (publickey) e status de saída 255, não um pedido de senha. Um tempo limite de conexão ou aviso de chave de host é outro problema: volte ao diretório do projeto e confira o inventário/configuração inalterados em vez de enfraquecer a confiança SSH.
Um usuário Linux tem diretório pessoal, shell de login e grupo primário. O módulo user cria a conta e, nesses alvos preparados, seu grupo primário de mesmo nome. create_home: true cria o diretório pessoal. become: true usa a elevação de privilégios autorizada da conta automation preparada nos alvos; não altera o login do LabEx.
Escreva um playbook completo. Neste here-document, > substitui o arquivo indicado do controlador e o delimitador YAML entre aspas impede a expansão pelo shell. Coloque o delimitador final sozinho no início de uma linha. Se digitar um bloco errado, execute-o inteiro novamente para substituir esse arquivo. Se o shell ainda estiver esperando um delimitador final ausente, pressione Ctrl+C para cancelar a entrada incompleta e execute o bloco completo a partir do prompt normal. YAML usa espaços para aninhar e - para itens de lista.
cat > access.yml <<'YAML'
- name: Give Ava access to the studio hosts
hosts: all
become: true
gather_facts: false
tasks:
- name: Create Ava's course account
ansible.builtin.user:
name: studio_ava
shell: /bin/bash
create_home: true
- name: Keep Ava's home private
ansible.builtin.file:
path: /home/studio_ava
state: directory
owner: studio_ava
group: studio_ava
mode: '0750'
- name: Create Ava's work directory
ansible.builtin.file:
path: /home/studio_ava/work
state: directory
owner: studio_ava
group: studio_ava
mode: '0750'
- name: Authorize Ava's public key
ansible.posix.authorized_key:
user: studio_ava
key: "{{ lookup('file', 'training-keys/ava.pub') }}"
state: present
YAML
O módulo file gerencia propriedade e permissões de diretórios, não o conteúdo de arquivos existentes de trabalho. O modo 0750 dá acesso total ao proprietário, leitura/travessia ao grupo primário e nenhum acesso aos demais usuários; as aspas nos dígitos evitam a interpretação numérica do YAML. lookup lê uma chave pública do controlador. Chaves duplas avaliam essa expressão. state: present adiciona essa chave e preserva as outras; não substitui o arquivo inteiro de chaves da conta.
Módulos que começam com ansible.builtin vêm com Core. ansible.posix.authorized_key pertence a uma coleção separada, instalada offline para este projeto. Ele cria o diretório .ssh do usuário com modo 0700 e authorized_keys com modo 0600, pertencentes ao usuário e seu grupo primário. Você não precisa instalar uma coleção nem editar configurações do servidor SSH.
Confira primeiro a sintaxe YAML/playbook:
ansible-playbook access.yml --syntax-check
Em caso de erro, leia o arquivo/linha indicado, compare espaços e aspas com o bloco completo, reescreva e repita. Não é necessário reiniciar a VM. Uma prévia em check mode não é confiável para essa criação inicial: a tarefa posterior de chaves não pode usar uma conta cuja criação uma tarefa anterior apenas previu. Aplique a criação declarada e use check mode depois que as contas existirem:
ansible-playbook access.yml
Ambos os hosts devem terminar sem alvos inacessíveis ou tarefas com falha. Agora entre como Ava e salve sua identidade real. Dentro das aspas remotas, umask 027 limita arquivos novos a no máximo 0640; > grava a saída de id no arquivo de chegada; cat o lê novamente. A configuração vale somente para o shell desse comando remoto.
ssh -F clients.conf web1-ava 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'
ssh -F clients.conf web2-ava 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'
Ambos imprimem studio_ava. Você usou um login real de pessoal e escreveu um arquivo, além de apenas obter um resumo Ansible bem-sucedido. Os arquivos separados e o login de Maya devem continuar funcionando.
Reutilize a declaração para uma lista da equipe
Nesta etapa, você substituirá detalhes repetidos das contas por dados estruturados e um loop, adicionará Noah e confirmará a convergência sem alterar o trabalho existente.
Permaneça em Controller, em /home/labex/project. Cada entrada precisa de um usuário do curso e do caminho de sua chave pública no controlador. O diretório preparado group_vars está vazio. Um arquivo chamado group_vars/all.yml fornece variáveis a todos os hosts do inventário. Escreva a lista aprovada de duas pessoas:
cat > group_vars/all.yml <<'YAML'
staff:
- name: studio_ava
key_file: training-keys/ava.pub
- name: studio_noah
key_file: training-keys/noah.pub
YAML
Um host_vars/web1.yml correspondente pode fornecer uma lista apenas para web1; valores do host substituem os padrões compartilhados do grupo. Esta unidade usa a mesma lista nos dois hosts, enquanto o challenge fornece listas aprovadas diferentes. As tarefas reutilizáveis não precisam mudar.
Um loop repete uma tarefa para cada entrada de staff. item.name lê o nome atual e item.key_file o caminho de sua chave pública. A mesma lista controla criação de contas, diretórios e autorizações. Substitua o playbook individual pela versão reutilizável:
cat > access.yml <<'YAML'
- name: Manage the approved studio staff
hosts: all
become: true
gather_facts: false
tasks:
- name: Create each course account
ansible.builtin.user:
name: "{{ item.name }}"
shell: /bin/bash
create_home: true
loop: "{{ staff }}"
- name: Keep each home private
ansible.builtin.file:
path: "/home/{{ item.name }}"
state: directory
owner: "{{ item.name }}"
group: "{{ item.name }}"
mode: '0750'
loop: "{{ staff }}"
- name: Create each work directory
ansible.builtin.file:
path: "/home/{{ item.name }}/work"
state: directory
owner: "{{ item.name }}"
group: "{{ item.name }}"
mode: '0750'
loop: "{{ staff }}"
- name: Add each approved public key
ansible.posix.authorized_key:
user: "{{ item.name }}"
key: "{{ lookup('file', item.key_file) }}"
state: present
loop: "{{ staff }}"
YAML
Mantenha o comportamento não exclusivo padrão. Uma operação exclusiva de chaves em um loop pode remover outra chave legítima de uma iteração anterior. Este projeto adiciona chaves específicas e depois remove uma chave antiga específica; não substitui o conjunto completo de chaves de todos.
Confira a sintaxe e aplique. Noah ainda não existe, portanto a limitação de check mode para a criação inicial continua válida.
ansible-playbook access.yml --syntax-check
ansible-playbook access.yml
Ava não deve precisar de novas mudanças; Noah é criado nos dois alvos. Leia os resultados por item e confirme unreachable=0 e failed=0 nos dois resumos. Use a identidade real de Noah para criar seu próprio arquivo de trabalho:
ssh -F clients.conf web1-noah 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'
ssh -F clients.conf web2-noah 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'
Ambos imprimem studio_noah. Os arquivos de chegada de Ava continuam sendo dela; as notas de Maya permanecem inalteradas. Leia-os pelas identidades originais:
ssh -F clients.conf web1-ava 'cat work/arrival.txt'
ssh -F clients.conf web2-ava 'cat work/arrival.txt'
ssh -F clients.conf web1-maya 'cat work/briefing.txt'
ssh -F clients.conf web2-maya 'cat work/briefing.txt'
Agora todos os usuários necessários existem. --check prevê mudanças compatíveis sem aplicá-las:
ansible-playbook access.yml --check
Os dois resumos devem mostrar changed=0, unreachable=0 e failed=0. Repita a declaração real:
ansible-playbook access.yml
Ela também deve informar nenhuma mudança. Isso é idempotência para contas, diretórios e autorizações de chaves declarados; acessos SSH comuns ainda podem escrever logs de login do sistema. O mesmo loop pode consumir outra lista aprovada sem reescrever sua implementação.
Se um login falhar, verifique o alias e a identidade escolhidos e compare o caminho da chave pública e o usuário com os dados aprovados. Corrija a declaração do controlador e aplique novamente. Não corrija uma autorização ausente copiando chave privada para um alvo, tornando o diretório pessoal gravável por todos ou desativando a confiança do servidor.
Resumo
Você criou contas do curso, diretórios privados de trabalho e autorizações de chaves públicas; usou identidades SSH reais para salvar trabalho; substituiu a repetição individual por um loop estruturado da equipe; e confirmou a convergência preservando o acesso e as notas existentes.
