Looker のドキュメントを表示していることに注意してください。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

Looker CI/CD のインストールと構成

このページでは、Looker で CI/CD ワークフローを実装するために必要なコンポーネントをインストールして構成する方法について説明します。

この手順では、開発、QA、本番からなる 3 層システムを使用します。ただ、同じ原則は 2 層および 4 層のシステムにも適用できます。

またこの手順では、Git プロバイダとして GitHub を使用することを前提としています。他の Git プロバイダを使用して CI/CD ワークフローを作成できますが、プロバイダに合わせてこれらの手順を変更する場合は、専門知識が必要です。

関連するセクションの手順に沿って操作します。

前提条件
初回のみのセットアップ手順
各 Looker デベロッパー向けのセットアップ手順

前提条件

Linux 環境

このプロセスでは、Unix のようなオペレーティングシステムで動作するように設計された Gazer と Spectacles というツールを使用します。各 LookML デベロッパーは、CI/CD ワークフローを実行する予定の Linux 環境または macOS のコマンドラインにアクセスできる必要があります。

Windows を使用している場合、Microsoft の Windows Subsystem For Linux（WSL）内で Gazer と Spectacles を使用できます。WSL では、さまざまな Linux フレーバーを実行できます。適した Linux オペレーティングシステムがない場合は、サポートが幅広い最新バージョンの Ubuntu Linux を使用することをおすすめします。

以下の手順では Linux システムの例を示しています。macOS または WSL を使用している場合は、変更が必要になる場合があります。

階層ごとに 1 つの Looker インスタンス

この構成を有効にするには、システムの階層ごとに 1 つの Looker インスタンスが必要になります。たとえば、開発ステージ、QA ステージ、本番環境ステージがあるシステムの場合、3 つの個別のインスタンスが必要になります。インスタンスは、Google がホストする場合もあれば、セルフホスト型の場合もあります。

同じ接続名

データベース接続は、どの階層を表すかに関係なく、各 Looker インスタンス内で同じ名前にする必要があります。たとえば、sales 接続では、すべてのインスタンスでこの名前が使用されます（sales_dev や sales_qa は使用されません）。

接続は、同じデータベースを指すことも、異なるデータベースを指すこともできます。ただし、同じデータベースを参照している場合は、開発または QA インスタンスの永続的な派生テーブルが本番環境を妨げないように、異なるスクラッチスキーマを定義する必要があります。

たとえば、3 つのインスタンスすべてに同じデータベースを使用する場合は、次のように構成されます。

	本番環境	QA	開発環境
接続名	`sales`	`sales`	`sales`
データベース	`sales_db`	`sales_db`	`sales_db`
スクラッチスキーマ	`prod_sales_scratch`	`qa_sales_scratch`	`dev_sales_scratch`

また、3 つのインスタンスすべてに一意のデータベースを使用する場合は、次のように構成されます。

	本番環境	QA	開発環境
接続名	`sales`	`sales`	`sales`
データベース	`sales_db_prod`	`sales_db_qa`	`sales_db_dev`
スクラッチスキーマ	`sales_scratch`	`sales_scratch`	`sales_scratch`

Git リポジトリ

3 つの階層すべてのプロジェクトごとに、単一の git リポジトリが使用されます。開発インスタンスは main ブランチを追跡しますが、QA と本番環境インスタンスは一般的に git タグを参照します（詳細は後で説明します）。

初回のみのセットアップ手順

このセクションの手順は、Looker 管理者の権限と git プロバイダの管理者権限を持つユーザーが 1 回だけ完了する必要があります。

Git 認証情報

各開発者の Linux 環境は、LookML の管理に使用しているものと同じリポジトリに接続する必要があります。これはおそらく、GitHub などのサービスでホストされている外部リポジトリです。リポジトリを構成するには、適切な認証情報を持つこのサービスのアカウントが必要です。アカウントを使用して SSH 認証鍵を設定し、Linux 環境からそのサービスに自動的に接続できます。

GitHub の場合は、GitHub アカウントへの新しい SSH 認証鍵の追加の手順を行います。

Git サーバーリポジトリの作成と構成

CI/CD ワークフローを機能させるには、LookML を git リポジトリに保存し、Looker プロジェクトに接続する必要があります。プロジェクト設定で [Git 本番環境のブランチ名] を main に設定し、[Enable Advanced Deploy Mode] を有効にする必要があります。

次の手順がまだ実行されていない場合は、GitHub の次の手順を行います。

新しいリポジトリの作成

GitHub UI で、右上の [+] ボタンをクリックし、[新しいリポジトリ] を選択します。
オーナー（通常は組織）を選択し、REPOSITORY_NAME を入力します。
リポジトリを公開するか非公開にするか（非公開リポジトリには有料の GitHub サブスクリプションが必要です）を選択し、チェックボックスをオンにして README ファイルで初期化します。
[リポジトリを作成] ボタンをクリックします。
[<> コード] というラベルの付いた緑色のボタンを押して、SSH URL をコピーします。次のようになります: git@github.com:org_name/REPOSITORY_NAME.git.
Looker で、新しいプロジェクトを作成します。
開発モードに入り、左側のバーからプロジェクト設定項目を選択して、[Git を構成] を選択します。
リポジトリの URL（この例では git@github.com:org_name/REPOSITORY_NAME.git）を貼り付け、[Continue] を選択します。
デプロイキーをコピーし、このリポジトリの GitHub UI に戻ります。
[設定]、[キーをデプロイ] の順に選択します。
[Add deploy key] ボタンをクリックして、デプロイキーを [Key] フィールドに貼り付けます。
Looker-REPOSITORY_NAME などのタイトルを追加し、[書き込みアクセスを許可] チェックボックスをオンにして、[キーを追加] ボタンを押します。
Looker に戻り、[設定のテストとファイナライズ] を選択します。
左側のバーから [プロジェクトの設定] をもう一度選択します。[Git 本番環境のブランチ名] を main に変更します。
[高度なデプロイモードの有効化] を選択し、[プロジェクト構成の保存] を選択します。

左側のプロジェクト設定アイコンの下に、Deployment Manager のデプロイアイコンが表示されます。

既存のリポジトリを使用する

LookML が保存されている GitHub リポジトリに移動します。
[<> コード] というラベルの付いた緑色のボタンを押して、SSH URL をコピーします。次のようになります: git@github.com:org_name/REPOSITORY_NAME.git.
Looker で、新しいプロジェクトを作成します。
開発モードに入り、左側のバーからプロジェクト設定項目を選択して、[Git を構成] をクリックします。
リポジトリの URL（この例では git@github.com:org_name/REPOSITORY_NAME.git）を貼り付け、[Continue] を選択します。
デプロイキーをコピーし、このリポジトリの GitHub UI に戻ります。
[設定]、[キーをデプロイ] の順に選択します。
[Add deploy key] ボタンをクリックして、デプロイキーを [Key] フィールドに貼り付けます。
Looker-REPOSITORY_NAME などのタイトルを追加し、[書き込みアクセスを許可] チェックボックスをオンにして、[キーを追加] ボタンを押します。
Looker に戻り、[設定のテストとファイナライズ] を選択します。
左側のバーから [プロジェクトの設定] をもう一度選択します。[Git 本番環境のブランチ名] を main に変更します。
[高度なデプロイモードの有効化] を選択し、[プロジェクト構成の保存] を選択します。

左側のプロジェクト設定アイコンの下に、Deployment Manager のデプロイアイコンが表示されます。

GitHub アクションの作成

LookML が変更されるたびにさまざまなチェックが自動的に行われるように、複数の GitHub アクションを作成すると便利です。これらのアクションを追加するには、Linux 環境の Git リポジトリを変更できるようにする必要があります。まだできない場合は、下の Git の構成の手順に従ってください。

GitHub アクションを追加するには、Linux 環境でリポジトリのディレクトリに移動し、サブディレクトリ .github/workflows を追加します。設定後、GitHub UI の [Actions] ページからこれらのアクションを手動で実行できます。

Look-At-Me-Sideways（LAMS）

LAMS は、LookML のエラーや不正行為を検査するオープンソースのリンターです。次の内容を含む lams.yml という名前のファイルを .github/workflows ディレクトリに追加します。

name: LAMS

on:
  pull_request:
    branches: [ main ]
  push:
  workflow_dispatch:

jobs:
  lams_job:
    runs-on: ubuntu-latest
    name: LAMS LookML Linter Job
    steps:
    - name: Checkout your LookML
      uses: actions/checkout@v1
    - name: Setup Node
      uses: actions/setup-node@v1
      with:
        node-version: '16.x'
    - name: Install LAMS
      run: npm install -g @looker/look-at-me-sideways@3
    - name: Run LAMS
      run: lams --reporting=no

commit が GitHub に push されるか、pull リクエストが開かれてコードが main ブランチとマージされるたびに、LAMS が実行されます。

Release Please

Release Please は、リリースに適切なバージョン番号を自動的にタグ付けするオープンソースツールです。

次の内容を含む release-please.yml という名前のファイルを .github/workflows ディレクトリに追加します。

name: release-please

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          release-type: simple
          package-name: sales_project

従来の commit

この GitHub アクションにより、従来の commit 標準に準拠したタイトルで pull リクエストが開かれるようになります。

次の内容を含む lint_pr_title.yml という名前のファイルを .github/workflows ディレクトリに追加します。

name: "Lint Pull Request Title"

on:
  pull_request_target:
    types:
      - opened
      - edited
      - synchronize

jobs:
  main:
    name: Validate PR title
      runs-on: ubuntu-latest
      steps:
        - uses: amannn/action-semantic-pull-request@v5
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

変更を GitHub に push する

最後に、次のコマンドを使用して GitHub アクションの変更を commit し、GitHub に push します。

git add .github/workflows/
git commit -m "chore: Added github actions"
git push

`main` ブランチの保護

GitHub UI では、通常のデベロッパーがそのブランチに変更を直接 push できないように、main ブランチに対してブランチ保護を有効にする必要があります。そうではなく、別のブランチで変更を行ってから、pull リクエストを開きます。pull リクエストは、承認されて main にマージされる前に別のデベロッパーがレビューできます。

ブランチ保護を構成するには、リポジトリの GitHub UI に移動し、[設定]、[Branches] の順に選択し、[Add branch protection rule] ボタンを押します。

ブランチ保護を追加するための GitHub UI。

[Branch name pattern] として「main」と入力し、次のオプションをオンにします。

マージ前に pull リクエストを必須にする
承認を必須にする
新しい commit が push されたときに古い pull リクエストの承認を閉じる

ブランチ保護オプションを設定するための GitHub UI。

最後に、ページ下部にある [作成] ボタンをクリックします。

pull リクエストが作成されると、前の手順で構成した GitHub アクションが実行されます。初めて実行した後にこの UI で選択することで、pull リクエストを main にマージできるようになる前に成功する必要があるようにすることもできます。

pull リクエストの構成

Looker では、pull リクエストの使用を必須にして、デベロッパーの代わりに Looker を PR を開くようにすることができます。これは開発インスタンスに対してのみ構成する必要があります。QA インスタンスと本番環境インスタンスは、高度なデプロイモードを使用して更新を取得します。

これを有効にするには、各プロジェクトの [Project Settings] に移動し、[GitHub Integration] という見出しの下の [Pull Requests Required] を選択します。

pull リクエストを必須にするための Looker UI。

ボタンを押して Webhook シークレットを設定し、生成されたランダムな文字列をコピーして、[Save Project Configuration] ボタンを押します。

リポジトリの GitHub UI に戻り、[Settings]、[Webhooks] の順に選択します。右上の [Webhook を追加] ボタンを押します。

[Payload URL] というラベルのフィールドに「https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deploy」と入力します。
[Secret] というラベルの付いたフィールドに、Looker から保存した Secret を貼り付けます。
[Which events would you like to trigger this webhook?] の質問に対して、[Let me select individual events] を選択します。

Webhook を構成するための GitHub UI。

[pull リクエスト] と [push] が選択されていることを確認します。

pull リクエストと push 用の GitHub チェックボックス。

最後に、ページ下部にある [Webhook を追加] ボタンを押します。

各 Looker デベロッパー向けのセットアップ手順

次のインストール手順はすべて、Linux 環境で行う必要があります。

Ruby のインストール

Gazer を実行するには、Ruby プログラミング言語をインストールする必要があります。2.7.7 以降の Ruby はすべて Gazer で使用できますが、Ruby 3.xx を推奨します。Ubuntu Linux に Ruby をインストールするには、次のコマンドを実行します。

sudo apt update
sudo apt install ruby

ruby -v を実行して、ruby が正しくインストールされていることを確認します。その結果、次のようなレスポンスが返されます。

ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]

これらのコマンドは、Debian Linux、Linux Mint、および Aptitude パッケージマネージャーを使用する他の Linux フレーバーでも動作します。他の Linux フレーバーで機能するコマンドの検索や、macOS にインストールするためのコマンドの検索が必要になる場合があります。詳細については、Ruby のインストールをご覧ください。

Gazer のインストール

Gazer は、Google の社員が作成したオープンソースプロジェクトであり、コマンドラインツールを使用してスペース、Look、ダッシュボードの操作や管理を行うことができます。

Ruby がインストールされている場合は、Ruby の Gem ツールを使用して Gazer をインストールできます。

gem install gazer

gzr version コマンドを使用して、Gazer がインストールされていることを確認します。その結果、次のようなレスポンスが返されます。

v0.3.12

Spectacles のインストール

Spectacles は、LookML のテストに使用される Google 以外のツールです。Spectacles は有料バージョンとオープンソースバージョンの両方を提供しています。インストールの詳細については、スタートガイドをご覧ください。

Git のインストール

Git バージョン管理ソフトウェアは、次のコマンドを使用して Ubuntu Linux にインストールできます。

sudo apt update
sudo apt install git

git --version コマンドを実行して、インストールが成功したことを確認します。その結果、次のようなレスポンスが返されます。

git version 2.42.0.609.gbb76f46606

これらのコマンドは、Debian Linux、Linux Mint、および Aptitude パッケージマネージャーを使用する他の Linux フレーバーでも動作します。他の Linux フレーバーで使用できるコマンドの検索が必要になる場合があります。たとえば、Fedora や macOS の手順については、スタートガイド - Git のインストールをご覧ください。

Git の構成

Linux 環境の Git は、LookML が保存されている Git リポジトリとやり取りを行えるように構成する必要があります。この手順は、GitHub に保存されている LookML Git リポジトリ向けに作成されています。

名前とメール

GitHub（およびその他のほとんどの Git 実装）は、アクティビティを記録できるように名前とメールアドレスを把握する必要があります。次のコマンドを実行して、Git で名前とメールを構成します。

git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"

Git 認証情報

初回の CI/CD 設定で、git 認証情報が作成されています。生成された秘密 SSH 認証鍵は、$HOME/.ssh/config ファイルで構成する必要があります。ファイルを作成するには、次のコマンドを使用します。

touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config

次のテキストを $HOME/.ssh/config ファイルに挿入します。

Host github.com
  User git
  IdentityFile ~/.ssh/KEY_NAME
  ControlMaster auto
  ControlPath ~/.ssh/ctrl-%r@%h:%p
  ControlPersist yes

KEY_NAME の代わりに、GitHub アカウントへの新しい SSH 認証鍵の追加の手順で生成した秘密鍵ファイルの名前を使用します。秘密鍵ファイルの名前は公開鍵ファイルと同じですが、.pub 拡張子はありません。たとえば、ファイル id_ed25519.pub に含まれる公開鍵を使用した場合、秘密鍵の名前は id_ed25519 になります。

ローカル Git リポジトリの設定

LookML リポジトリを構成したら、Linux 環境にそのコピーを作成する必要があります。これを行うには、次のコマンドを実行します。

git clone GIT_URL

たとえば、コマンドは次のようになります。

git clone git@github.com:my_org_name/sales_project.git

これにより、LookML リポジトリがサブディレクトリ（sales_project など）にコピーされます。cd SUB_DIRECTORY コマンドを使用して、リポジトリに移動します。この例では、コマンドは cd sales_project になります。

リポジトリのディレクトリに移動したら、次のコマンドを使用できます。

コマンド	Purpose
`git checkout BRANCH_NAME`	ブランチを切り替えるために使用されます。ほとんどの場合、プライマリブランチは `main` と呼ばれます。ただし、古いシステムでは `master` と呼ばれる場合があります。
`git fetch`	サーバーから最新の変更を取得するために使用されます。
`git pull`	チェックアウトされたローカルファイルに変更を適用する場合に使用します。`git pull` は、暗黙的に `git fetch` を実行します。
`git tag`	特定のリビジョンにわかりやすいタグを作成するために使用されます。
`git push`	ローカルの変更をサーバーに push するために使用されます。

Gazer の構成

Gazer を使用するには、開発インスタンス、QA インスタンス、本番環境インスタンスそれぞれで API 認証情報が必要です。API 認証情報の作成手順については、管理者設定 - ユーザーのページをご覧ください。API 認証情報は、CI/CD ワークフローを最初に設定したユーザーによってすでに作成されている可能性があります。その場合は、既存の認証情報を使用できます。ユーザーごとに新しい認証情報を生成する必要がありません。

ホームディレクトリで、最小限の権限を持つ .netrc ファイルに API 認証情報を保存します。次のコマンドを使用して、適切な権限を持つ空のファイルを作成できます。

touch $HOME/.netrc
chmod 600 $HOME/.netrc

次のようなエントリをファイルに追加します。ただし、machine には独自の Looker サーバーホスト名、ログインに API client_id、パスワードに API client_secret を使用します。次に例を示します。

machine dev.example.looker.com
  login 80ka7nl6lj87ftmn
  password u7kw3mj5h2trfz0

machine qa.example.looker.com
  login fi3qtv5at5crvd1q
  password bdxtaeghnzyz0wm

machine example.looker.com
  login k7lr6yv57wvzy9p2
  password wcvr5qjd2isbs2s

各サーバーに対して次のような簡単な Gazer コマンドを実行して、これが動作するかをテストします。

gzr user me --host dev.example.looker.com

次のような結果が得られます。

+----+---------------+---------+----------+------------------+--------------+
|  id|email          |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith    |John      |              2161|           708|
+----+---------------+---------+----------+------------------+--------------+

上記のコマンドが機能しない場合、次のように、gzr コマンドの最後に --port 443 を追加する必要がある可能性があります。

gzr user me --host dev.example.looker.com --port 443

Spectacles の構成

Spectacles は、Gazer と同じ API client_id と client_secret を使用します。Spectacles ディレクトリで、階層ごとに config-TIER.yaml という名前のファイルを作成します（例: config-dev.yaml）。その階層の Looker インスタンスに応じて、以下の内容をファイルに追加します。次に例を示します。

config-dev.yaml

base_url: https://dev.example.looker.com/
client_id: 80ka7nl6lj87ftmn
client_secret: u7kw3mj5h2trfz0

config-qa.yaml

base_url: https://qa.example.looker.com/
client_id: fi3qtv5at5crvd1q
client_secret: bdxtaeghnzyz0wm

config-prod.yaml

base_url: https://example.looker.com/
client_id: k7lr6yv57wvzy9p2
client_secret: wcvr5qjd2isbs2s

次のコマンドを実行し、各ファイル名を置き換えて、各ファイルをテストできます。

$ spectacles connect --config-file config-dev.yaml

次のようなレスポンスが返されるはずです。

Connected to Looker version 23.18.60 using Looker API 4.0

Looker CI/CD のインストールと構成

前提条件

Linux 環境

階層ごとに 1 つの Looker インスタンス

同じ接続名

Git リポジトリ

初回のみのセットアップ手順

Git 認証情報

Git サーバー リポジトリの作成と構成

新しいリポジトリの作成

既存のリポジトリを使用する

GitHub アクションの作成

Look-At-Me-Sideways（LAMS）

Release Please

従来の commit

変更を GitHub に push する

main ブランチの保護

pull リクエストの構成

各 Looker デベロッパー向けのセットアップ手順

Ruby のインストール

Gazer のインストール

Spectacles のインストール

Git のインストール

Git の構成

名前とメール

Git 認証情報

ローカル Git リポジトリの設定

Gazer の構成

Spectacles の構成

Git サーバーリポジトリの作成と構成

`main` ブランチの保護