Kiril FerrerBackend & AI Product Engineer

Buscar en proyectos y aprendizaje

Escribe al menos dos caracteres.

↑↓ para recorrer · Esc para cerrar

Sistemas · Bloque I · Unidad 1.1

Capas, estado y evidencia

Recupera primero el modelo y después compruébalo sobre un servicio preparado. Las actividades comparten criterios explícitos, pero no una respuesta ni una secuencia de reparación.

2actividades publicadas
E0 + ECpapel y contenedor desechable
Codexrevisión por evidencia

Cómo trabajar este bloque

Realiza SYS-R-101 antes del laboratorio. EnSYS-L-101, descarga el paquete y extráelo en un directorio temporal fuera del repositorio. El launcher debe ejecutarse sinsudo.

Conserva solo fragmentos mínimos de salida y acompaña cada uno con su interpretación. Una salida sin explicar no cuenta como evidencia.

SYS-R-101

Reconstruir dos recorridos entre capas

  • Recuperación
  • Inicial
  • Guiado alto
  • E0

Debes explicar dos operaciones a otra persona sin consultar primero la unidad: una aplicación lee un archivo local y un cliente solicita un recurso HTTP alojado en otro host.

Abrir actividad, entorno y criterios

E0 · E0 · Sin sistema objetivo. Respuesta local en el navegador y expediente Markdown opcional.

Capacidad

Reconstruir un modelo causal de capas, interfaces, recursos y estado, y reconocer el límite de cada observación.

Enunciado

Dibuja ambos recorridos desde la intención inicial hasta el resultado y anota en cada frontera qué se pide, qué estado importa y qué señal permitiría comprobarlo.

Estado inicial

  • La Unidad 1.1 está estudiada, pero debe permanecer cerrada durante el primer intento.
  • No hay una avería escondida ni una respuesta única de formato: se evalúa la coherencia causal.
  • La plantilla descargable está vacía y solo organiza la evidencia.

Límites del sandbox

  • No se ejecutan comandos ni se modifica un sistema.
  • No se incluyen credenciales, direcciones reales ni información de terceros.
  • Si consultas la teoría después del primer intento, registra qué parte corregiste.

1. Recuperación sin consulta

Hacer visible el modelo que puedes reconstruir de memoria.

  1. Traza la lectura local desde la aplicación hasta el recurso y el resultado de vuelta.
  2. Traza la petición remota separando el host cliente, el trayecto de red y el host servidor.
  3. Marca con un signo de interrogación cualquier frontera cuyo mecanismo no puedas justificar todavía.

2. Observaciones y límites

Convertir las cajas del dibujo en comprobaciones posibles.

  1. Añade al menos tres observaciones por recorrido.
  2. Para cada observación escribe qué estado muestra, desde qué perspectiva y qué conclusión sigue abierta.
  3. Distingue hechos, inferencias y estado deseado mediante etiquetas consistentes.

3. Contraste y transferencia

Corregir el modelo sin sustituirlo por una copia de la teoría.

  1. Contrasta el primer intento con la Unidad 1.1 y corrige solo las fronteras que hayan cambiado.
  2. Explica qué parte del recorrido existe tanto en local como en remoto y qué responsabilidades se añaden.
  3. Formula una observación inicial si el archivo no pudiera leerse y otra si la petición remota no respondiera.

Evidencia que debes conservar

  • Mapa anotado de la lectura local.
  • Mapa anotado de la petición remota.
  • Tabla breve de observación, conclusión permitida y conclusión todavía no demostrada.
  • Nota de transferencia y correcciones realizadas tras consultar la teoría.

Criterios de aceptación

  • Los recorridos distinguen aplicación, proceso, interfaz del sistema operativo, kernel y recurso final.
  • La petición remota separa el estado del cliente del estado del servidor y no trata Internet como una única capa.
  • Cada observación se vincula a una interfaz o herramienta y declara qué confirma y qué no confirma.
  • Proceso, servicio y aplicación no se utilizan como sinónimos.
  • Las inferencias aparecen separadas de los hechos observables.

Decisiones abiertas

  • Formato del mapa: texto, Mermaid, dibujo escaneado o tabla.
  • Herramientas de observación propuestas, siempre que consulten la capa declarada.
  • Nivel de detalle de bibliotecas y runtime sin entrar en llamadas al sistema programadas.

Materiales

Se guarda solo en este navegador. Puedes descargarlo para enviarlo a Codex junto con los materiales que hayas completado.

Sin borrador guardado.

Revisión y reinicio

Revisión: Codex debe comparar la evidencia con estos criterios, señalar primero el supuesto no demostrado y proponer una sola comprobación siguiente. No hay una solución oficial publicada.

Reinicio: Borrar la respuesta local o iniciar una copia nueva de la plantilla; no existe estado de laboratorio que conservar.

Pistas graduadas

Pista 1 · Empieza por responsabilidades
  • Pregunta quién expresa la intención, quién ejecuta y quién media el acceso al recurso.
  • No añadas herramientas hasta haber dibujado las fronteras.
Pista 2 · Una señal no valida todo el recorrido
  • Un proceso existente y un servicio disponible son afirmaciones distintas.
  • Una respuesta de resolución de nombres no demuestra que el puerto o la aplicación respondan.
Pista 3 · Cambia de perspectiva
  • En la petición remota hay estado observable en el cliente y en el servidor.
  • Anota explícitamente desde qué host se realizaría cada comprobación.

Teoría y documentación permitida

SYS-L-101

Seguir una petición desde curl hasta el proceso y el log

  • Laboratorio
  • Inicial
  • Guiado alto
  • EC

Un servicio HTTP mínimo responde dentro de un contenedor. Debes seguir una petición real desde el cliente hasta el socket en escucha, el proceso que la atiende y el evento que deja en el log.

Abrir actividad, entorno y criterios

EC · EC · Contenedor desechable ejecutado con Podman rootless, Docker rootless o Docker Desktop.

Capacidad

Observar una misma operación desde varias interfaces y construir una explicación causal sin modificar el host ni confundir aislamiento con una máquina virtual.

Enunciado

Arranca el servicio preparado, formula una predicción, ejecuta una petición correlacionada y reúne tres observaciones independientes que permitan reconstruir el recorrido y sus límites.

Estado inicial

  • Paquete autocontenido con Containerfile, servicio Python y launcher de alcance validado.
  • El runtime asigna un puerto efímero ligado a 127.0.0.1; no se abre una interfaz externa.
  • El servicio expone /health y /trace, y registra eventos estructurados en stdout.
  • No hay un fallo oculto: el objetivo es aprender a relacionar vistas del mismo estado.

Límites del sandbox

  • Extrae el paquete en un directorio creado para el intento, nunca dentro de este repositorio.
  • Ejecuta el launcher como usuario normal y no antepongas sudo.
  • El launcher rechaza Docker Engine rootful; acepta Podman rootless, Docker rootless o Docker Desktop.
  • No publiques el endpoint, no cambies el bind de loopback y no uses credenciales reales.
  • La limpieza valida etiquetas y nombres exactos antes de retirar el contenedor o la imagen.

1. Preparar un intento aislado

Separar el sistema objetivo del portfolio y obtener un estado reiniciable.

  1. Descarga el paquete y colócalo en un directorio desde el que puedas extraerlo.
  2. Crea un directorio temporal nuevo y entra en la carpeta extraída.
  3. Ejecuta el diagnóstico antes de construir o iniciar recursos.
attempt_dir="$(mktemp -d -t sys-l-101.XXXXXX)"
tar -xzf sys-l-101-lab.tar.gz -C "$attempt_dir"
cd "$attempt_dir/sys-l-101"
./lab doctor

2. Predecir y arrancar

Declarar el recorrido esperado antes de mirar todas las salidas.

  1. Dibuja una primera predicción con host, runtime, puerto publicado, contenedor, socket, proceso y aplicación.
  2. Inicia el intento y conserva el ID, el runtime y el endpoint que muestra el launcher.
  3. Comprueba el estado sin interpretar todavía que «en ejecución» equivale a servicio sano.
./lab start
./lab status
./lab endpoint

3. Correlacionar cliente, socket, proceso y log

Observar la misma operación mediante interfaces diferentes.

  1. Asigna un ID a la petición y conserva el verbose de curl.
  2. Observa el socket dentro del contenedor y registra dirección, puerto y estado.
  3. Observa el árbol o la tabla de procesos y relaciona el PID con el programa.
  4. Consulta los logs del runtime y localiza el evento con el mismo ID de petición.
  5. Para cada salida escribe qué confirma y qué sigue sin demostrar.
endpoint="$(./lab endpoint)"
request_id="manual-$(date +%s)"
curl --verbose --header "X-Request-ID: $request_id" "$endpoint/trace"
./lab exec ss -ltnp
./lab exec ps -eo pid,ppid,user,stat,args
./lab logs

4. Reiniciar y retirar

Demostrar que el estado es desechable y que la limpieza tiene alcance exacto.

  1. Registra el identificador actual del contenedor.
  2. Reinicia el intento y comprueba qué estado cambió y cuál se conservó.
  3. Destruye los recursos del intento y confirma que el launcher ya no encuentra el contenedor.
./lab reset
./lab status
./lab destroy
./lab status

Evidencia que debes conservar

  • Expediente completado con objetivo, estado inicial e identificador del intento.
  • Predicción inicial y mapa corregido del recorrido.
  • Tres fragmentos mínimos de salida: socket, proceso y log, además del verbose relevante de curl.
  • Interpretación de cada fragmento y una afirmación que todavía no permite sostener.
  • Evidencia del reset o destroy y conclusión final.

Criterios de aceptación

  • El paquete se extrae en un directorio temporal fuera del checkout del portfolio y se ejecuta sin sudo.
  • El puerto se publica únicamente en loopback y el contenedor descarta capacidades, usa filesystem de solo lectura y limita recursos.
  • La misma petición se identifica de forma inequívoca en la salida del cliente y en el log del servicio.
  • Las observaciones de socket, proceso y log se interpretan por separado, sin afirmar que una sola demuestra la salud completa.
  • El mapa diferencia el proceso del host, el runtime, el espacio de red del contenedor y la aplicación.
  • El reinicio o la destrucción actúan solo sobre los recursos etiquetados con el ID del intento.

Decisiones abiertas

  • Usar Podman rootless, Docker rootless o Docker Desktop según el entorno disponible.
  • Representar el mapa como diagrama, tabla o texto estructurado.
  • Elegir /proc como observación adicional del proceso, sin sustituir las tres evidencias mínimas.

Materiales

Se guarda solo en este navegador. Puedes descargarlo para enviarlo a Codex junto con los materiales que hayas completado.

Sin borrador guardado.

Revisión y reinicio

Revisión: Codex debe comparar la evidencia con estos criterios, señalar primero el supuesto no demostrado y proponer una sola comprobación siguiente. No hay una solución oficial publicada.

Reinicio: Ejecutar ./lab reset para recrear únicamente el contenedor del intento o ./lab destroy para retirar su contenedor e imagen etiquetados.

Pistas graduadas

Pista 1 · Conserva un identificador común
  • La cabecera X-Request-ID permite localizar la misma petición en dos perspectivas.
  • No pegues todo el log: conserva el evento mínimo que comparte ese identificador.
Pista 2 · Pregunta quién posee cada vista
  • curl observa como cliente; ss consulta sockets; ps o /proc muestran procesos; el runtime conserva stdout.
  • Que dos herramientas muestren información relacionada no significa que consulten la misma interfaz.
Pista 3 · Distingue publicación y escucha
  • El puerto del host y el puerto dentro del contenedor pueden ser distintos.
  • Anota en qué espacio de red existe cada dirección antes de unirlas en el mapa.

Teoría y documentación permitida

Revisión con Codex

Entrega el expediente descargado y, para el laboratorio, únicamente los fragmentos relevantes. Pide a Codex que evalúe modelo, evidencia, operación y comunicación contra los criterios visibles; que señale primero el supuesto no demostrado y que proponga una sola comprobación siguiente.

No necesitas subir logs completos, archivos del runtime ni el directorio del intento. El material no contiene una clave de respuestas.