情シスのお仕事をやっているとGoogleWorkspaceのグループ管理、MLへの追加申請を受理して追加、みたいな時間を過ごすことはありませんか。ないですか。僕はあります。
申請なり依頼なりを受けてポチッとやれば済む話なので1個1個の負荷は大したことがないものの、グループというものの管理には色々頭を抱える問題がありますよね。
- 社外のユーザを追加して、そのユーザが案件から外れてもずっとグループに残り続けている
- MLにこの人達を追加してください、と大量のユーザが列挙されてポチポチ業で消える無の時間が発生する
- 情シスしか作業できない設定にしてると休むと作業が止まる！！属人性しんどい
これらの課題を直接的に100％解決できるものではないですが、解決するための道具として使うことはできそうなものを作りました。
j-o-lantern0422/josef: manage Google Workspace’s Google Group with yaml.
Josefとは
掲題の通りのツールで、GoogleWorkspaceのグループをyamlで管理できます。管理するのに必要な機能は一通り実装したつもり。
dumpする機能
josefはyamlで定義されたドメインの一覧を受け取り、そのドメインを持つGoogleWorkspace上のグループの一覧を出力する機能を持っています。
こんなのを定義して、
とすると
のようなYAMLを出力してくれます。
applyする機能
先に出力したyamlをベースに該当のグループのmembersを追加したり減らしたりすると、実際のグループからも人を減らしたり追加したり出来ます。便利ですね。
あと、新しくgroupを作成することも出来ますし、yaml上から消えたグループについては削除されます。yamlを真の情報として扱うことが出来るので、手動のオペレーションで変更されたものをyamlの状態に戻すことが出来ます。ちなみに、先のドメインを定義するyamlで定義していないドメインのグループに関しては管理対象外になるので、josefで管理しないものを作ることも可能です。コミュニティとしてのグループは申請とかいらないです、という場合は便利かな。
コマンドは単純で
とすると実行できます。
実環境とyamlの間の差分を見る
要するにdry runができます。将来的には josef apply group_and_members.yml --dry-run でも実行できるようにするつもりですが、今は下記のようなコマンドで実行可能です。
まあぶっちゃけどっちでもいいですね。この機能は編集後に実際にどういう変更が行われるのかを見ることが出来る機能です。
こんな感じで表示されます。当然何も差分がなければ何も表示しません。
使うために必要なもの
大したものは必要ないんですが特権管理者のアカウントが必要です。
- ruby
- 3.0.0で開発したので3.0.0なら動く
- GoogleWorkspaceの特権管理者アカウント
- GoogleWorkspaceのAPIを叩くための認証情報
- サービスアカウントのみに対応している
- AdminSDKを有効にすること
- 必要なスコープ
- なおドメイン委任管理の機能は無効でいいです
GoogleWorkspaceの設定次第では特権管理者アカウントは必要ないのかもしれないですが、僕の私物GoogleWorkspaceで確認した限りは必要そうでした。環境変数に設定するか実行時にプライマリメールアドレスを求められるので入力してください。
作った動機
申請をPull Requestで受け付けたい
勤め先ではGoogleWorkspace上のグループが承認の必要なものについてはワークフローを通して情シス部門に届き、それを作業者が受け取ったらポチポチ作業するようになっています。とても簡単な作業なので、むしろその申請を確認したり、申請が来ていないか気にすることにリソースが使われます。生産的な仕事にリソースを割きたいし割いて欲しいと思っているので、この作業を簡略化したいという思いを持っていました。
Pull Requestで申請を受けられると、CIを回したり、Pull Requestがマージされたら適用、なども自動化出来ます。マージした人のメールアドレスを取得できる仕組みがCIにあるなら、先の特権管理者の人のメールアドレスであるときだけ適用などもできそうですね。
社外のユーザが入っているグループの棚卸しがしたい
社外のユーザをグループに入れている場合、そのグループの管理責任をおっている人がそのユーザについても管理しています。例えば準委任契約でお仕事を手伝ってもらう人のメールアドレスを追加したとしたら、その契約が終わったらグループから削除する依頼が来ます。
この手の運用には定期的な棚卸しがつきものですが、棚卸しって大変ですよね。yamlで管理できていると git grep で行単位の検索から、一般的なプログラミング言語ではyamlを扱う手段は普通にあるので素のGoogleWorkspaceよりは扱いやすいだろうと思います。
チームの問題解決意識が向上していた
所属しているチームの問題解決意識が向上していると感じていました。誰かが解決してくれるのを待ってそれを使う、よりも自分が解決に導く、という意識を感じていたので、この手のツールを作るにしても使うにしてもうまくやれそう、と思ったので安心して作れました。いい話ですね。僕も僕で質の低いものに甘んじるわけにはいかないなと背筋が伸びる気持ちです。
カッとなった
問題解決力が上がったのを喜びつつも色々感じるところがある日常を送っていて、なんか夕飯食ってるときにカッとなって4時間ぐらいで作りました。そのうち2時間ぐらいはGoogleのAPIコンソールとドキュメントとAPIラッパーのソース眺めてました。いつものことですけどGoogleWorkspaceのAPI難しくないですか？rubyのラッパーが難しいのかな…。慣れると普通のREST APIなので作り始めると早いんですけどね。
今後
- カッとなってオラァんって作ったのでテストがない。書くぞ！
- 分割したyamlをサポートしたい
- 試しに勤め先でdumpしたらとんでもないサイズのyamlができ、流石にこれは…となった。
- yamlも行数多くなると大変さが増すので分割されたyamlを取り扱う手段が欲しい。josefに実装しなくても、そういう手札を持ちたいですねえ
- チュートリアルを充実させる
- GoogleWorkspaceのAPIなんかむずくない？問題。サービスアカウントの認証情報入ったjson取得毎回迷子になる…
- グループのメールアドレス変更に対する妙案
- ID保持すれば出来るけど、人間が見ても意味不明なものがyamlに入っているというのも…
- 新規作成とうまく共存するにはどうするのがいいのか
- メールアドレス変えるか？ドメインはともかく…みたいな気持ちはある
作ってみて思ったのは、過去にOneLoginのRoleとUserの紐付けをyamlでやるj-o-lantern0422/hotify: Onelogin role manage with yaml を作ったときと比べて格段に早く作れたことと、だいぶコードがシンプルになったなってことです。josefも完璧なコードが書けているってことはないですけど（テストないし）。それだけレベルが上ってるなら喜ばしいことです。
あと、読み方は「ヨーゼフ」です。アルプスの少女ハイジに出てくるあの犬がモデルです。決して波紋使いの名前ではない。勤め先の流行りで犬か和風な名前をつけがちなのですが、グループをなんか管理するのって、牧羊犬ぽくないですか？アルプスの少女ハイジほとんど見たことないのでヨーゼフが牧羊犬かは知らないのですが…。