このページでは、Looker で CI/CD ワークフローを実装するために必要なコンポーネントをインストールして構成する方法について説明します。
この手順では、開発、QA、本番からなる 3 層システムを使用します。ただ、同じ原則は 2 層および 4 層のシステムにも適用できます。
またこの手順では、Git プロバイダとして GitHub を使用することを前提としています。他の Git プロバイダを使用して CI/CD ワークフローを作成できますが、プロバイダに合わせてこれらの手順を変更する場合は、専門知識が必要です。
関連するセクションの手順に沿って操作します。
前提条件
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 に戻ります。
- [設定]、[アクション - 全般] の順に選択します。
- [ワークフローの権限] で、[GitHub Actions による pull リクエストの作成と承認を許可する] がオンになっていることを確認し、[保存] をクリックします。
- GitHub 設定の [Deploy keys] ページに切り替えます。
- [Add deploy key] ボタンをクリックして、デプロイキーを [Key] フィールドに貼り付けます。
Looker-REPOSITORY_NAMEなどのタイトルを追加し、[書き込みアクセスを許可] チェックボックスをオンにして、[キーを追加] ボタンを押します。- Looker に戻り、[設定のテストとファイナライズ] を選択します。
- 左側のバーから [プロジェクトの設定] をもう一度選択します。[Git 本番環境のブランチ名] を
mainに変更します。 - [高度なデプロイモードの有効化] を選択し、[プロジェクト構成の保存] を選択します。
左側のプロジェクト設定アイコンの下に、Deployment Manager のデプロイ アイコンが表示されます。
既存のリポジトリを使用する
- LookML が保存されている GitHub リポジトリに移動します。
- [設定]、[アクション - 全般] の順に選択します。
- [ワークフローの権限] で、[GitHub Actions による pull リクエストの作成と承認を許可する] がオンになっていることを確認し、[保存] をクリックします。
- GitHub リポジトリの [<> Code] セクションに移動します。
- [<> コード] というラベルの付いた緑色のボタンを押して、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@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 0
- 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
従来の 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 }}
permissions:
pull-requests:
read statuses: write
変更を 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] ボタンを押します。
[Branch name pattern] として「main」と入力し、次のオプションをオンにします。
- マージ前に pull リクエストを必須にする
- 承認を必須にする
- 新しい commit が push されたときに古い pull リクエストの承認を閉じる
最後に、ページ下部にある [作成] ボタンをクリックします。
pull リクエストが作成されると、前の手順で構成した GitHub アクションが実行されます。初めて実行した後にこの UI で選択することで、pull リクエストを main にマージできるようになる前に成功する必要があるようにすることもできます。
pull リクエストの構成
Looker では、pull リクエストの使用を必須にして、デベロッパーの代わりに Looker を PR を開くようにすることができます。これは開発インスタンスに対してのみ構成する必要があります。QA インスタンスと本番環境インスタンスは、高度なデプロイモードを使用して更新を取得します。
これを有効にするには、各プロジェクトの [プロジェクト設定] ページに移動し、[GitHub Integration] という見出しの下の [Pull Requests Required] を選択します。
ボタンを押して 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] を選択します。
[pull リクエスト] と [push] が選択されていることを確認します。
最後に、ページ下部にある [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 のテストに使用されるオープンソース ツールです(有料版は現在提供されていません)。インストールの詳細については、スタートガイドをご覧ください。
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 になります。
リポジトリのディレクトリに移動したら、次のコマンドを使用できます。
| コマンド | 目的 |
|---|---|
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