tr;dr
- Terraformにはユーザーが作ったmoduleを共有するTerraform Module Registryという仕組みがある
- 自前でmoduleを管理するよりもいろんな人が管理しているので便利
- terraform使ってる人はterraform使ってるので、contributeできる!
- 実際に行ったのは去年の年末なので、少し前ですが実際にContributeした際のこと書きます。
Terraform Registry
- https://registry.terraform.io/
- Terraformが公式で出している他の人が作っているTerraform moduleを公開・共有できる仕組み(これ書いて気づいたんですが、いつの間にか名前が
Terraform Module RegistryからTerraform Registryにいつの間に名前が変わっている？)
公開されているmodules(一例)
-
Terraformを扱うときに一つだけのresourceを扱うことは少ないと思います。
- 例えばVPCを扱うときにVPC,subnet,route table,internet gateway,security group,vpc endpoint etc...
-
そのときにTerraform Registryで公開されているmoduleを利用して、欲しいresourceがまとまっているmoduleを利用すると非常に便利！
欲しいmoduleを探す
- 欲しいmoduleを探すのは簡単で検索欄にkeywordを入力すると、登録されているmoduleの一覧を見ることが出来ます。
- Verifiedにチェックを入れると、HashiCorpの人がreviewやmaintenanceをしている認定されたものだけが表示されます。
terraform-eks-module
- https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/
- Terraformでeksのclusterを建てることができるmoduleの一つです。EKSはkubernetesのcontrol planeをmanagedで建ててくれるもので実際にclusterとして利用する場合は、EC2を別途建てたり(これ書いている中でFargate for EKSもされましたが)、security groupやIAM Roleの作成などが必要になります。これらのresourceをまとめてくれるものです。
Source
- Registoryがどこで管理されているかは、ページのsourceの部分にlinkがあります。今回の場合はhttps://github.com/terraform-aws-modules/terraform-aws-eksです。
Issue
- 私が実際に出したPRは（https://github.com/terraform-aws-modules/terraform-aws-eks/pull/228) でmoduleにoutputにkubeconfigファイルを書き出さないようにするというオプションを追加したものなのですが、PRを出す前にIssueを確認しました。その結果、修正を出そうとしていた内容のIssueが２つあったので、PRには添付しています。(htts://github.com/terraform-aws-modules/terraform-aws-eks/issues/169,htts://github.com/terraform-aws-modules/terraform-aws-eks/issues/170)
- 自分が欲しい機能以外にもまずはIssueを眺めて、自分でも修正できそうなやつを見つけてContributeするのも良いかもしれません。
修正
- repositoryをforkしてコードを修正します。ここらへんは普通のGithubの利用と同じなので割愛。
- 参照するmoduleを変更する方法はいくつかあると思うのですが、私の場合はinitした後のeks moduleを呼んでいる箇所をシンボリックリンクにして、forkしたrepositoryを向くようにして変更していました。
terraform-docs
- Terraform RegistryはGithubのREADME.mdの部分がRegistryの部分の説明文になります。
- 全てのmoduleがそうというわけではありませんが、多くのmoduleでterraform-docsを使って、inputとoutputの表を作成していることが多いので、terraform-docs(https://github.com/segmentio/terraform-docs)を使って、output,inputが増えた場合は更新します。
- 多くのprojectはpre-commit（https://pre-commit.com/）を使って、terraform-docsやlint,fmtの設定がされていることがあるので、その場合はpre-commit frameworkを導入してあげると更新忘れが少ないので便利です。(逆にいえば入ってなかったらPRチャンス！)
- terraform-docsの細かい使い方は別記事(https://qiita.com/yutachaos/items/1a7f5a93ceaf972c76c6) に書きました。
PR
- 修正ができたらPRを出します。
- terraform-eks-moduleの場合はテンプレートがあったのでテンプレートに合わせて埋めていきました。
# PR o'clock
## Description
Please explain the changes you made here and link to any relevant issues.
### Checklist
- [ ] Change added to CHANGELOG.md. All changes must be added and breaking changes and highlighted
- [ ] CI tests are passing
- [ ] README.md has been updated after any changes to variables and outputs. See https://github.com/terraform-aws-modules/terraform-aws-eks/#doc-generation
- Description
- コードの修正内容や意図を書きます。すでにIssueなどを立てている場合はここに入れるのもありです。
- Checklist
- registoryにあったりなかったりだと思いますが、今回の場合はCHANGELOG.mdに変更点を記載、CIが通ったか、前述のterraform-docsでREADME.mdを更新したかがchecklistのようです。
Merge
- PRに出すとCommentなどがされることがあると思うので対応していきます。対応が全て終わったらmergeされます。
release
- 通常のOSSと同じようにmasterにmergeされた分はいくつかの単位にまとめられてreleaseがされます。relesaseされたmoduleはterraform moduleのversionで指定して使うことができるようになります！
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "6.0.2"
# insert the 4 required variables here
}
おわりに
- 複数のresourceをmodule機能を使って、自前でまとめてあげることがよくあると思いますが、最初は良かったけど、段々、追加したい機能やversionが上がったときの差分の考慮など、自前でmoduleを管理すると大変になっていきます。そのようなときにTerraform Registoryで自分が実現したい機能がある場合は非常に便利です。erraform自体も非常に変化が早いOSSなので、自分たちで追随していくよりも多くの人が扱っているmoduleを使った方がメンテナンスコストを避けられる面もあります。何よりTerraform Providerを書くにはGolangの知識が必要になりますが、Terraform moduleが必要になる人は基本的にTerraformのresourceを扱っているので、これらのOSSよりも参加する敷居が(個人的には)低いかなーと思いますので、ぜひ皆でterraformをよくしていきましょう！