Lookerの開発環境について調査してみた（概要編）
目次
1．はじめに
2．Lookerの開発環境とは
3．開発インスタンス→本番インスタンスへのダッシュボードの移行方法
4．さいごに
1．はじめに
※本記事はNI+C TeamGCP Advent Calendar 2023 19日目の記事となります。
こんにちは、鈴木です。
今回は、Lookerにおける開発環境ってどんな考え方があるのか？開発環境から本番環境にダッシュボードを移行するって
どんな方法があるのか？についてご紹介します。
Lookerを利用しようとしているけど開発環境を用意すべきか悩んでいる方や、すでにLookerを利用中で開発環境を用意したい
という皆様の参考に少しでもなれば幸いです！
2．Lookerの開発環境とは
Lookerの開発環境には下記3つの考え方があります。
- 1インスタンス内で開発モードを利用する
各個人の開発ブランチで本番環境に影響を及ぼさずに開発することが可能 - 1インスタンス内でconnection（DBへの接続）を本番・開発用に作成し、Lookerのプロジェクトを分ける
接続先やプロジェクトを分けることで本番環境に影響を及ぼさずに開発することが可能 - 2インスタンス用意し、本番・開発用のインスタンスを分ける
完全に環境を分離し、開発することが可能
Lookerを利用される場合は通常、上記①、②のように1インスタンスのみで利用される方が多いと思いますが、
本番モードでは確認ができなかったりバージョンアップの事前確認ができなかったりと本番運用していく上では
懸念事項が発生する場合があります。
③のように複数インスタンス（開発/ステージング/本番など）用意する場合は、以下のような目的でインスタンスを分けます。
- Lookerのバージョンアップの際、エンドユーザーが使う本番インスタンスに新バージョンが適用される前に、新バージョンでも問題なく既存のコンテンツが動くかどうかを別のインスタンス（開発）で検証したい（ESRリリースサイクルとの併用）
※「ESRリリースサイクル」については今後別ブログにてご紹介いたします。簡単に説明しますと通常大体毎月行われるバージョンアップを年4回のサイクルに変更することが可能です - 何かしらダッシュボードに変更を加える際に、エンドユーザーに影響を与えたくない （ユーザー定義ダッシュボード（以下UDDダッシュボード）はバージョン管理ができず、変更の際はエンドユーザーが触っているものを直に変更するしかないため）
いずれも「本番インスタンスのコンテンツを触っているエンドユーザーに影響を与えるリスクを減らしたい」というのが
主目的となり、特に外部提供されているお客様やEnterprise企業でユーザーに対するリリース管理が厳密なお客様などが対象に
なるかと思います。
3．開発→本番インスタンスへのダッシュボードの移行方法
前述の③に記載した、2インスタンス用意し、本番・開発用のインスタンスを分けた場合には開発→本番へ開発内容を
移行する必要があります。
Looker公式ドキュメントにて「ダッシュボードを別の Looker インスタンスに移動する」について案内されているので、
まずはこちらを参考にされるのがいいと思います。
ただ、上記の方法以外にも移行方法はいくつかあるのですが、前提としてLookMLで管理できるものとそれ以外のものを
別に考える必要があります。
- LookerMLで管理できるもの：LookML Projectに含まれるModels、Views、LookML Dashboards（これはProjectに紐づいたGitで連携される）
- それ以外：コンテンツ（Looks、UDDダッシュボード）やconnectionなど
LookMLで管理できるものについては、Gitが連携されているのでリポジトリ経由で移行が可能です。
それ以外のコンテンツ（Looks、UDDダッシュボード）はGitで移行することができないので、
LookMLダッシュボードに変換してGit経由、もしくはAPIなどを用いて移行することが可能です。
ダッシュボードを移行する方法については以下の通りです。
| 移行方法 | 移行対象 | 概要 | 備考 |
|---|---|---|---|
| Git経由 | LookerMLで管理できるもの（LookML Projectに含まれるModels、Views、LookML Dashboards） | 開発インスタンスで作成したUDDダッシュボードをLookMLダッシュボード化し、本番インスタンスにはLookMLダッシュボードとしてデプロイする | Looker公式ドキュメントで案内している方法 |
| Gazer | LookMLで管理できないコンテンツ（Looks、UDDダッシュボード）等 | ・OSSとして提供されており、LookerAPIがパッキングされたもの ・シンプルなコマンド ライン ツール ・UDDダッシュボードを移行できる ・コンテンツの移行としては最も実績があり一般的に利用されている | |
| Looker Deployer | Gazerと基本的に同様（Gazerと比較すると移行対象のサポートが幅広い（Group/RoleやBoards/Folders、コード等）） | ・Gazerと同様、OSSとして提供されている ・PythonとGazerを元に動くため、Gazerのインストール必要 | Gazerと比較するとフォルダ単位での移行が可能なので便利 |
Looker公式が紹介しているように、
コンテンツをLookML化可能なのであればGit経由で移行するのが一番スマートな方法ですし、
LookMLダッシュボードはGUIで編集が不可なので本番環境では触らせないという点でも一番最適な方法だと思います！
ただ、上記どの方法で移行するかは、移行対象の内容や移行対象の数によって選択が必要になります。
例えば、移行するコンテンツの数が多い場合はすべてLookMLダッシュボードに変換する手間もあるので、
その場合はGazerやLooker Deployerを用いることで移行することが可能です。
また、そもそもダッシュボードをLookMLダッシュボードで管理されていたり、ダッシュボード数も少ないので
あればLookMLダッシュボードに変換してGit経由で移行することが可能です。
GazerとLooker Deployerに関してはコンテンツを移行する目的となるので、開発環境と本番環境で同一のコンテンツを
参照するためには同じLookMLやconnectionなどの環境の用意が前提となりますのでご注意ください。
GazerとLooker Deployerのインストールや移行に関しても複雑なので、実際に試してみた手順などはまた別のブログで
ご紹介いたします。
4．さいごに
今回は開発環境や複数インスタンスでの移行方法の概要についてご紹介しましたが、いかがでしたでしょうか？
開発環境と本番環境の複数インスタンスを用意する前提での移行方法について記載しておりますが、
もちろん同一インスタンス内でも適用できる内容になっております。
ドキュメントなどを調べてみてもあまりLookerの複数インスタンスについての情報がなかったり複雑なので、
少しでも皆様のお力になれれば幸いです！
また別のブログで、実際に移行した手順や各移行方法の詳細についてご紹介していきたいと思いますので乞うご期待ください！
