新しいインスタンスの自動プロビジョニング

必要に応じて、Looker のセルフホスト型の新しいインスタンスの起動時に、ライセンスキー、ホスト URL、初期ユーザー アカウントを使ってインスタンスを自動的にプロビジョニングできます。

メールユーザーでの新しいインスタンスの自動プロビジョニング

最初の起動時に、Looker は JAR ファイルが存在する looker ディレクトリで provision.yml という名前のファイルをスキャンします。形式は以下のとおりです。

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"

Looker インスタンスが新しく、まだ設定されていない場合は、指定されたライセンスキーと、提供された情報を含むユーザー アカウントでプロビジョニングされます。

Looker がすでにプロビジョニングされている場合、ライセンスキーとホスト URL の値は、インスタンスに設定されているライセンスキーとホスト URL をオーバーライドします。ユーザー情報は無視されます。この方法は、ステージング サーバーのライセンスキーと URL を別々に維持しながら、本番環境インスタンスの内部データベースの新しいコピーで Looker のステージング インスタンスを更新する場合に便利です。

API ユーザーでの新しいインスタンスの自動プロビジョニング

新しい Looker インスタンスの起動時に、最初の API ユーザーをプログラムでプロビジョニングできます。API ユーザーまたは メールユーザーをプロビジョニングできますが、Looker では API ユーザーとメールユーザーの両方を同時にプロビジョニングすることはできません。

API 認証情報を生成する

API ユーザーをプロビジョニングするには、Looker が読み取ってデータベースに保存するクライアント ID とクライアント シークレットを生成します。これらの認証情報の要件は次のとおりです。

  • クライアント ID は 20 文字にする必要があります。
  • クライアント シークレットは 24 文字にする必要があります。
  • どちらの文字列も POST リクエストの本文に含めることができる必要があります。そのため、クライアント ID とクライアント シークレットには英数字のみを使用することをおすすめします。

たとえば、Looker は次のコードを使用して、これらの認証情報をプログラムで生成します。

require 'securerandom'

TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze

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

このコードでは、あいまいな文字を避けて、文字列のエラーが発生しにくくしています。

openssl コマンドを使用して適切な文字列を生成することもできます。

openssl rand -hex 10

openssl コマンドの末尾の数字は文字列のバイト数です。クライアント ID には 10、クライアント シークレットには 12 を使用します。

API ユーザーをプロビジョニングする

起動時に API ユーザーをプロビジョニングするには、ライセンスキーとホスト URL を含む provision.yml ファイルが looker ディレクトリにあることを確認します。例:

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"

API ユーザー情報が含まれる looker ディレクトリに、権限 0600 で api-provision.yml という名前のファイルを作成します。次に例を示します。

user:
  first_name: "Ariel"
  last_name: "Q"
  client_id: "M9hZb8vRh9bSZzdPxw42"
  client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"

このファイルは、Looker インスタンスがデータベースでユーザーを処理して作成すると、起動時に削除されるため、これらの認証情報は、このファイル以外の Secret Manager に保存することをおすすめします。

起動時に、インスタンスにユーザーがいない場合、Looker はこれらの認証情報を使用して Looker Admin API ユーザーを作成し、api-provision.yml ファイルをディスクから削除します。

新しいユーザーとしてログインしたら、プロビジョニングされた API ユーザーは Looker によって自動的に削除されるため、少なくとも 1 つの追加の管理者ユーザーを作成する必要があります。

プロビジョニングされた認証情報の自動削除

プロビジョニングされた API ユーザーは、新しいインスタンスのプロビジョニングのみを目的としており、インスタンスに無期限に残すことを目的としていません。

Looker は、次のいずれかの条件が満たされると、プロビジョニングされた API ユーザーを自動的に削除します。

  • プロビジョニングされた API ユーザー以外の管理者ユーザーがインスタンスにログインした。
  • プロビジョニングされた API ユーザーが最初にログインしてから 50 分が経過した。

そのため、プロビジョニングされたユーザーとして初めてログインしたら、すぐに少なくとも 1 つの追加の管理者ユーザーを作成することが重要です。