Introdução
Um endpoint de integridade é uma URL pequena que informa se uma aplicação está respondendo. Neste laboratório, você escreverá um Cloudflare Worker em JavaScript, testará sua resposta JSON dentro do LabEx, publicará o mesmo código em uma URL pública workers.dev, inspecionará um log de solicitação e removerá a implantação de teste.
Use sua própria conta de aprendizagem, com e-mail verificado e Workers Free, preparada em Prepare Your Cloudflare Learning Account. Você deve reconhecer o fluxo de autorização do dispositivo apresentado em Connect LabEx to Your Cloudflare Account e conhecer o básico de JavaScript. Esta VM nova precisa de uma autorização própria, incluindo permissão para implantar e excluir Workers. Não é necessário ter domínio comprado, banco de dados ou upgrade pago. Sua resposta de teste será pública e conterá apenas dados de exemplo.
A configuração já instalou o Node.js 22.22.0 e o Wrangler 4.131.1, instalado localmente no projeto, em /home/labex/project/first-worker. Você usará o Wrangler para consultar informações da conta e o curl para testar respostas; essas ferramentas também funcionam fora do LabEx. Você escreverá o Worker e a configuração e executará os comandos padrão do Wrangler. Mantenha esta VM aberta até confirmar a exclusão e o logout.
Escreva um Worker de integridade
Nesta etapa, você criará o arquivo de entrada em JavaScript e informará ao Wrangler como executá-lo. Um Worker exporta um manipulador fetch: o Cloudflare o chama quando recebe uma solicitação HTTP, e o Response retornado se torna a resposta HTTP. Este primeiro Worker retorna a mesma mensagem de integridade para todos os caminhos; o roteamento será abordado no próximo laboratório.
Entre no projeto preparado e verifique a versão da CLI:
cd /home/labex/project/first-worker
npx wrangler --version
A versão deve ser 4.131.1. O Wrangler é uma dependência do projeto, portanto execute os comandos neste diretório. No seu próprio computador, instale as dependências fixadas de um projeto com npm ci quando um arquivo de lock for fornecido.
O próximo comando usa um here-document: cat grava em src/index.js as linhas entre <<'WORKER' e WORKER. O > substitui o conteúdo desse arquivo. As aspas no delimitador impedem que o shell altere o texto JavaScript. Cole o bloco completo, incluindo o delimitador final.
cat > src/index.js <<'WORKER'
export default {
async fetch(request) {
console.log("health-request", request.method, new URL(request.url).pathname);
return Response.json({ service: "labex-first-worker", status: "ok" });
},
};
WORKER
Response.json cria uma resposta JSON com status 200 e o tipo de conteúdo JSON. A mensagem do console registra o método e o caminho sem registrar cabeçalhos ou credenciais.
Gere um nome exclusivo para evitar substituir um Worker existente. O módulo crypto integrado do Node.js gera seis bytes aleatórios e os formata como doze caracteres hexadecimais. $(...) captura esse texto em uma variável do shell:
WORKER_NAME="labex-first-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
Crie a configuração. Aqui, o delimitador não está entre aspas, portanto $WORKER_NAME será expandido para esse valor exclusivo:
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false
}
CONFIG
main identifica seu arquivo JavaScript. compatibility_date seleciona o comportamento de compatibilidade do runtime; não é a data da implantação. workers_dev habilita uma URL pública de teste, enquanto preview_urls desabilita URLs adicionais de pré-visualização de versões. JSON sem comentários é válido em JSONC; use o formato mostrado neste laboratório.
cat wrangler.jsonc
Confirme que o nome começa com labex-first- e inclui um sufixo exclusivo. Mantenha esse nome durante todo o laboratório: a implantação e a exclusão terão como alvo esse nome. Você adicionará o ID da conta após a autorização.
Use o botão de verificação da etapa para conferir a configuração e o manipulador. Na próxima etapa, você observará a resposta por conta própria usando o runtime local.
Execute e teste o Worker localmente
Nesta etapa, você executará o Worker dentro da VM antes de publicá-lo. O runtime local do Wrangler executa seu manipulador sem criar uma implantação na nuvem.
Inicie o servidor de desenvolvimento em segundo plano para que o mesmo terminal possa enviar solicitações HTTP. --ip 0.0.0.0 disponibiliza o serviço da VM na interface web do LabEx, e --port 8080 seleciona a porta. > local.log salva a saída padrão, 2>&1 envia os erros para o mesmo arquivo e & devolve o prompt do terminal enquanto o servidor continua em execução.
npx wrangler dev --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
cat local.log
Aguarde até que o log informe que o servidor está pronto na porta 8080. Se a inicialização ainda estiver em andamento, execute cat local.log novamente antes de continuar. Deixe o servidor em execução até o final desta etapa.
Use curl para enviar uma solicitação. -i inclui os cabeçalhos da resposta, permitindo verificar o status e o tipo de conteúdo:
curl -i http://127.0.0.1:8080/health
A resposta inclui estes valores estáveis; a ordem e as letras maiúsculas dos cabeçalhos podem variar:
HTTP/1.1 200 OK
Content-Type: application/json
...
{"service":"labex-first-worker","status":"ok"}
O endereço 127.0.0.1 refere-se a esta VM. Ele não representa seu computador nem uma implantação pública no Cloudflare. Verifique o status HTTP, o tipo de conteúdo JSON e os dois campos da resposta antes de continuar.
Conclua a verificação desta etapa enquanto o servidor de desenvolvimento ainda estiver em execução.
Autorize e implante no Cloudflare
Nesta etapa, você conectará esta VM à sua conta de aprendizagem e implantará o Worker testado. Primeiro, inspecione o processo em segundo plano. jobs lista os processos iniciados neste terminal; a entrada deve mostrar wrangler dev.
jobs
Pare esse processo com kill %1. Aqui, %1 significa o processo 1 neste terminal, não um ID de processo do sistema. Se jobs mostrar outro número para wrangler dev, use esse número. Isso envia um sinal de encerramento ao processo.
kill %1
Inicie a autorização do dispositivo. Os escopos de leitura identificam sua conta; workers_scripts:write permite implantar e excluir scripts, e workers_tail:read permite visualizar logs em tempo real. --browser=false exibe o link para que você o abra no seu próprio navegador.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Abra o link exibido, entre no Cloudflare se solicitado, informe o código atual do dispositivo e revise a solicitação de permissões do Wrangler. Selecione sua conta de aprendizagem, não todas as contas. A página de consentimento também inclui o Background Access obrigatório. Só aprove depois de verificar a aplicação, a conta e as permissões; volte ao terminal e aguarde a conclusão da autorização. Se um código expirar, execute novamente o comando de login para obter um novo código. Não cole tokens no terminal nem compartilhe arquivos de credenciais.
Expanda Account & Billing e Developer Platform para inspecionar os nomes das permissões mostrados abaixo. Essas permissões são mais amplas que as da lição de conexão somente para leitura, porque este laboratório implanta um Worker e abre seus logs em tempo real.
Confirme que sua conta de aprendizagem está selecionada. Use Edit se a conta incorreta ou todas as contas estiverem selecionadas; revise sua escolha antes de clicar em Authorize.
Inspecione as contas disponíveis para este login:
npx wrangler whoami --json
Confirme "loggedIn": true e "authType": "OAuth Token". No array accounts, encontre o objeto com o name da sua conta de aprendizagem e copie seu id de 32 caracteres. As outras configurações da conta não são necessárias neste laboratório. Se aparecer apenas uma conta, ainda confirme o nome; se aparecerem várias, use o Dashboard para distingui-las. Se sua conta estiver ausente, repita a autorização usando a conta pretendida.
Adicione account_id à configuração. Substitua YOUR_ACCOUNT_ID neste bloco pelo ID copiado antes de executá-lo. Isso reescreve a configuração preservando a variável $WORKER_NAME da etapa 1. Mantenha este terminal aberto; se você perdeu a variável, leia o nome original com cat wrangler.jsonc e restaure WORKER_NAME exatamente com esse nome antes de continuar. Não gere outro nome nem troque de conta depois da implantação.
cat > wrangler.jsonc <<CONFIG
{
"name": "$WORKER_NAME",
"main": "src/index.js",
"compatibility_date": "2026-09-14",
"workers_dev": true,
"preview_urls": false,
"account_id": "YOUR_ACCOUNT_ID"
}
CONFIG
cat wrangler.jsonc
Verifique o nome exclusivo do Worker e compare account_id com o objeto da conta pretendida exibido por whoami --json. Esse ID é uma configuração, não uma senha. O Wrangler o lê ao implantar e excluir. Agora publique o código-fonte local:
npx wrangler deploy
Se esta conta ainda não tiver um subdomínio workers.dev, o Wrangler perguntará se você deseja registrar um. Responda yes, escolha um nome disponível em letras minúsculas usando letras, números e hífens e confirme. Esse nome no nível da conta será compartilhado pelos seus futuros Workers e é diferente do nome exclusivo do Worker deste laboratório. Se já existir um subdomínio, reutilize-o; não o renomeie. Não é necessário comprar um domínio personalizado nem fazer upgrade do plano.
Aguarde a conclusão da implantação. O Wrangler exibirá uma URL com esta estrutura:
https://<your-worker-name>.<your-subdomain>.workers.dev
Copie a URL real exibida pela implantação para uma variável do shell. Substitua toda a URL de exemplo abaixo, mantenha as aspas e não inclua uma barra final:
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/health"
Espere HTTP 200 e o mesmo JSON do teste local. Se o novo hostname ainda estiver sendo propagado, aguarde um pouco e tente novamente; uma página de erro não indica uma implantação bem-sucedida. Você também pode abrir a URL real /health no navegador. Se o navegador ou a rede bloquear workers.dev, use o resultado do curl na VM; não desative as configurações de segurança do navegador. A solicitação feita na VM e a verificação independente abaixo são os testes de resposta obrigatórios.
Agora confirme visualmente a mesma implantação no Cloudflare Dashboard. Mantenha o terminal aberto.
Selecione sua conta de aprendizagem no seletor de contas. A identidade dela deve corresponder à conta selecionada acima.
Abra Compute → Workers & Pages. Atualize a lista de aplicações, se necessário, e encontre o nome exato labex-first-... da sua configuração. Se houver muitas aplicações, pesquise o nome completo.
Abra esse Worker. Confirme o nome e localize o endereço workers.dev; compare o endereço com a URL exibida por wrangler deploy.
Estas capturas mostram um exemplo de implantação. O sufixo aleatório do seu Worker e o subdomínio da sua conta serão diferentes. Localize seus próprios valores em vez de copiar o exemplo. O Dashboard é outra visualização do recurso criado no terminal; não crie um segundo Worker nem edite o código aqui. Se ele não aparecer, verifique primeiro a conta selecionada, o nome exato e se o comando de implantação terminou.
A lista de aplicações confirma que existe um recurso na nuvem; a resposta HTTP testada com curl confirma que o código funciona. Você não precisa tirar nem enviar uma captura de tela.
Use o botão de verificação da etapa. A verificação independente do backend lê as configurações do Worker na conta selecionada e testa o endpoint público; outro site que retorne um texto semelhante não será aceito.
Observe um log de solicitação em tempo real
Nesta etapa, você conectará um fluxo de logs em tempo real e encontrará a mensagem produzida pelo seu manipulador. Um fluxo de logs mostra apenas as solicitações recebidas enquanto está conectado; solicitações anteriores não são reproduzidas.
Inicie o tail do Wrangler em segundo plano. --format json produz eventos estruturados. Desta vez, a saída padrão e os erros serão enviados para arquivos separados, mantendo o texto de diagnóstico fora dos dados dos eventos:
npx wrangler tail --format json > requests.json 2> tail-errors.log &
Aguarde alguns segundos para a inicialização da conexão e envie uma nova solicitação:
curl -i "$WORKER_URL/health"
O arquivo de eventos também contém muitos metadados da solicitação. head -n 32 exibe suas primeiras 32 linhas, permitindo que você se concentre no evento inicial e na mensagem da aplicação:
head -n 32 requests.json
Procure um evento com outcome igual a ok, uma solicitação GET terminando em /health e uma mensagem do console contendo health-request. Os outros campos, os horários e os cabeçalhos da solicitação podem variar. Se o arquivo estiver vazio, inspecione tail-errors.log, aguarde a conexão, envie a solicitação novamente e leia o arquivo outra vez.
Pare o tail antes de verificar todos os eventos salvos. Inspecione jobs e use o número exibido para wrangler tail (normalmente 1 depois que o processo anterior foi encerrado):
jobs
kill %1
Use o botão de verificação da etapa para conferir o evento capturado em relação ao Worker implantado.
O arquivo pode conter metadados da solicitação. Mantenha-o nesta VM; não o publique como captura de tela nem o envie para um repositório público.
Exclua o Worker de teste
Nesta etapa, você removerá apenas o Worker de teste e confirmará o resultado enquanto sua autorização de gerenciamento ainda estiver ativa. Excluir uma VM não excluiria um Worker implantado.
Inspecione novamente a configuração do projeto e confirme que name é o nome exclusivo labex-first-... usado neste laboratório:
cat wrangler.jsonc
Exclua esse Worker usando a configuração do projeto:
npx wrangler delete
Leia o prompt de confirmação, verifique o nome exato e pressione y para confirmar. Não use a exclusão forçada nem exclua outro projeto. Normalmente, o Wrangler informa que o Worker foi excluído. Com a versão fixada e essas permissões específicas, ele pode, em vez disso, exibir um erro de autenticação para /storage/kv/namespaces depois de excluir o Worker: o Wrangler também verifica o armazenamento legado do Workers Sites durante a limpeza. Este laboratório não cria namespaces KV. Não conceda todas as permissões sugeridas nem repita a implantação para corrigir esse diagnóstico; use o botão de verificação da etapa para descobrir se o Worker realmente desapareceu. Qualquer outro erro ainda precisa ser investigado.
No Cloudflare Dashboard, abra Workers & Pages na sua conta de aprendizagem e atualize a lista. Confirme que o nome exato do seu Worker não está presente. Em seguida, use o botão de verificação da etapa para fazer uma verificação independente pela API.
A verificação exige uma resposta de inventário autenticada bem-sucedida; uma solicitação de rede malsucedida ou um login expirado não conta como exclusão. Sua conta de aprendizagem e o subdomínio workers.dev no nível da conta continuarão disponíveis para laboratórios futuros. Conclua a verificação desta etapa antes de sair.
Desconecte a VM
Nesta etapa, você removerá a autorização armazenada pelo Wrangler depois de confirmar a limpeza na nuvem. Os arquivos-fonte locais continuarão na VM, mas não autorizarão mais o acesso à sua conta.
npx wrangler logout
npx wrangler whoami --json
Procure "loggedIn": false. Esta versão do Wrangler termina com código diferente de zero quando você está desconectado; isso é esperado. Um erro de rede sem esse estado explícito não comprova o logout. Use o botão de verificação da etapa para confirmar de forma independente.
Seu navegador pode continuar conectado ao Cloudflare Dashboard. O login do navegador e a autorização do Wrangler nesta VM são independentes. Um laboratório posterior começará com uma VM nova e solicitará sua própria autorização.
Resumo
Você escreveu um manipulador fetch e uma configuração de Worker, testou localmente sua resposta JSON, implantou o Worker na sua própria conta de aprendizagem e inspecionou um log de solicitação em tempo real. Você verificou de forma independente a resposta pública e a propriedade do recurso, excluiu o Worker de teste enquanto estava autorizado e saiu da VM.
Para referência, consulte os comandos do Wrangler, o manipulador fetch e a configuração do workers.dev.
