Redes

Dominios generados#

Cualquier servicio HTTP puede obtener un dominio bajo skiffly.cloud con un certificado ya emitido:

Los dominios son por entorno: el mismo servicio tiene dominios distintos en production y en staging. Generar dos veces devuelve el dominio existente. Cada dominio apunta al puerto en el que escucha el servicio; el primer dominio se expone al contenedor como SKIFFLY_PUBLIC_DOMAIN.

Dominios propios#

1. Agrega el dominio: Configuración → Red → Agregar dominio propio, skiffly domain app.example.com o customDomainCreate.

2. Crea los dos registros DNS que Skiffly imprime:

   app.example.com.            CNAME  edge.skiffly.cloud.
   _skiffly.app.example.com.   TXT    "<token de verificación>"

   Los dominios apex (example.com) necesitan un proveedor que admita ALIAS/ANAME o CNAME flattening; si no, apunta un registro A a la IP del edge 65.109.28.161 (EU-Helsinki; solo cambia con un traslado del plano de datos anunciado en la página de estado). Para verificar un dominio apex basta el registro TXT.

3. Espera a la verificación o pulsa Comprobar ahora. Skiffly comprueba los registros automáticamente cada 2 minutos durante el primer día y luego cada hora durante 7 días (CustomDomainStatus.autoCheck: ACTIVE); después las comprobaciones se detienen (STOPPED) hasta que pulses Comprobar ahora en Configuración → Redes, ejecutes skiffly domain status app.example.com o llames a customDomainVerify(id), que además reinicia el ciclo. Los cambios de DNS pueden tardar hasta 48 horas en propagarse. Cuando el registro TXT (y el CNAME, salvo en dominios apex) resuelve, el dominio se enruta, se emite un certificado de Let's Encrypt en unos minutos y recibes una notificación. No hace falta volver a desplegar.

   Los dominios verificados se vuelven a comprobar cada 6 horas; si los registros desaparecen en tres comprobaciones seguidas, el dominio deja de estar verificado y se te avisa.

skiffly domain app.example.com
skiffly domain status app.example.com     # imprime los registros y el estado de verificación
skiffly domain delete app.example.com

Cada dominio se sirve tanto en http:// como en https://; todavía no hay redirección forzada, así que redirige desde la app si lo necesitas (X-Forwarded-Proto está definido). Los dominios propios con comodín no se admiten.

Red privada#

Los servicios del mismo proyecto y entorno comparten una red privada. Cada servicio es accesible por su slug (el nombre del servicio en minúsculas; SKIFFLY_PRIVATE_DOMAIN) en su puerto, sin necesidad de dominio:

http://api:8080
postgres://postgres:…@postgres:5432/app
redis://redis:6379

• El hostname privado funciona solo dentro del entorno; production no puede llegar a staging.
• El tráfico entre proyectos está bloqueado por política de red; hay salida a internet, salvo por el puerto 25.
• Las bases de datos de plantillas escuchan solo en la red privada. ${{Postgres.DATABASE_URL}} ya usa el hostname privado.
• Los hostnames privados resuelven a las réplicas del servicio; el puerto es el del servicio, no el PORT de quien llama.
• SKIFFLY_PRIVATE_DOMAIN es el nombre completo (api.p-….svc.cluster.local). Úsalo donde el nombre corto no basta: nginx con resolver explícito no busca nombres cortos; apunta resolver a ${{SKIFFLY_DNS_RESOLVER}}.

Proxies TCP#

Los servicios que no son HTTP (Postgres, MySQL, Redis, Mongo, un servidor de juegos) pueden exponerse en un host:puerto público:

skiffly connect postgres          # crea un proxy tras confirmar y abre psql
skiffly proxy add --port 5432     # edge.skiffly.cloud:2xxxx → puerto 5432 del contenedor
skiffly proxy list
skiffly proxy delete 21543

El proxy es edge.skiffly.cloud:<puerto> con un puerto único en 20000–29999, aplicado de inmediato a un servicio en ejecución (syncStatus: ACTIVE; CREATING hasta el primer despliegue). El tráfico va directo al contenedor sin TLS, así que el servicio debe exigir contraseña. Hasta cinco proxies por servicio y entorno. Un servicio con proxy TCP no puede usar App Sleeping.

Límites y modo bajo ataque#

Cada solicitud pasa por un límite por cliente en el borde antes de llegar a tu servicio: hasta 100 solicitudes por segundo desde una IP (ráfagas de hasta 300) y 256 solicitudes en curso; por encima del límite el cliente recibe 429 Too Many Requests. Una dirección puede mantener hasta 256 conexiones y abrir 100 nuevas por segundo; los proxies TCP permiten 64 conexiones y 20 nuevas por segundo por dirección. El cuerpo de una solicitud debe terminar de subirse en 5 minutos y una conexión keep-alive inactiva se cierra a los 60 segundos. Tu servicio ve la dirección real del visitante en X-Real-Ip y X-Forwarded-For. Los dominios generados *.skiffly.cloud se sirven a través de Cloudflare, que limita el cuerpo de una solicitud a 100 MB y espera que la respuesta empiece en 100 segundos; usa un dominio propio para subidas más grandes o solicitudes más largas.

Si un servicio recibe una avalancha de tráfico, activa el modo bajo ataque en Settings → Networking o desde la CLI:

skiffly waf under-attack enable --service web --duration 1h
skiffly waf under-attack status --service web
skiffly waf under-attack disable --service web

Mientras está activo, cada cliente del servicio queda limitado a 5 solicitudes por segundo y 10 en curso, y en sus dominios *.skiffly.cloud los visitantes nuevos pasan antes una verificación del navegador: scripts, bots y clientes de API quedan fuera. Se aplica en segundos, sin redeploy, y se desactiva solo a las 1, 3, 12 o 24 horas, o sigue activo hasta que lo desactives. Está pensado para un incidente en curso: una API que debe seguir atendiendo clientes que no son navegadores debería apoyarse solo en el límite por IP. API: serviceInstanceUnderAttackEnable(serviceId, environmentId, duration), serviceInstanceUnderAttackDisable, ServiceInstance.underAttack.

Todavía no#

No existen IPs salientes estáticas, una capa CDN, dominios propios con comodín ni reenvío de correo. El tráfico saliente sale desde la IP del nodo.