Provisionner automatiquement une nouvelle instance Looker

Au démarrage d'une nouvelle instance Looker hébergée par un client, vous pouvez la provisionner automatiquement avec une clé de licence, une URL d'hôte et un compte utilisateur initial.

Provisionner automatiquement une nouvelle instance pour un utilisateur de messagerie

Au démarrage initial, Looker recherche un fichier nommé provision.yml dans le répertoire looker, qui contient le fichier JAR. 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 nouvelle et n'a pas encore été configurée, elle sera provisionnée avec la clé de licence donnée et un compte utilisateur avec les informations fournies.

Si Looker a déjà été provisionné, les valeurs de la clé de licence et de l'URL de l'hôte remplacent les clés de licence et l'URL d'hôte définies actuellement. Les informations utilisateur seront ignorées. Cela est utile pour mettre à jour une instance de préproduction Looker avec une nouvelle copie 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 intermédiaire.

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 d'e-mail, mais Looker ne permet pas de provisionner à la fois un utilisateur d'API et un utilisateur d'e-mail.

Générer des identifiants pour l'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 pour 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. Il est donc recommandé de n'utiliser que des caractères alphanumériques.

Par exemple, Looker utilise le code suivant pour générer ces identifiants par programmation:

require 'securerandom'

TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze

def generate_token(size)
  Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end

Le code ci-dessus évite les caractères ambigus pour que les chaînes soient moins sujettes aux erreurs.

Vous pouvez également générer des chaînes appropriées à l'aide de la commande openssl:

openssl rand -hex 10

Le nombre à la fin de la commande openssl correspond au nombre d'octets de la chaîne. Vous devez donc utiliser 10 pour l'ID client et 12 pour le code secret du client.

Provisionner l'utilisateur de l'API

Pour provisionner un utilisateur d'API au démarrage, assurez-vous de disposer d'un fichier provision.yml contenant votre clé de licence et l'URL d'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 de l'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 ce fichier 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 est vide et qu'aucun utilisateur n'est présent, Looker crée un utilisateur de l'API Admin Looker avec ces identifiants et supprime le fichier api-provision.yml du disque.

Vous disposez ensuite de 30 minutes pour utiliser ces identifiants afin d'effectuer un provisionnement supplémentaire. Passé ce délai, ils sont supprimés de la base de données interne et ne sont plus utilisables. La suppression de ces identifiants initiaux évite de créer une porte dérobée de longue durée dans l'application et de limiter le cas d'utilisation prévu au provisionnement.