Introdução
A Willow Commons já tem um site comunitário funcionando. Antes de movê-lo, descubra qual endereço um cliente realmente utiliza. Um registro DNS salvo, uma resposta em cache e uma resposta do site descrevem partes diferentes do caminho.
Você usará primeiro o site normal, comparará um servidor autoritativo real com um resolvedor de cache independente e alterará um nome de prática separado. O nome do site usado pela comunidade não muda nesta unidade. Dois backends HTTP e os serviços DNS estão preparados em namespaces de rede Linux isolados que compartilham o kernel de uma única VM.
Você deve saber digitar comandos no terminal, reconhecer caminhos e trocar de aba. Este laboratório explica os comandos DNS e as pequenas edições de configuração utilizados. Não é necessária uma conta de domínio público nem experiência prévia de administração do BIND. Reserve cerca de 40 minutos, incluindo leitura e erros comuns; essa é uma estimativa do autor.
Usar o site funcional pelo nome
Nesta etapa, você lerá o site atual da comunidade e salvará sua programação real. Comece em Community Preview e selecione Warm Client. Você deve ver a página da Willow Commons, três encontros e a identificação old location. Selecione Download the programme e abra o texto baixado. A identificação de local indica o backend; não é uma animação de sucesso.
Leia a identificação de local perto do topo e use Download the programme abaixo dos três encontros. A página mostrada é uma resposta real do backend original.
A prévia faz uma consulta DNS e uma requisição HTTP reais a partir do cliente do curso selecionado. Sua URL externa da plataforma é um gateway para o navegador; ela não significa que seu computador usa o DNS do curso. Atualizar o navegador envia outra requisição sem limpar o cache do resolvedor do curso. Não use Fresh Client por enquanto.
Mude para o terminal Warm Client. Ele começa em /home/labex/project/site-move/warm, com suas próprias configurações de resolução. pwd mostra o diretório atual:
pwd
DNS, o Sistema de Nomes de Domínio, associa um nome a um endereço. Um registro A associa um nome a um endereço IPv4. Em seguida, HTTP usa esse endereço e uma porta para solicitar conteúdo. Aqui o nome é site.community.test; 8081 é a porta HTTP, não um valor de registro DNS. .test é um sufixo reservado para testes, não um domínio comunitário público.
curl faz uma requisição HTTP. --noproxy '*' exclui todos os proxies nesta requisição; as aspas mantêm o asterisco literal. -f trata erros HTTP como falhas, -s oculta o medidor de progresso e -S continua exibindo erros. --max-time 5 limita a requisição a cinco segundos:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Você deve obter HTML contendo Willow Commons e old location. O terminal mostra o código-fonte; o navegador renderiza a mesma página. Agora baixe o recurso de texto real. -o programme.txt salva a resposta no diretório atual deste cliente:
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat mostra o arquivo salvo:
cat programme.txt
Você deve ver os três encontros, as informações de entrada sem degraus e Service location: old. A existência de um arquivo ou um status HTTP, isoladamente, não comprova que o conteúdo está correto.
Se curl informar Could not resolve host, confira a grafia do nome. Failed to connect significa que nenhuma conexão HTTP foi estabelecida; isso difere de HTTP 404, que significa que um servidor respondeu, mas o caminho não existia. Corrija o erro de digitação e repita a URL mostrada. Não altere o DNS da plataforma, /etc/hosts nem um arquivo do resolvedor do curso. Se abrir outro terminal, use a aba real Warm Client e execute cd /home/labex/project/site-move/warm antes de salvar. Arquivos e diretórios de trabalho pertencem a esse cliente; um download do navegador pertence ao seu navegador.
Comparar o servidor autoritativo e o cache
Nesta etapa, você distinguirá o registro de origem de uma cópia temporária em cache. Permaneça em Warm Client. O servidor autoritativo é responsável por community.test; seu endereço é 10.94.0.2. O resolvedor de cache do cliente escuta em 127.0.0.1, o endereço de loopback dentro deste cliente. O outro cliente tem um resolvedor e um cache separados.
dig faz uma pergunta ao DNS. @10.94.0.2 seleciona explicitamente o servidor. A solicita um endereço IPv4. +noall oculta as seções habituais do dig e +answer mostra as linhas de resposta:
dig @10.94.0.2 site.community.test A +noall +answer
Você deve obter uma linha neste formato:
site.community.test. 120 IN A 10.94.0.10
As colunas são nome, TTL, classe, tipo e endereço. TTL, tempo de vida, é o número de segundos que uma resposta pode permanecer em cache. IN é a classe Internet. O ponto final indica um nome DNS completo. Espaços e tabulações podem variar.
Consulte agora o resolvedor do cliente do curso:
dig @127.0.0.1 site.community.test A +noall +answer
O endereço deve continuar sendo 10.94.0.10, mas o TTL pode estar menor porque a requisição anterior preencheu o cache. sleep 5 espera cinco segundos reais sem alterar o DNS:
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Normalmente, o TTL restante diminui. Se a cópia anterior expirou, o resolvedor consulta novamente o servidor autoritativo e o TTL sobe para perto de 120. A leitura deste laboratório pode consumir todo o intervalo. Isso é expiração normal, não um cache com defeito. Não é necessário observar uma janela iniciada durante a preparação do ambiente.
Use um nome separado para a próxima edição. Ele aponta para o mesmo backend antigo, mas não é o nome oficial do site comunitário:
dig @127.0.0.1 practice.community.test A +noall +answer
Observe o nome, o endereço e o TTL restante. Uma consulta bem-sucedida não prova que o site é acessível; a etapa 1 fez a requisição HTTP separadamente. Execute a verificação desta etapa e leia a próxima antes de começar sua breve sequência de alteração e comparação.
Alterar um registro de prática e deixar o cache expirar
Nesta etapa, você validará uma pequena alteração de registro, a carregará no servidor autoritativo e verá por que um TTL menor não encurta uma cópia já armazenada em cache. Você só pode modificar practice e o serial SOA necessário em community.zone. Preserve o nome oficial site, keep, o servidor de nomes e os dois sites.
Primeiro leia as instruções de edição abaixo. Em Warm Client, consulte novamente o nome de prática imediatamente antes de mudar de aba:
dig @127.0.0.1 practice.community.test A +noall +answer
Se restarem poucos segundos, espere esse intervalo acabar e consulte novamente enquanto o servidor autoritativo ainda mantém o registro original. Isso renova a janela de observação por meio de uma requisição DNS real, sem limpar o cache. Uma cópia nova dura até 120 segundos. Trabalhe no seu ritmo e use o parágrafo de recuperação se perder a janela.
Mude para DNS Desk, cujo diretório é /home/labex/project/site-move. Leia o arquivo:
cat community.zone
Uma zona é o conjunto de dados autoritativos de uma parte do DNS. $TTL 120 fornece uma duração padrão. practice 120 IN A 10.94.0.10 define explicitamente a duração e o endereço do nome de prática. SOA, Start of Authority, inclui um número de versão chamado serial. Aumente esse número ao publicar uma alteração e preserve os outros valores SOA. As durações DNS e os temporizadores SOA têm finalidades diferentes. Aqui, @ representa a origem da zona, community.test.. NS identifica seu servidor autoritativo e o registro A de ns fornece o endereço desse servidor. Os parênteses agrupam os campos SOA em um único registro. Os valores existentes de atualização, repetição, expiração e cache negativo pertencem à administração da zona: não os altere. Eles não são o TTL do registro A de prática.
O here-document a seguir grava toda a pequena zona. > substitui o arquivo. As aspas de 'ZONE' mantêm $TTL literal, em vez de expandi-lo como variável do shell. O último ZONE deve começar no início da linha. Copie o bloco inteiro:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Somente endereço e duração de prática, além do serial, mudaram. named-checkzone valida toda a zona salva sem carregá-la. Seu primeiro argumento é o nome da zona; o segundo é o arquivo:
named-checkzone community.test community.zone
Você deve ver loaded serial 2 e depois OK. Isso é um resultado de validação de arquivo, não uma prova de que o servidor em execução o carregou. Se a sintaxe falhar, leia o arquivo, restaure o bloco completo e verifique novamente. Um arquivo salvo incorretamente deixa a zona anterior em execução disponível até uma recarga válida.
sudo executa este único comando administrativo. O auxiliar de escopo restrito fornecido chama o verdadeiro rndc reload community.test do BIND dentro do servidor autoritativo do curso; ele não reinicia nenhum cache:
sudo /opt/labex/site-move/reload-zone
Você deve obter zone reload queued. Consulte o servidor autoritativo em execução para confirmar o que foi realmente carregado. A estação não possui um resolvedor padrão do curso, por isso este diagnóstico entra explicitamente no namespace de rede do servidor autoritativo. ip netns exec site-authority executa somente o comando seguinte nessa rede do curso:
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Você deve obter 45 IN A 10.94.0.20. Mude para Warm Client e consulte seu cache:
dig @127.0.0.1 practice.community.test A +noall +answer
Durante a vida restante original, ele ainda pode retornar 10.94.0.10, mesmo com mais de 45 segundos restantes. O novo TTL de 45 segundos vale para cópias novas; não reescreve a resposta antiga em cache. Os dois backends continuam funcionando enquanto os clientes podem legitimamente receber respostas diferentes.
Espere o TTL restante observado mais um segundo e consulte novamente. Por exemplo, se ele mostrou 37 segundos, sleep 38 basta para essa cópia. A espera conservadora abaixo cobre o máximo original completo de 120 segundos, mesmo que você não tenha anotado o valor exato:
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Agora você deve obter 10.94.0.20 e um TTL restante não superior a 45. Leia a linha real: o término de um temporizador não prova nada sozinho. Faça uma requisição HTTP por nome no mesmo cliente:
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Você deve obter Service location: new com a programação completa. O nome oficial site.community.test continua servindo o local antigo.
Se você perdeu a diferença: o resultado concluído continua válido. Para repetir a observação, use apenas practice: em DNS Desk, restaure sua linha para practice 120 IN A 10.94.0.10 e aumente o serial SOA atual usando nano community.zone. nano é um editor de texto: mova-se com as setas, edite apenas essa linha e o serial, pressione Ctrl+O, Enter para salvar e Ctrl+X para sair. Valide e recarregue com os mesmos comandos acima. Espere o TTL atualmente observado do cliente de prática expirar naturalmente, consulte-o para obter o endereço antigo por até 120 segundos e altere apenas practice de volta para o endereço novo e 45 segundos, com outro serial maior. Valide, recarregue e compare imediatamente. Termine com expiração natural e uma requisição real ao site novo. Nunca redefina o site oficial, reinicie resolvedores nem substitua conteúdo dos sites para repetir uma janela.
Se digitou um caminho errado, use pwd e cd /home/labex/project/site-move em DNS Desk antes de reler o arquivo. Erros de sintaxe e conteúdo incorreto são problemas diferentes: valide o arquivo, inspecione o servidor autoritativo em execução, inspecione o cache e só então solicite HTTP. Execute a verificação final quando o cliente de prática resolver o endereço novo.
Resumo
Você usou um site funcional pelo nome, salvou sua programação completa e separou dados autoritativos, respostas DNS em cache e conteúdo HTTP. Validou uma alteração de prática limitada e viu que reduzir o TTL não encurta uma cópia já existente. O site comunitário oficial e o backend antigo continuam disponíveis. A próxima unidade aplica esse conhecimento a uma migração de endereço por etapas.
