Si vous le souhaitez, au démarrage d'une nouvelle instance Looker hébergée par le client, vous pouvez la provisionner automatiquement avec une clé de licence, une URL hôte et un compte utilisateur initial.
Provisionner automatiquement une nouvelle instance avec un utilisateur de messagerie
Au démarrage initial, Looker analyse le répertoire looker, où réside le fichier JAR, à la recherche d'un fichier nommé provision.yml. Le format de ce fichier est le suivant :
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"
Si l'instance Looker est toute nouvelle et n'a pas encore été configurée, elle sera provisionnée avec la clé de licence fournie et un compte utilisateur contenant les informations fournies.
Si Looker a déjà été provisionné, les valeurs de la clé de licence et de l'URL hôte remplaceront celles définies dans l'instance. Les informations sur l'utilisateur seront ignorées. Cette approche est utile pour mettre à jour une instance de préproduction de Looker avec une copie récente de la base de données interne d'une instance de production, tout en conservant une clé de licence et une URL distinctes pour le serveur de préproduction.
Provisionner automatiquement une nouvelle instance avec un utilisateur d'API
Au démarrage d'une nouvelle instance Looker, vous pouvez provisionner un utilisateur d'API initial de manière programmatique. Vous pouvez provisionner un utilisateur d'API ou un utilisateur de messagerie, mais Looker ne permet pas de provisionner à la fois un utilisateur d'API et un utilisateur de messagerie.
Générer des identifiants d'API
Pour provisionner un utilisateur d'API, générez un ID client et un code secret du client que Looker lira et enregistrera dans la base de données. Les exigences concernant ces identifiants sont les suivantes :
- L'ID client doit comporter 20 caractères.
- Le code secret du client doit comporter 24 caractères.
- Les deux chaînes doivent pouvoir être incluses dans le corps d'une requête
POST. Pour cette raison, nous vous recommandons d'utiliser uniquement des caractères alphanumériques pour l'ID client et le code secret du client.
Par exemple, Looker utilise le code suivant pour générer ces identifiants de manière programmatique :
require 'securerandom'
TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze
def generate_token(size)
Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end
Ce code évite les caractères ambigus pour rendre les chaînes moins sujettes aux erreurs.
Vous pouvez également utiliser la commande openssl pour générer des chaînes appropriées :
openssl rand -hex 10
Le nombre à la fin de la commande openssl correspond au nombre d'octets de la chaîne. Utilisez donc 10 pour l'ID client et 12 pour le code secret du client.
Provisionner l'utilisateur d'API
Pour provisionner un utilisateur d'API au démarrage, assurez-vous de disposer d'un fichier provision.yml qui inclut votre clé de licence et votre URL hôte dans le répertoire looker. Exemple :
license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
Créez un fichier nommé api-provision.yml avec les autorisations 0600 dans le répertoire looker qui inclut les informations sur l'utilisateur d'API. Exemple :
user:
first_name: "Ariel"
last_name: "Q"
client_id: "M9hZb8vRh9bSZzdPxw42"
client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"
Nous vous recommandons de stocker ces identifiants dans un gestionnaire de secrets en dehors de ce fichier, car il sera supprimé au démarrage une fois que l'instance Looker aura traité et créé l'utilisateur dans la base de données.
Au démarrage, si l'instance ne comporte aucun utilisateur, Looker crée un utilisateur d'API administrateur Looker avec ces identifiants et supprime le fichier api-provision.yml du disque.
Une fois que vous vous êtes connecté en tant que nouvel utilisateur, vous devez créer au moins un utilisateur administrateur supplémentaire, car l'utilisateur d'API provisionné sera automatiquement supprimé par Looker.
Suppression automatique des identifiants provisionnés
L'utilisateur d'API provisionné est uniquement destiné à provisionner une nouvelle instance. Il n'est pas destiné à rester indéfiniment sur votre instance.
Looker supprime automatiquement l'utilisateur d'API provisionné lorsque l'une des conditions suivantes est remplie :
- Un utilisateur administrateur autre que l'utilisateur d'API provisionné s'est connecté à l'instance.
- 50 minutes se sont écoulées depuis la première connexion de l'utilisateur d'API provisionné.
Par conséquent, il est important de créer au moins un utilisateur administrateur supplémentaire immédiatement après vous être connecté pour la première fois en tant qu'utilisateur provisionné.