dbt Projects on Snowflakeで開発者を増やすときの流れを確かめてみた
さがらです。
dbt Projects on Snowflakeで開発者を増やすときの流れを確かめてみたので、その内容について本記事でまとめてみます。
事前準備
以下のブログに沿って、あるユーザーがdbt Projects on Snowflakeのセットアップを終えた状態と仮定して、本記事の内容を行っていきます。GitHubへの認証はOAuth2を使用します。
やってみた
GitHubのユーザー招待＆リポジトリへの招待
まず前置きとして、GitHubのユーザー招待と対象のリポジトリへの招待を行っておきます。
※以下は参考になりそうなGitHubの公式ドキュメントを貼っておきます。
Snowflakeのユーザー招待＆ロールの付与
対象者がSnowflakeのユーザーでない場合は招待し、ロールも付与します。
※以下はユーザー作成とロール付与に関するとても簡素なサンプルクエリです。
USE ROLE SECURITYADMIN;
CREATE USER <招待するユーザー名>
PASSWORD = '<任意のPW>'
EMAIL = '<ユーザーのメールアドレス>'
MUST_CHANGE_PASSWORD = TRUE;
GRANT ROLE <dbtの開発用ロール> TO USER <招待するユーザー名>;
ちなみに、メールアドレスを設定してverificationをしておかないと、Workspaceでブランチ作成時に下図のようにエラーが起きます！
対象のユーザーでログインし、Workspaceをセットアップ
先程作成したユーザーでログインします。
メールアドレスのverificationがまだの場合は、SettingsからResend verificationを押して、verificationを行います。
ロールを付与した開発用ロールに切り替え、Workspaceを起動します。
左上のWorkspace名をクリックし、From Git repositoryを押します。
下図のようにRepository URLとWorkspace nameを入力し、API integrationは開発用ロールに付与されたExternal Access Integrationを設定した上で、認証方法はOAuth2を選択します。
この上で、Sign inを押します。
表示される画面に沿って、認証を進めます。
無事に認証がされると、下図のようにSigned inと表示されます。この状態でCreateを押します。
すると、入力したリポジトリの内容がクローンされ、Workspace内でdbtの開発ができるようになりました！
実際の開発手順については、以下のブログの「dbtの開発」章が参考になると思います。
おまけ：開発者用ロールだけ付与していた場合、Workspaceから本番環境のtargetを指定したdbtコマンド実行はできるのか？
もう一つおまけなのですが、開発者ユーザーには開発者用のスキーマだけ権限のあるロールを付与していた場合、Workspaceから本番環境のtargetを指定したdbtコマンド実行はできるのか、確かめてみました。
まず参考までに、profiles.ymlは下図のようになっており、開発者ユーザーにはDBT_PROD_ROLEは付与していません。
この状態で、Workspaceからtargetをprodに設定し、何かしらのdbtコマンドを実行しようとすると、コマンドを選ぶところからできなくなっていました。
profiles.ymlの本番用のウェアハウスの権限を付与していなかったため、こうなったようです。
そのため、profiles.ymlのwarehouseを開発用ウェアハウスに変更してdbtコマンドを実行しようと試みると、コマンドを選択して実行できました。
しかし、profiles.ymlで指定している本番用ロールに権限がないため、下図のようにエラーとなりました。ちゃんと開発と本番でロールを分けていれば、開発者用ロールから本番環境に対してデータの更新をさせないことが確認できました！
最後に
dbt Projects on Snowflakeで開発者を増やすときの流れを確かめてみました。
基本的には権限を分けてロールを管理していれば、ユーザーに対して使用するロールを付与するだけでセットアップ可能です！
