Introducción
Un endpoint de estado es una URL pequeña que le indica si una aplicación responde. En este laboratorio, escribirá un Cloudflare Worker en JavaScript, probará su respuesta JSON dentro de LabEx, publicará el mismo código en una URL pública de workers.dev, inspeccionará un registro de solicitudes y eliminará la implementación de prueba.
Use su propia cuenta de aprendizaje con un correo electrónico verificado y Workers Free, preparada en Prepare Your Cloudflare Learning Account. Debe reconocer el flujo de autorización del dispositivo de Connect LabEx to Your Cloudflare Account y conocer los fundamentos de JavaScript. Esta VM nueva necesita su propia autorización, incluidos los permisos para implementar y eliminar Workers. No necesita comprar un dominio, usar una base de datos ni adquirir una actualización de pago. La respuesta de prueba es pública y solo contiene datos de ejemplo.
La configuración ya instaló Node.js 22.22.0 y Wrangler 4.131.1 como dependencia local del proyecto en /home/labex/project/first-worker. Inspeccionará la información de la cuenta con Wrangler y probará las respuestas con curl; estas herramientas también funcionan fuera de LabEx. Usted escribirá el Worker y la configuración, y ejecutará los comandos estándar de Wrangler. Mantenga esta VM abierta hasta verificar la eliminación y el cierre de sesión.
Escriba un Worker de estado
En este paso, creará el punto de entrada de JavaScript e indicará a Wrangler cómo ejecutarlo. Un Worker exporta un controlador fetch: Cloudflare lo llama cuando recibe una solicitud HTTP, y el objeto Response devuelto se convierte en la respuesta HTTP. Este primer Worker devuelve el mismo mensaje de estado para cualquier ruta; el enrutamiento se tratará en el siguiente laboratorio.
Entre en el proyecto preparado y compruebe la versión de la CLI:
cd /home/labex/project/first-worker
npx wrangler --version
La versión debe ser 4.131.1. Wrangler es una dependencia del proyecto, por lo que debe ejecutar los comandos desde este directorio. En su propio equipo, instale las dependencias fijadas de un proyecto con npm ci cuando se proporcione su archivo de bloqueo.
El siguiente comando utiliza un here-document: cat escribe en src/index.js las líneas situadas entre <<'WORKER' y WORKER. El operador > reemplaza el archivo. Las comillas del delimitador impiden que el shell modifique el texto de JavaScript. Pegue el bloque completo, incluido el 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 crea una respuesta JSON con estado 200 y el tipo de contenido JSON. El mensaje de consola registra el método y la ruta sin registrar encabezados ni credenciales.
Genere un nombre único para evitar sobrescribir un Worker existente. El módulo crypto integrado en Node.js genera seis bytes aleatorios y los formatea como doce caracteres hexadecimales. $(...) captura ese texto en una variable del shell:
WORKER_NAME="labex-first-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
Cree la configuración. En este caso, el delimitador no lleva comillas, por lo que $WORKER_NAME se sustituye por ese valor único:
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 su archivo JavaScript. compatibility_date selecciona el comportamiento de compatibilidad del entorno de ejecución; no es la fecha de implementación. workers_dev habilita una URL pública de prueba, mientras que preview_urls deshabilita las URL adicionales de vista previa de versiones. El formato JSON sin comentarios también es válido como JSONC; use el formato mostrado en este laboratorio.
cat wrangler.jsonc
Confirme que el nombre comienza por labex-first- e incluye un sufijo único. Mantenga ese nombre durante todo el laboratorio: la implementación y la eliminación se dirigirán a él. Añadirá el ID de la cuenta después de la autorización.
Use el botón de verificación del paso para comprobar la configuración y el controlador. En el siguiente paso observará usted mismo la respuesta mediante el entorno de ejecución local.
Ejecute y pruebe el Worker localmente
En este paso, ejecutará el Worker dentro de la VM antes de publicarlo. El entorno de ejecución local de Wrangler ejecuta su controlador sin crear una implementación en la nube.
Inicie el servidor de desarrollo en segundo plano para que el mismo terminal pueda enviar solicitudes HTTP. --ip 0.0.0.0 hace que el servicio de la VM esté disponible para la interfaz web de LabEx, y --port 8080 selecciona su puerto. > local.log guarda la salida estándar, 2>&1 envía los errores al mismo archivo y & devuelve el prompt del terminal mientras el servidor sigue ejecutándose.
npx wrangler dev --ip 0.0.0.0 --port 8080 > local.log 2>&1 &
cat local.log
Espere hasta que el registro indique que el servidor está listo en el puerto 8080. Si el inicio aún está en curso, repita cat local.log antes de continuar. Mantenga el servidor en ejecución hasta el final de este paso.
Use curl para enviar una solicitud. -i incluye los encabezados de la respuesta, de modo que puede comprobar tanto el estado como el tipo de contenido:
curl -i http://127.0.0.1:8080/health
La respuesta incluye estos valores estables; el orden y las mayúsculas de los encabezados pueden variar:
HTTP/1.1 200 OK
Content-Type: application/json
...
{"service":"labex-first-worker","status":"ok"}
La dirección 127.0.0.1 hace referencia a esta VM. No corresponde a su equipo ni a una implementación pública de Cloudflare. Compruebe el estado HTTP, el tipo de contenido JSON y los dos campos de la respuesta antes de continuar.
Complete la verificación de este paso mientras el servidor de desarrollo siga ejecutándose.
Autorice e implemente en Cloudflare
En este paso, conectará esta VM a su cuenta de aprendizaje e implementará el Worker probado. Primero inspeccione el trabajo en segundo plano. jobs muestra los trabajos iniciados en este terminal; su entrada debe mostrar wrangler dev.
jobs
Detenga ese trabajo con kill %1. Aquí %1 significa el trabajo 1 de este terminal, no el ID de un proceso del sistema. Si jobs muestra otro número para wrangler dev, use ese número. Esto envía una señal de terminación al trabajo.
kill %1
Inicie la autorización mediante dispositivo. Los permisos de lectura identifican su cuenta; workers_scripts:write permite implementar y eliminar scripts, y workers_tail:read permite consultar registros en tiempo real. --browser=false muestra el enlace para que lo abra en su propio navegador.
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read
Abra el enlace mostrado, inicie sesión en Cloudflare si se le solicita, introduzca el código actual del dispositivo y revise la solicitud de permisos de Wrangler. Seleccione su cuenta de aprendizaje, no todas las cuentas. La página de consentimiento también incluye el Background Access requerido. Apruebe la solicitud solo después de comprobar la aplicación, la cuenta y los permisos; vuelva al terminal y espere a que finalice la autorización. Si el código caduca, vuelva a ejecutar el comando de inicio de sesión para obtener uno nuevo. No pegue tokens en el terminal ni comparta archivos de credenciales.
Expanda Account & Billing y Developer Platform para inspeccionar los nombres de los permisos que se muestran a continuación. Estos permisos son más amplios que los de la lección de conexión de solo lectura porque este laboratorio implementa un Worker y abre sus registros en tiempo real.
Confirme que está seleccionada su cuenta de aprendizaje. Use Edit si se seleccionó la cuenta equivocada o todas las cuentas; revise la selección antes de hacer clic en Authorize.
Inspeccione las cuentas disponibles para este inicio de sesión:
npx wrangler whoami --json
Confirme "loggedIn": true y "authType": "OAuth Token". En el arreglo accounts, busque el objeto cuyo name coincida con el nombre de su cuenta de aprendizaje y copie su id de 32 caracteres. No necesita ninguna otra configuración de cuenta para este laboratorio. Si solo aparece una cuenta, confirme igualmente su nombre; si aparecen varias, use el Dashboard para distinguirlas. Si falta su cuenta, repita la autorización con la cuenta correcta.
Añada account_id a la configuración. Sustituya YOUR_ACCOUNT_ID en este bloque por el ID copiado antes de ejecutarlo. Esto vuelve a escribir la configuración y conserva la variable $WORKER_NAME del paso 1. Mantenga abierto este terminal; si perdió la variable, lea el nombre original mediante cat wrangler.jsonc y restaure WORKER_NAME con exactamente ese nombre. No genere otro nombre ni cambie de cuenta después de implementar.
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
Compruebe el nombre único del Worker y compare account_id con el objeto de la cuenta correspondiente en whoami --json. Este ID es configuración, no una contraseña. Wrangler lo lee al implementar y al eliminar. Ahora publique el código local:
npx wrangler deploy
Si esta cuenta aún no tiene un subdominio workers.dev, Wrangler le preguntará si desea registrar uno. Responda yes, elija un nombre disponible en minúsculas usando letras, números y guiones, y confírmelo. Este nombre a nivel de cuenta se comparte con sus futuros Workers y es diferente del nombre único del Worker de este laboratorio. Si ya existe un subdominio, reutilícelo; no le cambie el nombre. No necesita comprar un dominio personalizado ni actualizar el plan.
Espere a que finalice la implementación. Wrangler muestra una URL con esta estructura:
https://<your-worker-name>.<your-subdomain>.workers.dev
Copie la URL real que muestra la implementación en una variable del shell. Sustituya la URL de ejemplo completa que aparece a continuación, conserve las comillas y omita la barra final:
WORKER_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
curl -i "$WORKER_URL/health"
Espere un estado HTTP 200 y el mismo JSON que obtuvo en la prueba local. Si el nuevo nombre de host aún se está propagando, espere unos instantes y vuelva a intentarlo; una página de error no indica que la implementación se haya realizado correctamente. También puede abrir la URL real de /health en el navegador. Si su navegador o red bloquea workers.dev, use el resultado de curl en la VM; no desactive la configuración de seguridad del navegador. La solicitud desde la VM y la comprobación independiente siguiente son las pruebas de respuesta requeridas.
Ahora confirme visualmente la misma implementación en el Cloudflare Dashboard. Mantenga abierto el terminal.
Seleccione su cuenta de aprendizaje en el selector de cuentas. Su identidad debe coincidir con la cuenta seleccionada anteriormente.
Abra Compute → Workers & Pages. Actualice la lista de aplicaciones si es necesario y busque el nombre exacto labex-first-... de su configuración. Si hay muchas aplicaciones, busque el nombre completo.
Abra ese Worker. Confirme su nombre y localice su dirección workers.dev; compare la dirección con la URL que mostró wrangler deploy.
Estas capturas muestran una implementación de ejemplo. El sufijo aleatorio de su Worker y el subdominio de su cuenta serán diferentes. Localice sus propios valores en lugar de copiar el ejemplo. El Dashboard es otra vista del recurso que creó desde el terminal; no cree un segundo Worker ni edite aquí su código. Si no aparece, compruebe primero la cuenta seleccionada, el nombre exacto y si el comando de implementación finalizó.
La lista de aplicaciones confirma que existe un recurso en la nube; la respuesta HTTP que probó con curl confirma que su código funciona. No necesita tomar ni enviar una captura propia.
Use el botón de verificación del paso. Su comprobación independiente del backend lee la configuración del Worker en la cuenta seleccionada y prueba el endpoint público, por lo que otro sitio web que devuelva un texto parecido no puede satisfacerla.
Observe un registro de solicitudes en tiempo real
En este paso, conectará un flujo de registros en tiempo real y buscará el mensaje producido por su controlador. Un flujo de registros solo muestra las solicitudes recibidas mientras está conectado; las solicitudes anteriores no se reproducen.
Inicie Wrangler tail en segundo plano. --format json produce eventos estructurados. Esta vez, la salida estándar y los errores se envían a archivos separados para mantener el texto de diagnóstico fuera de los datos de eventos:
npx wrangler tail --format json > requests.json 2> tail-errors.log &
Espere unos segundos para que la conexión se inicialice y envíe una solicitud nueva:
curl -i "$WORKER_URL/health"
El archivo de eventos también contiene muchos metadatos de la solicitud. head -n 32 muestra sus primeras 32 líneas para que pueda centrarse en el evento inicial y el mensaje de la aplicación:
head -n 32 requests.json
Busque un evento cuyo outcome sea ok, una solicitud GET que termine en /health y un mensaje de consola que contenga health-request. Los demás campos, las marcas de tiempo y los encabezados de la solicitud pueden variar. Si el archivo está vacío, inspeccione tail-errors.log, espere a que se conecte el flujo, envíe la solicitud de nuevo y vuelva a leer el archivo.
Detenga tail antes de verificar todos los eventos guardados. Inspeccione jobs y use el número que aparezca para wrangler tail (normalmente 1 después de detener el trabajo anterior):
jobs
kill %1
Use el botón de verificación del paso para comprobar el evento capturado con respecto al Worker implementado.
El archivo puede contener metadatos de solicitudes. Manténgalo en esta VM; no lo publique como captura de pantalla ni lo envíe a un repositorio público.
Elimine el Worker de prueba
En este paso, eliminará únicamente el Worker de prueba y confirmará el resultado mientras su autorización de administración siga activa. Eliminar una VM no elimina un Worker implementado.
Inspeccione de nuevo la configuración del proyecto y confirme que su name es el nombre único labex-first-... utilizado en este laboratorio:
cat wrangler.jsonc
Elimine ese Worker mediante la configuración del proyecto:
npx wrangler delete
Lea el mensaje de confirmación, compruebe el nombre exacto y pulse y para confirmar. No use la eliminación forzada ni elimine otro proyecto. Normalmente Wrangler informa de que el Worker se eliminó. Con la versión fijada y estos permisos limitados, puede mostrar en cambio un error de autenticación para /storage/kv/namespaces después de eliminar el Worker: Wrangler también comprueba el almacenamiento heredado de Workers Sites durante la limpieza. Este laboratorio no crea espacios de nombres de KV. No conceda todos los permisos sugeridos ni repita la implementación para corregir ese diagnóstico; use el botón de verificación de este paso para saber si el Worker realmente desapareció. Cualquier otro error requiere investigación.
En el Cloudflare Dashboard, abra Workers & Pages en su cuenta de aprendizaje y actualice la lista. Confirme que el nombre exacto de su Worker ya no aparece. Después, use el botón de verificación del paso para realizar una comprobación independiente mediante la API.
La comprobación requiere una respuesta de inventario autenticada correctamente; una solicitud de red fallida o una sesión caducada no cuentan como eliminación. Su cuenta de aprendizaje y su subdominio workers.dev a nivel de cuenta seguirán disponibles para laboratorios posteriores. Complete la verificación de este paso antes de cerrar la sesión.
Desconecte la VM
En este paso, eliminará la autorización almacenada de Wrangler después de verificar la limpieza en la nube. Los archivos fuente locales permanecerán en la VM, pero ya no autorizarán el acceso a su cuenta.
npx wrangler logout
npx wrangler whoami --json
Busque "loggedIn": false. Esta versión de Wrangler termina con un código distinto de cero cuando la sesión está cerrada; es lo esperado. Un error de red sin este estado explícito no demuestra que se haya cerrado la sesión. Use el botón de verificación del paso para confirmarlo de forma independiente.
Su navegador puede seguir conectado al Cloudflare Dashboard. El inicio de sesión del navegador y la autorización de Wrangler en esta VM son independientes. Un laboratorio posterior comenzará con una VM nueva y solicitará su propia autorización.
Resumen
Escribió un controlador fetch y la configuración de un Worker, probó localmente su respuesta JSON, lo implementó en su propia cuenta de aprendizaje e inspeccionó un registro de solicitudes en tiempo real. Verificó de forma independiente la respuesta pública y la propiedad del recurso, eliminó el Worker de prueba mientras estaba autorizado y cerró la sesión de la VM.
Como referencia, consulte los comandos de Wrangler, el controlador fetch y la configuración de workers.dev.
