コーポレートエンジニア(兼いろいろ)をやっている @sion_cojp です。
本当はやり遂げた状態を発表したかったのですが、道のりも長かったため、今やっていこうとしてる内容を記事にしてみました。
この記事を見てタイミーのコーポレートエンジニアに興味を持っていただけたら幸いです。
- TL;DR
- 増え続けるXaaS、ユーザ管理、複雑化
- 残されない手順書
- 我々がやりたいこと
- なぜterraform?
- terraformで管理していくための課題
- 課題を解決してみる
- さらにソフトウェア化できそうなところ
- APIがないXaaS
- 最後に
TL;DR
- XaaSユーザ管理を全てterraformにしていく
- 名前とroleさえ設定してapplyすれば権限付与できる形式にしたい
増え続けるXaaS、ユーザ管理、複雑化
GSuite(SaaS)/ AWSやGCP(IaaS) / CircleCI(PaaS)など便利なツールが増えている時代。
弊社では全てのXaaSを網羅するカオスマップがgithubで管理されており、例えばエンジニア組織が主に使うものはこれだけあります。
オン/オフボーディングの際、社員に権限を手動で追加/削除してる必要がありますが、おそらくこれらのXaaSにログインし手動でポチポチやってる企業が多いかと思います。
「ちゃんと追加した?退職時にremoveしてる?」
追加権限が忙しいマネージャークラスしか無く、追加に時間かかって仕事がスムーズにできなかったり。
removeしてないとセキュリティ的に問題発生します。またユーザ単位課金だと無駄な費用も増えます。
残されない手順書
「ユーザをどう追加/削除したか、またそれはどういう基準か。」
ポチポチは手順や意図が残しづらいです。
どこをどうクリックして...のように全て手順書で管理されてる企業は少ないかと思います。
我々がやりたいこと
XaaSのアカウント作成/削除を、オン/オフボーディングの一環としてコーポレート側で一限管理できると良さそうです。
ユーザ名に対し、role(部署やチーム)単位で紐づけてCRUDできるソフトウェアがあれば解決できます。
それらをどう管理するか...基本terraformで管理して、最悪なにかしらの独自ソフトウェアで解決していく方向で考えてみます。
なぜterraform?
terraform自体は調べてもらうにして、私なりに今回のメリットは3つ。
1. 今ある状態をstateに残せる 2. providerさえあれば、いろんなXaaSを操作できるフレームワーク 3. 脱属人化を図れそう
1について、後ほど説明します。
2, 3について、AWSでterraformが書ける人なら他のprovider...例えばGCP/datadogなども扱えることが多いです。
これはとても大事なことで、世の中にいる優秀なコーポレートエンジニアは極少数で、採用が難しいですし、弊社でも私1人です。
特定の言語で独自ソフトウェアを書くよりは、terraformのフレームワークに落とし込むことで、脱属人化もしやすいです。
最悪なにかしらの独自ソフトウェアで解決しようと思いました。 この文言と矛盾してる理由は、今のところterraformに落とし込むことで問題はなさそうですが、将来どうなるか全く読めない。その場合は作るしかないかなぁと思い、この一文を添えました。
terraformで管理していくための課題
デメリットは2つ。
1. XaaSに対して、providerがない場合がある 2. community providerの場合、開発が滞ってる可能性がある
AWS/GCPなど有名なものはterraform-providerがあり、活発に開発されてます。
弊社では日本のXaaSも利用してるので、それらのterraform-providerを作る必要があります。
またGSuiteは有名なIaaSですが、community providerです。
community providerの場合は、活発に開発されてない事が多いです。
1passwordに至ってはregistry.terraform.ioに上がってないため、terraform 0.13で使うには自身でgithub releaseからproviderをインストールしないといけません。
これらを解決するには、自分たちでOSSでproviderを作成/コミットする課題があります。
課題を解決してみる
下記を試していけそうか実際にチャレンジしてみました。
1. 自分自身でterraform-providerを作ってみる(上述、2,3の課題解決) 2. 一番難しそうなGSuiteのterraform化をしてみる(上述、1の課題解決)
1について、jamfのterraform-providerを書いてみました。
- https://github.com/sioncojp/go-jamf-api
- https://github.com/sioncojp/terraform-provider-jamf
- https://registry.terraform.io/providers/sioncojp/jamf/latest?pollNotifications=true
jamf trial期間中に作成しため、若干バグがありますが、実際にterraform apply->Createができたのは確認しました。
解決は出来ましたが、コーポレートエンジニアが最低限Golangを扱える必要があります。
「Golangは扱えるが、terraform-providerの開発が難しいのでは?」というと、どのproviderも作り方は簡単で同じなので勉強すれば...最悪私が教えれば書けると思います。
(hashicorpがtutorialも出してます Setup and Implement Read | Terraform - HashiCorp Learn)
2について、GSuiteのgroup部分をterraform化することが出来ました。
ただ、documentはあまり整備されておらず、issueも若干たまっており、OSSコミットしていく必要があります。
1,2 を踏まえて、「Golangが書けて、あとはOSS開発/コミットをやっていく気持ちがあれば出来る」というのが所感です。
さらにソフトウェア化できそうなところ
> 1. 今ある状態をstateに残せる
これを利用して、GSuiteのterraform state情報より組織図の自動generateができそうですね。
またterraform-providerを開発した知識を踏まえて、先ほど出てきたjamfやmerakiなどコーポレートで管理してるツールのterraform化も出来て似たような課題を解決できそうです。
APIがないXaaS
APIがないXaaSもあります。そこは手順書で管理するしかないと思います。
最後に
現段階では、gsuite/1passwordはterraform importすれば管理出来る状態です。
jamfに関しては、少しお時間かかりますが引き続き開発していく気持ちですので、ご協力よろしくお願いします。
そしてこれらを1人で成し遂げようとしたら多くの時間が必要です。
この記事見てterraform/Golangを駆使して、コーポレートを自動化することに興味がある方がいらっしゃれば是非一度お話しましょう!