Redes
En Lizard (lizard.build), los servicios del mismo proyecto y de la misma región se comunican entre sí por una red privada en <service>.lizard.internal, en cualquier puerto, sin un dominio público. Cada servicio web también recibe un dominio generado *.onlizard.com con TLS automático al desplegarse. También puedes asociar tu propio hostname. Managed Postgres y Managed Redis se unen a la misma red privada. Ve a redes privadas, dominios personalizados o puertos.
Dominios generados
El dominio predeterminado de un servicio se crea para ti, con la forma <name>-<suffix>.onlizard.com. Los servicios más antiguos conservan <words>.<region>.onlizard.com. Muéstralo:
lizard domain # show the service's current domain
lizard domain generate # claim a *.onlizard.com subdomain if the service has nonelizard domain generate devuelve el dominio generado existente si lo hay, y falla mientras el servicio tenga un dominio personalizado. Los archivos servidos desde Managed Object Storage usan en su lugar un host de gateway: s3-eu-west-1.onlizard.com o s3-us-east-1.onlizard.com.
Asociar un dominio personalizado
El hostname es un argumento posicional: no existe un subcomando add:
lizard domain app.example.com --service webLizard devuelve los registros DNS que debes crear (un CNAME para el hostname y un registro TXT para la verificación). Agrégalos en tu proveedor de DNS.
Verificar
Una vez que el DNS se haya propagado, activa el dominio:
lizard domain verify app.example.com --service webEsto comprueba el registro TXT y activa el dominio. El TLS se aprovisiona automáticamente.
Eliminar un dominio
lizard domain delete app.example.com --service web
lizard domain rm app.example.com --service web --yes # alias, skip confirmationCambiar el puerto en el que escucha tu servicio
Los dominios dirigen el tráfico al puerto del contenedor del servicio. Si tu servicio escucha en otro puerto, cambia el puerto del contenedor y vuelve a desplegar:
lizard port 8080 --service web
lizard redeploy --service webServicios worker
Un servicio en modo worker (containerPort=0) puede seguir mostrando un dominio generado, pero no sirve nada: no hay listener ni ruta de load balancer. No asocies un dominio personalizado a un worker.
Redes privadas
Los servicios del mismo proyecto se conectan entre sí en <service>.lizard.internal, en cualquier puerto en el que escuche el servicio, sin un dominio público. Haz referencia al hostname como ${{api.LIZARD_PRIVATE_DOMAIN}}. Managed Postgres y Managed Redis exponen DATABASE_PRIVATE_URL y REDIS_PRIVATE_URL en la misma red; consulta la cadena de conexión de Postgres. Estos nombres solo se resuelven dentro del proyecto, y los servicios de otros proyectos no pueden llegar a estas direcciones. El tráfico no sale de la red de Lizard, así que http:// simple sirve entre servicios.
Los nombres privados solo funcionan entre servicios y bases de datos de la misma región. Entre regiones, usa la URL pública. Lizard fija el nombre una sola vez, a partir del nombre del servicio en minúsculas y con los demás caracteres cambiados por -, y añade -2, -3 si hay un conflicto. Renombrar el servicio no lo cambia, así que haz referencia a ${{api.LIZARD_PRIVATE_DOMAIN}} en lugar de escribir el nombre.
lizard secrets set API_URL='http://${{api.LIZARD_PRIVATE_DOMAIN}}:8080' --service webGestionar en el dashboard
Abre un servicio en el dashboard (lizard open) y ve a Settings → Networking. Muestra el estado de verificación y DNS de cada dominio y te permite agregar o eliminar hostnames.
Ver también
lizard domain: la referencia completa de comandos.- Regiones: co-ubicar servicios y addons para reducir la latencia.
- De prototipo a un SaaS por el que pagan: dónde encaja un dominio personalizado entre las demás cosas que una app generada todavía necesita.
Actualizado