11 publicaciones etiquetados con "docker"

Todas las partes de esta serie hasta ahora le han dado al modelo herramientas: funciones que escribiste tú, con argumentos que definiste tú. Este post va sobre la otra cosa que hacen los agentes, que es escribir código y después ejecutarlo.

Es un riesgo distinto, y vale la pena ser preciso sobre la diferencia. Una llamada a herramienta es el modelo eligiendo de un menú que tú controlas. Ejecutar código generado es el modelo pasándote algo que nadie ha leído nunca, y que tú ejecutas en tu máquina.

Esta es la parte que nadie dice en voz alta cuando te recomiendan añadirte al grupo docker para dejar de escribir sudo.

Ese grupo es root. No "casi root", ni "root para cosas de Docker". Si puedes ejecutar un contenedor, puedes leer, modificar o borrar cualquier archivo de la máquina — incluido el archivo de contraseñas, los directorios personales de otras personas y los archivos que el administrador apartó deliberadamente de ti.

No hace falta ningún exploit. Es un comando, y tarda unos cuatro segundos.

La parte 4 de orquestación de agentes dividió una caja de herramientas para que el agente de agenda no pudiera emitir reembolsos. La parte 5 le dio al agente una identidad propia en el gateway. La parte 6 puso un verificador de JWT delante del servidor de herramientas para que rechace a quien llama sin identificarse.

Todas ellas controlan qué puede llamar el agente. Ninguna controla adónde puede ir.

Esa distinción es todo este artículo. La exfiltración no necesita una herramienta. Necesita un socket.

++

Así es como suele ir. Una aplicación necesita un modelo, así que pegas la clave API en su .env. Luego una segunda aplicación necesita una. Luego un script. Seis meses después, la misma clave está en cinco lugares, nadie recuerda cuál de ellas sigue funcionando, y no puedes rotarla sin romper algo que solo descubrirás cuando se rompa.

Un gateway es la solución aburrida. Un endpoint frente a cada modelo, un lugar que mantiene la credencial real, y una clave específica por aplicación que puedes revocar por su cuenta. Esta publicación despliega uno en una instancia WEC y lo apunta a la API de Inferencia WEC.

Parte 1 de esta serie auditó una caja multi-agente en vivo y encontró cada pregunta sobre exposición de red que valía la pena hacer. Una línea de esa auditoría no se siguió: "el Postgres, ClickHouse y Redis detrás de Langfuse estaban publicados en 127.0.0.1 en lugar del mundo — alguien tomó una buena decisión allí. Mantén ese pensamiento."

Aquí está la otra mitad de ese pensamiento: conseguir la red correcta no dice nada sobre lo que sucede después de que alguien ya esté dentro de un contenedor. Si el proceso que se ejecuta allí es root, un compromiso comienza con las llaves de todo el sistema de archivos. Así que verificamos — en la misma caja, la misma pila de Langfuse que la Parte 1 ya alabó — si "red correcta" también significaba "privilegio correcto." No lo era, para dos de los seis contenedores. Aquí está cómo se veía realmente la solución, incluyendo la parte que se rompió.

Comienzas con un agente. Luego necesita una base de datos. Después agregas un segundo agente, un puente de mensajería, una pila de observabilidad. Seis meses después, una única instancia de WEC está ejecutando cinco proyectos de compose, veinte y tantos contenedores, y nadie recuerda qué puertos están abiertos al mundo.

Eso no es un hipotético — esa es la caja en la que se escribió este tutorial. Así que en lugar de teorizar, lo investigamos: ¿pueden los contenedores alcanzarse entre sí a través de pilas? ¿Pueden alcanzar las bases de datos? ¿Está el firewall realmente protegiendo algo?

Tres de las respuestas me sorprendieron. Una de ellas fue una base de datos sentada allí sin contraseña. Y el firewall — el firewall estaba mintiendo.

++

La mayoría de las guías de "autoalbergar un asistente de IA para WhatsApp" se detienen en "el contenedor se inició". Esta va hasta el final: despliegas una puerta de enlace de WhatsApp programable real (API de Evolution), luego escribes el puente tú mismo — las ~50 líneas que convierten un mensaje entrante en una respuesta de LLM y la envían de vuelta. Ese puente (webhook → modelo → respuesta) es el patrón reutilizable detrás de cada integración de chat-AI: SMS, Slack, Telegram, voz — cambia el canal, la forma es idéntica.

Y porque esto es una construcción real, encontramos — y solucionamos — cada detalle: una imagen que movió a los editores, un bucle de versión de Baileys, un bucle de respuesta infinito, spam en grupos de chat, la nueva dirección LID de WhatsApp, y una genuina pared de entrega que la mayoría de los tutoriales pretenden que no existe. Cada comando, error y salida a continuación es de una ejecución real.

++

Nuestro análisis de economía de tokens de GPT-5.6 terminó con un desafío: las promesas de referencia son una hipótesis, no una razón — ejecuta la evaluación en tu carga de trabajo antes de que creas en un reclamo de "menos tokens por tarea". Este tutorial es nosotros siguiendo nuestro propio consejo.

Tomamos el asistente de documentos RAG de parte 5, lo envolvemos en una suite de regresión DeepEval — en contenedor, juzgada por gemma4 en la API de Inferencia WEC, sin dependencia de OpenAI — y luego usamos esa suite para responder a una pregunta genuinamente abierta: ¿deberíamos cambiar el modelo de generación del servicio? Qwen2.5-3B-Instruct (actual) vs gemma4 (candidato), tasa de aprobación y tokens por tarea, medidos cara a cara.

Spoiler: la evaluación nos salvó de una migración innecesaria. Y en el camino encontramos cuatro fallos reales de producción: un espiral mortal por disco lleno, una condición de carrera en el arranque, una trampa de variable de Docker Compose que evaluó silenciosamente el modelo incorrecto, y la solución que hace que esa clase de error sea imposible. Cada comando, número y error a continuación proviene de una ejecución real.

++

Todo en esta serie apuntaba a esto. Sabes demostrar que un modelo funciona (parte 1), hacer su salida fiable para máquinas (parte 2), generar datos de prueba reales (parte 3) y observar producción (parte 4). Ahora gastamos las cuatro habilidades a la vez en el patrón que está detrás de casi todo producto LLM serio: RAG — generación aumentada por recuperación.

Vamos a construir un asistente de documentación: un servicio HTTP en contenedor que responde preguntas de clientes desde la propia documentación de WEC. No un notebook — un servicio, Docker primero, con la forma que realmente desplegarías. Y como esta serie no hace demos del camino felíz: por el camino nuestro RAG alucina un precio de GPU, encontramos la causa en nuestro propio scraper, la arreglamos y fijamos el arreglo con un test de regresión. Cada comando, número y error de abajo viene de una ejecución real.

+

En Artículo 1 hicimos funcionar OpenClaw — pero solo a través de HTTP sin cifrar, con un workaround allowInsecureAuth. Aquí colocamos Caddy frente a él como un proxy inverso: verdadero HTTPS, autenticación emparejada por dispositivo, y los puertos del gateway cerrados para que el proxy sea la única forma de acceso. Cada comando y error a continuación proviene de la implementación real.

++

Tu asistente de IA no tiene que vivir en la nube de otra persona.

Despliega un agente de IA OpenClaw autoalojado en una instancia WEC con Docker Compose — desde iniciar la VM hasta un agente que realmente responde, usando tu propia clave de API de modelo. Cada comando, versión y error a continuación fue capturado de un despliegue real en una instancia WEC.