Aller au contenu principal

Déploiement et configuration

Dans l'article précédent, nous avons couvert les bases pour démarrer rapidement avec Logto. Cet article approfondit le sujet, en se concentrant sur les meilleures pratiques et les étapes de configuration détaillées pour déployer Logto dans un environnement de production.

Variables d'environnement​

Nous utilisons un ensemble prédéfini de variables d'environnement générées dans notre démo (docker-compose.yml), que vous devriez remplacer par les vôtres et maintenir la cohérence entre plusieurs instances de Logto.

Vous pouvez définir les variables d'environnement directement ou placer un fichier .env à la racine du projet Logto. Si vous testez avec Docker, consultez le fichier .env généré dans /etc/logto.

Essentiels​

  • DB_URL Le Postgres DSN pour la base de données Logto.
  • PORT Le port auquel Logto écoute. Par défaut 3001.
  • ENDPOINT Vous pouvez spécifier une URL avec votre domaine personnalisé pour la production (par exemple ENDPOINT=https://logto.domain.com). Cela affectera également la valeur de l'identifiant de l' Émetteur (OIDC) (OIDC issuer identifier).

Activer la console d'administration

  • ADMIN_PORT Le port auquel la console d'administration Logto écoute. Par défaut 3002.
  • ADMIN_ENDPOINT Vous pouvez spécifier une URL avec votre domaine personnalisé pour la production (par exemple ADMIN_ENDPOINT=https://admin.domain.com). Cela affectera également la valeur des URI de redirection de la console d'administration.

Désactiver la console d'administration

  • ADMIN_DISABLE_LOCALHOST Réglez-le sur 1 ou true pour fermer le port de la console d'administration. Avec ADMIN_ENDPOINT non défini, cela désactivera complètement la console d'administration.

Pour plus de détails sur les variables d'environnement, voir Configuration.

HTTPS​

Vous pouvez utiliser Node.js pour servir HTTPS directement ou configurer un proxy / équilibreur HTTPS devant Node.js. Voir Activation de HTTPS pour plus de détails.

Proxy inverse​

Si vous souhaitez utiliser un proxy inverse sur votre serveur, par exemple Nginx ou Apache, vous devez mapper les ports 3001 et 3002 séparément dans vos paramètres de proxy pass. En supposant que vous utilisiez Nginx, votre point de terminaison d'authentification Logto fonctionne sur le port 3001, et votre console d'administration Logto fonctionne sur le port 3002, mettez la configuration suivante dans nginx.conf :

server {
  listen 443 ssl;
  server_name <your_endpoint_url>; // par exemple 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>
  ...
}

Ajoutez ensuite une configuration similaire pour votre console d'administration :

server {
  listen 443 ssl;
  server_name <your_admin_endpoint_url>; // par exemple 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>
  ...
}

Rechargez la configuration Nginx pour prendre en compte les dernières modifications :

nginx -s reload

Tout est prêt. Ouvrez le navigateur et visitez https://admin.your-domain.com, vous devriez voir la page d'accueil de Logto.

Conteneurisation​

Pour la production, vous pouvez utiliser Docker pour conteneuriser Logto. Vous pouvez trouver le Dockerfile dans le répertoire racine du projet. Si vous souhaitez exécuter plusieurs instances de Logto, par exemple, déployer Logto dans un cluster Kubernetes, il y a quelques étapes supplémentaires à suivre.

Dossier de connecteurs partagé​

Par défaut, Logto créera un dossier connectors dans le répertoire racine du dossier core. Nous recommandons de partager le dossier entre plusieurs instances de Logto, vous devez monter le dossier packages/core/connectors dans le conteneur et exécuter npm run cli connector add -- --official pour déployer les connecteurs.

Voici un exemple minimal de deployment pour 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

Dans cet exemple, nous créons un répertoire vide en tant que volume et le montons dans les conteneurs. Ensuite, nous exécutons npm run cli connector add -- --official dans le conteneur d'initialisation pour télécharger les connecteurs. Enfin, chaque conteneur partagera le même dossier de connecteurs avec nos connecteurs officiels déjà à l'intérieur.

remarque

Ceci est un exemple de yaml, pour exécuter Logto, vous devez configurer correctement les variables d'environnement.

Pour la production, vous pouvez remplacer le volume "empty dir" par un volume persistant, et faire le travail "init" à votre manière, vous savez ce que vous faites !

Modification de la base de données​

Similaire aux connecteurs, la modification de la base de données doit être exécutée dans une seule instance. Vous pouvez utiliser un job pour exécuter le script de modification.

La variable d'environnement CI=true est nécessaire lorsque la modification est exécutée de manière non interactive.

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

Voir Modification de la base de données pour plus de détails sur la commande de modification.