必要に応じて、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
リクエストの本文に含めることができます。したがって、英数字のみを使用することをおすすめします。
例えば、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
ファイルを削除します。
その後 30 分以内に、これらの認証情報を使用して追加のプロビジョニングを行います。その後、認証情報は、内部データベースから削除され、使用できなくなります。これらの初期認証情報を削除すると、アプリケーションに長期間のバックドアが作成されることがなくなり、意図したユースケースがプロビジョニング専用に保たれます。