必要に応じて、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 ユーザーをプロビジョニングするには、クライアント ID とクライアント シークレットを生成し、Looker でそれらを取得してデータベースに保存します。これらの認証情報の要件は次のとおりです。
- クライアント ID は 20 文字にする必要があります。
- クライアント シークレットの長さは 24 文字です。
- 両方の文字列を
POST
リクエストの本文に含めることができる必要があるため、英数字のみを使用することをおすすめします。
たとえば、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
上記のコードでは、 characters な文字列を避けることで、文字列のエラーが発生しにくくなります。
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"
認証情報はこのファイルの外部の Secret Manager に保存することをおすすめします。このファイルは、起動時に Looker インスタンスの処理とデータベース内でのユーザーの作成が完了すると削除されるためです。
インスタンスが起動していて、ユーザーが存在しない場合、Looker はこれらの認証情報を使用して Looker 管理 API ユーザーを作成し、api-provision.yml
ファイルをディスクから削除します。
30 分以内にこれらの認証情報を使用して追加のプロビジョニングを行い、認証情報を内部データベースから削除して使用できなくなります。これらの初期認証情報を削除すると、アプリケーションへの長期間有効なバックドアが回避され、意図したユースケースがプロビジョニングで厳密に保持されます。