Implantação e configuração
No artigo anterior, abordamos o básico de como começar rapidamente com o Logto. Este artigo aprofunda mais, focando em melhores práticas e etapas detalhadas de configuração para implantar o Logto em um ambiente de produção.
Variáveis de ambiente
Usamos um conjunto gerado de variáveis de ambiente em nosso demo (docker-compose.yml
), que você deve substituir pelas suas próprias e manter a consistência entre várias instâncias do Logto.
Você pode definir as variáveis de ambiente diretamente ou colocar um arquivo .env
na raiz do projeto Logto. Se estiver testando com Docker, confira o .env
gerado da imagem em /etc/logto
.
Essenciais
DB_URL
O DSN do Postgres para o banco de dados do Logto.PORT
A porta que o Logto escuta. Padrão3001
.ENDPOINT
Você pode especificar uma URL com seu domínio personalizado para produção (Ex.:ENDPOINT=https://logto.domain.com
). Isso também afetará o valor do identificador do emissor OIDC.
Habilitar o Admin Console
ADMIN_PORT
A porta que o Logto Admin Console escuta. Padrão3002
.ADMIN_ENDPOINT
Você pode especificar uma URL com seu domínio personalizado para produção (Ex.:ADMIN_ENDPOINT=https://admin.domain.com
). Isso também afetará o valor dos URIs de redirecionamento do Admin Console.
Desabilitar o Admin Console
ADMIN_DISABLE_LOCALHOST
Defina como1
outrue
para fechar a porta do Admin Console. ComADMIN_ENDPOINT
não definido, desabilitará completamente o Admin Console.
Para mais detalhes sobre variáveis de ambiente, veja Configuração.
Habilitar o Secret Vault
- Para usar o Secret Vault, você precisa definir
SECRET_VAULT_KEK
como uma string codificada em base64 da sua Key Encryption Key (KEK). Isso é usado para criptografar as Data Encryption Keys (DEK) no Secret Vault. Recomenda-se AES-256 (32 bytes). Exemplo:crypto.randomBytes(32).toString('base64')
.
HTTPS
Você pode usar Node.js para servir HTTPS diretamente ou configurar um proxy / balanceador HTTPS na frente do Node.js. Veja Habilitando HTTPS para detalhes.
Proxy reverso
Se você quiser usar proxy reverso em seu servidor, por exemplo Nginx ou Apache, você precisa mapear as portas 3001 e 3002 separadamente nas configurações do proxy pass. Supondo que você esteja usando Nginx, seu endpoint de autenticação do Logto está rodando na porta 3001 e seu admin console do Logto está rodando na 3002, coloque a seguinte configuração no nginx.conf:
server {
listen 443 ssl;
server_name <your_endpoint_url>; // ex.: auth.seu-dominio.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 <caminho-para-seu-certificado-do-endpoint-auth>;
ssl_certificate_key <caminho-para-sua-chave-do-endpoint-auth>
...
}
Depois adicione uma configuração similar para seu admin console:
server {
listen 443 ssl;
server_name <your_admin_endpoint_url>; // ex.: admin.seu-dominio.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 <caminho-para-seu-certificado-do-endpoint-admin>;
ssl_certificate_key <caminho-para-sua-chave-do-endpoint-admin>
...
}
Recarregue a configuração do Nginx para aplicar as últimas alterações:
nginx -s reload
Tudo pronto. Abra o navegador e acesse https://admin.seu-dominio.com
, você deverá ver a página de boas-vindas do Logto.
Containerização
Para produção, você pode usar Docker para containerizar o Logto. Você encontra o Dockerfile no diretório raiz do projeto. Se quiser rodar múltiplas instâncias do Logto, por exemplo, implantar o Logto em um cluster Kubernetes, há alguns passos adicionais que você precisa seguir.
Pasta de conectores compartilhada
Por padrão, o Logto criará uma pasta connectors
no diretório raiz da pasta core
. Recomendamos compartilhar essa pasta entre múltiplas instâncias do Logto; você precisa montar a pasta packages/core/connectors
no container e rodar npm run cli connector add -- --official
para implantar os conectores.
Aqui está um exemplo 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
Neste exemplo, criamos um diretório vazio como volume e o montamos nos containers. Em seguida, rodamos npm run cli connector add -- --official
no init container para baixar os conectores. Por fim, cada container compartilhará a mesma pasta de conectores já com nossos conectores oficiais dentro.
Este é um exemplo de yaml, para rodar o Logto, você precisa definir as variáveis de ambiente corretamente.
Para produção, você pode substituir o volume "empty dir" por um volume persistente e fazer o trabalho de "init" do seu próprio jeito, você sabe o que está fazendo!
Alteração do banco de dados
Assim como os conectores, a alteração do banco de dados precisa ser executada em uma única instância. Você pode usar um job para rodar o script de alteração.
A variável de ambiente CI=true
é necessária quando a alteração é executada de forma não interativa.
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
Veja Alteração do banco de dados para detalhes sobre o comando de alteração.