このページは Cloud Translation API によって翻訳されました。

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

必要に応じて、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 をオーバーライドします。ユーザー情報は無視されます。この方法は、本番環境インスタンスの内部データベースの新しいコピーで Looker のステージングインスタンスを更新する場合に便利です。ステージングサーバーのライセンスキーと URL は別々に維持されます。

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 インスタンスがデータベースでユーザーを処理して作成すると、起動時に削除されるため、これらの認証情報はファイル外のシークレットマネージャーに保存することをおすすめします。

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

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

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

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

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

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

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

新しいインスタンスの自動プロビジョニング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。