Diseño de redes personalizadas para cargas de trabajo blockchain en contenedores

Alcance y respuesta directa

Una red personalizada es una red que usted define en lugar de depender de la predeterminada del runtime. En Docker y Podman, la forma más común es una red bridge definida por el usuario: los contenedores conectados a ella obtienen resolución DNS automática por nombre, una subred dedicada y aislamiento de los contenedores que no están conectados. Se crea con un comando como docker network create o podman network create, y luego se conectan las cargas de trabajo con --network.

Para cargas de trabajo blockchain, el patrón útil es separar los planos de comunicación. El tráfico peer-to-peer de un nodo, el acceso de un cliente RPC a ese nodo y el acceso SSH o de métricas de un operador no deberían compartir una única red plana. Una red personalizada le permite colocar el nodo y sus clientes de confianza juntos mientras mantiene fuera a los contenedores no relacionados.

Esta guía asume que ya tiene instalado un runtime de contenedores y que se siente cómodo con los comandos básicos docker run o podman run. No asume ninguna cadena, proveedor o sistema operativo host específico.

• Las redes bridge personalizadas proporcionan descubrimiento de servicios basado en DNS por nombre de contenedor.
• Las redes internas bloquean el acceso saliente a la LAN del host y a Internet.
• Las redes overlay extienden una red personalizada a través de múltiples hosts.
• La red host omite el aislamiento y debe ser una excepción deliberada.

Requisitos previos y suposiciones

Necesita un host Linux o un entorno Docker Desktop con permiso para crear redes. Podman sin root funciona para la mayoría de los ejemplos, pero el comportamiento de subred y enlace de puertos puede diferir del modo con root. Confirme la versión de su runtime antes de confiar en flags específicos del driver.

También necesita un plan sobre qué debe alcanzar cada contenedor. Escríbalo antes de crear nada: qué servicios se comunican entre sí, cuáles necesitan acceso saliente a Internet y qué puertos deben publicarse en el host. Ese plan se convierte en su lista de verificación más adelante.

docker version
docker network ls
podman version
podman network ls

Modelo mental: nombres, subredes y límites de aislamiento

Una red bridge personalizada es un switch virtual con su propia subred. Cada contenedor conectado obtiene una interfaz en ese switch. El runtime ejecuta un resolutor DNS integrado para que un contenedor llamado node-a pueda ser alcanzado por otros contenedores en la misma red usando ese nombre. Esta es la principal diferencia práctica con el bridge predeterminado, donde la resolución de nombres es limitada.

El aislamiento es una propiedad de la conexión, no del contenedor en sí. Un contenedor está aislado de otro solo si no comparten ninguna red. Si conecta un contenedor a dos redes personalizadas, se convierte en un router entre ellas, lo que puede ser exactamente lo que desea para un proxy o gateway, y exactamente lo que no desea para una base de datos.

Una red interna añade un segundo límite: los contenedores en ella pueden comunicarse entre sí pero no pueden salir del host. Eso es útil para un servicio backend al que solo se debe acceder a través de un proxy inverso en una red separada.

• Una red por límite de confianza suele ser más clara que una gran red compartida.
• La resolución de nombres está limitada a la red, por lo que nombres duplicados en redes diferentes no colisionan.
• Publicar un puerto con -p crea una ruta hacia el host que omite el aislamiento de red para ese puerto.

Creación de una red bridge personalizada con Docker

El siguiente procedimiento crea una red bridge personalizada con una subred explícita y luego ejecuta dos contenedores en ella. Reemplace los nombres de las imágenes con sus propias imágenes de nodo y cliente. Los comandos son ilustrativos y no dependen de una cadena específica.

Elija una subred que no se superponga con su LAN del host, VPN u otras redes de contenedores. Las subredes superpuestas son una causa común de sorpresas de enrutamiento.

docker network create \
  --driver bridge \
  --subnet 172.28.0.0/24 \
  --gateway 172.28.0.1 \
  node-net

docker run -d --name node-a --network node-net \
  --restart unless-stopped \
  your-node-image:latest

docker run -d --name rpc-client --network node-net \
  your-client-image:latest sleep infinity

docker network inspect node-net

Creación de una red personalizada interna con Podman

Podman utiliza los mismos conceptos con valores predeterminados ligeramente diferentes. El flag --internal crea una red sin conectividad externa. Esto es apropiado para un servicio backend al que solo deben acceder los contenedores en la misma red.

Después de crear la red, ejecute un contenedor en ella y confirme que puede resolver un par por nombre pero no puede alcanzar una dirección pública. El mensaje de error exacto depende del runtime y del kernel, así que trate el fallo observado como la señal de verificación en lugar de esperar una cadena específica.

podman network create \
  --subnet 10.89.0.0/24 \
  --internal \
  backend-net

podman run -d --name backend-api --network backend-net \
  your-api-image:latest

podman run --rm --network backend-net your-tools-image:latest \
  sh -c 'getent hosts backend-api; curl -sS --max-time 5 https://example.com || echo outbound-blocked'

Verificación de la resolución DNS y el aislamiento

La verificación debe ser un procedimiento repetible, no un vistazo único. Ejecute las mismas comprobaciones después de cada cambio en la topología de red. La siguiente tabla es una plantilla: complete el resultado observado para su entorno en lugar de asumir un valor.

Si una comprobación no coincide con la señal esperada, deténgase y corrija la topología antes de añadir más servicios. Añadir más contenedores sobre una red rota hace que el fallo sea más difícil de aislar.

docker exec rpc-client getent hosts node-a
docker exec rpc-client sh -c 'curl -sS --max-time 5 http://node-a:8545/health || true'
docker run --rm --network bridge your-tools-image:latest \
  sh -c 'getent hosts node-a || echo not-visible-from-default-bridge'

Conexión de un cliente a un nodo a través de la red personalizada

Una vez que la red está en su lugar, los clientes deben dirigirse al nodo por nombre de contenedor en lugar de por una IP codificada. Esto mantiene la configuración estable cuando los contenedores se reinician y reciben nuevas direcciones. El siguiente ejemplo utiliza una URL RPC de marcador de posición que se resuelve a través de la red personalizada.

Si su cliente también necesita alcanzar un endpoint RPC público, conéctelo a una segunda red no interna. Eso convierte al cliente en un puente deliberado entre la red aislada del nodo y el mundo exterior, lo que es más fácil de auditar que dar acceso saliente a cada contenedor.

export RPC_URL=http://node-a:8545

curl -sS -X POST "$RPC_URL" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Solución de problemas comunes de redes personalizadas

La mayoría de los problemas de redes personalizadas se dividen en un pequeño número de categorías. Los fallos de resolución de nombres suelen significar que los contenedores no están en la misma red, o que el cliente está usando una IP que cambió tras un reinicio. Los fallos salientes en una red interna son el comportamiento esperado, no un error. Los conflictos de puertos suelen significar que un puerto publicado ya está en uso en el host.

Si un contenedor puede alcanzar a un par por IP pero no por nombre, verifique que ambos estén conectados a la misma red definida por el usuario y que el resolutor DNS del runtime esté en ejecución. Si un contenedor no puede alcanzar nada en absoluto, inspeccione la red y confirme que la subred no se superpone con una ruta existente.

• Falla la resolución de nombres de contenedor: confirme que ambos contenedores comparten la misma red personalizada.
• Superposición de subredes: elija un rango fuera de los rangos de su LAN del host y VPN.
• Puerto ya asignado: cambie el puerto del lado del host o detenga el proceso en conflicto.
• La red interna bloquea el tráfico esperado: mueva el servicio a una red no interna o añada un proxy.
• El acceso del host a redes personalizadas se comporta de manera diferente según la plataforma: verifique en el host de destino, no solo en un portátil.

Limitaciones y compensaciones

Las redes personalizadas añaden sobrecarga operativa. Cada nueva red es otro objeto que nombrar, documentar y limpiar. Las redes overlay añaden latencia y requieren un plano de control de clúster funcional. Las redes internas son seguras por defecto pero inconvenientes cuando un servicio legítimamente necesita obtener actualizaciones o alcanzar un endpoint RPC público.

A veces se utiliza la red host para evitar NAT y la publicación de puertos, pero elimina por completo el límite de aislamiento. Para los nodos blockchain que exponen RPC o puertos de pares, esa compensación merece una revisión explícita. En la mayoría de los casos, una red bridge personalizada con puertos publicados de forma restrictiva es más fácil de razonar.

Si su objetivo es simplemente elegir un endpoint RPC público confiable en lugar de diseñar la red de contenedores, esa decisión corresponde a una comparación de proveedores y no a este artículo. Utilice el Asistente RPC para recomendaciones concretas de endpoints y proveedores, y reserve esta guía para la topología de red alrededor de su propia infraestructura.

Próximos pasos para la preparación para producción

Convierta la tabla de verificación en un script que se ejecute después de cada despliegue. Almacene las definiciones de red en el control de versiones junto con sus archivos compose o manifiestos de despliegue. Documente a qué red pertenece cada servicio y por qué.

Para los equipos que ejecutan infraestructura dedicada, revise cómo encajan el alojamiento de nodos y los niveles de servicio RPC en su topología. La guía de alojamiento de nodos blockchain cubre preocupaciones operativas más allá de las redes, y la guía de endpoints RPC multicadena explica cómo se deben configurar los clientes entre cadenas. Si está comparando opciones gestionadas, consulte precios de RPC y nodos dedicados.

Por último, decida dónde se sitúa el límite entre su red personalizada y los servicios externos. Un patrón común es una red interna para el nodo y sus clientes de confianza, más una ruta de salida estrecha a través de un proxy. Eso mantiene pequeño el radio de impacto mientras permite que el nodo se sincronice.

• Definiciones de red y scripts de verificación bajo control de versiones.
• Vuelva a ejecutar las comprobaciones de aislamiento después de cada cambio de topología.
• Mantenga la exposición pública limitada a los puertos que publica intencionadamente.
• Utilice el Asistente RPC cuando la pregunta restante sea qué endpoint o proveedor usar.