Opcionalmente, na inicialização de uma nova instância hospedada pelo cliente do Looker, você pode provisionar automaticamente a instância com uma chave de licença, um URL do host e uma conta de usuário inicial.
Provisionar automaticamente uma nova instância com um usuário de e-mail
Na inicialização, o Looker verifica o diretório looker, onde o arquivo JAR está localizado, em busca de um arquivo com o nome provision.yml. O formato desse arquivo é o seguinte:
license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
user:
first_name: "Ariel"
last_name: "Q"
email: "arielq@altostrat.com"
password: "password123"
Se a instância do Looker for nova e ainda não tiver sido configurada, ela será provisionada com a chave de licença e uma conta de usuário com as informações fornecidas.
Se o Looker já tiver sido provisionado, a chave de licença e os valores de URL do host vão substituir a chave de licença e o URL do host definidos na instância. As informações do usuário serão ignoradas. Essa abordagem é útil para atualizar uma instância de teste do Looker com uma cópia atualizada do banco de dados interno de uma instância de produção, mantendo uma chave de licença e um URL separados para o servidor de teste.
Provisionar automaticamente uma nova instância com um usuário da API
Ao iniciar uma nova instância do Looker, é possível provisionar um usuário inicial da API de maneira programática. É possível provisionar um usuário da API ou um usuário de e-mail, mas o Looker não permite provisionar um usuário da API e um usuário de e-mail ao mesmo tempo.
Como gerar credenciais de API
Para provisionar um usuário da API, gere um ID e uma chave secreta do cliente que o Looker vai ler e salvar no banco de dados. Os requisitos para essas credenciais são os seguintes:
- O ID do cliente precisa ter 20 caracteres.
- A chave secreta do cliente precisa ter 24 caracteres.
- As duas strings precisam ser incluídas no corpo de uma solicitação
POST. Por isso, recomendamos que você use apenas caracteres alfanuméricos para o ID e a chave secreta do cliente.
Por exemplo, o Looker usa o seguinte código para gerar essas credenciais de maneira programática:
require 'securerandom'
TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze
def generate_token(size)
Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end
Esse código evita caracteres ambíguos para reduzir a probabilidade de erros nas strings.
Também é possível usar o comando openssl para gerar strings adequadas:
openssl rand -hex 10
O número no final do comando openssl é o número de bytes na string. Portanto, use 10 para o ID do cliente e 12 para a chave secreta do cliente.
Provisionar o usuário da API
Para provisionar um usuário da API na inicialização, verifique se você tem um arquivo provision.yml que inclui a chave de licença e o URL do host no diretório looker. Exemplo:
license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
Crie um arquivo chamado api-provision.yml com as permissões 0600 no diretório looker que inclui as informações do usuário da API. Exemplo:
user:
first_name: "Ariel"
last_name: "Q"
client_id: "M9hZb8vRh9bSZzdPxw42"
client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"
Recomendamos que você armazene essas credenciais em um gerenciador de secrets fora desse arquivo, já que ele será removido na inicialização assim que a instância do Looker processar e criar o usuário no banco de dados.
Na inicialização, se a instância não tiver usuários, o Looker vai criar um usuário da API de administrador do Looker com essas credenciais e remover o arquivo api-provision.yml do disco.
Depois de fazer login como o novo usuário, crie pelo menos mais um usuário administrador, já que o usuário da API provisionado será excluído automaticamente pelo Looker.
Exclusão automática de credenciais provisionadas
O usuário da API provisionado se destina apenas ao provisionamento de uma nova instância e não deve permanecer na sua instância indefinidamente.
O Looker exclui automaticamente o usuário da API provisionado quando uma das seguintes condições é atendida:
- Um usuário administrador diferente do usuário da API provisionado fez login na instância.
- 50 minutos se passaram desde que o usuário da API provisionada fez login pela primeira vez.
Portanto, é importante criar pelo menos um usuário administrador adicional imediatamente após fazer login como o usuário provisionado pela primeira vez.