Despliegue y configuración
En el artículo anterior, cubrimos los conceptos básicos de comenzar rápidamente con Logto. Este artículo profundiza más, centrándose en las mejores prácticas y pasos detallados de configuración para desplegar Logto en un entorno de producción.
Variables de entorno
Usamos un conjunto predefinido de variables de entorno en nuestra demostración (docker-compose.yml
), que deberías reemplazar con las tuyas y mantener la consistencia en múltiples instancias de Logto.
Puedes establecer las variables de entorno directamente o colocar un archivo .env
dentro de la raíz del proyecto Logto. Si estás probando con Docker, revisa el .env
generado de la imagen en /etc/logto
.
Esenciales
DB_URL
El DSN de Postgres para la base de datos de Logto.PORT
El puerto al que Logto escucha. Por defecto3001
.ENDPOINT
Puedes especificar una URL con tu dominio personalizado para producción (Ej.ENDPOINT=https://logto.domain.com
). Esto también afectará el valor del identificador del emisor de OIDC.
Habilitar la Consola de Administración
ADMIN_PORT
El puerto al que la Consola de Administración de Logto escucha. Por defecto3002
.ADMIN_ENDPOINT
Puedes especificar una URL con tu dominio personalizado para producción (Ej.ADMIN_ENDPOINT=https://admin.domain.com
). Esto también afectará el valor de los URIs de redirección de la Consola de Administración.
Deshabilitar la Consola de Administración
ADMIN_DISABLE_LOCALHOST
Establécelo en1
otrue
para cerrar el puerto de la Consola de Administración. SiADMIN_ENDPOINT
no está configurado, deshabilitará completamente la Consola de Administración.
Para más detalles sobre las variables de entorno, consulta Configuración.
HTTPS
Puedes usar Node.js para servir HTTPS directamente o configurar un proxy / balanceador HTTPS frente a Node.js. Consulta Habilitar HTTPS para más detalles.
Proxy inverso
Si deseas usar un proxy inverso en tu servidor, por ejemplo Nginx o Apache, necesitas mapear los puertos 3001 y 3002 por separado en tu configuración de paso de proxy. Suponiendo que estás usando Nginx, tu endpoint de autenticación de Logto está ejecutándose en el puerto 3001, y tu consola de administración de Logto está ejecutándose en el 3002, coloca la siguiente configuración en nginx.conf:
server {
listen 443 ssl;
server_name <your_endpoint_url>; // ej. auth.your-domain.com
...
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:3001;
}
ssl_certificate <path-to-your-certificate-for-auth-endpoint>;
ssl_certificate_key <path-to-your-certificate-key-for-auth-endpoint>
...
}
Luego agrega una configuración similar para tu consola de administración:
server {
listen 443 ssl;
server_name <your_admin_endpoint_url>; // ej. admin.your-domain.com
...
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:3002;
}
ssl_certificate <path-to-your-certificate-for-admin-endpoint>;
ssl_certificate_key <path-to-your-certificate-key-for-admin-endpoint>
...
}
Recarga la configuración de Nginx para aplicar los últimos cambios:
nginx -s reload
Todo está listo. Abre el navegador y visita https://admin.your-domain.com
, deberías poder ver la página de bienvenida de Logto.
Contenerización
Para producción, puedes usar Docker para contenerizar Logto. Puedes encontrar el Dockerfile en el directorio raíz del proyecto. Si deseas ejecutar múltiples instancias de Logto, por ejemplo, desplegar Logto en un clúster de Kubernetes, hay algunos pasos adicionales que necesitas seguir.
Carpeta de conectores compartida
Por defecto, Logto creará una carpeta connectors
en el directorio raíz de la carpeta core
. Recomendamos compartir la carpeta entre múltiples instancias de Logto, necesitas montar la carpeta packages/core/connectors
al contenedor y ejecutar npm run cli connector add -- --official
para desplegar los conectores.
Aquí tienes un ejemplo mínimo de deployment
para Kubernetes:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: logto
namespace: default
spec:
template:
spec:
volumes:
- name: connectors
emptyDir: {}
initContainers:
- image: ghcr.io/logto-io/logto
command:
- /bin/sh
args:
- '-c'
- 'npm run cli connector add -- --official'
name: init
volumeMounts:
- name: connectors
mountPath: /etc/logto/packages/core/connectors
containers:
- image: ghcr.io/logto-io/logto
name: logto
volumeMounts:
- name: connectors
mountPath: /etc/logto/packages/core/connectors
En este ejemplo, creamos un directorio vacío como un volumen y lo montamos en los contenedores. Luego ejecutamos npm run cli connector add -- --official
en el contenedor de inicialización para descargar los conectores. Finalmente, cada contenedor compartirá la misma carpeta de conectores con nuestros conectores oficiales ya dentro.
Este es un ejemplo de yaml, para ejecutar Logto, necesitas configurar las variables de entorno adecuadamente.
Para producción, puedes reemplazar el volumen de "directorio vacío" con un volumen persistente, y hacer el trabajo de "inicialización" a tu manera, ¡sabes lo que estás haciendo!
Alteración de la base de datos
Similar a los conectores, la alteración de la base de datos necesita ejecutarse en una sola instancia. Puedes usar un trabajo para ejecutar el script de alteración.
La variable de entorno CI=true
es necesaria cuando la alteración se ejecuta de manera no interactiva.
apiVersion: batch/v1
kind: Job
metadata:
name: alteration
spec:
template:
spec:
containers:
- name: alteration
image: ghcr.io/logto-io/logto
imagePullPolicy: Always
env:
- name: CI
value: 'true'
- name: DB_URL
value: postgresql://user:password@localhost:5432/logto
command:
- /bin/sh
args:
- '-c'
- 'npm run alteration deploy latest'
restartPolicy: Never
Consulta Alteración de la base de datos para más detalles sobre el comando de alteración.