TerraformのModuleソースとしてTerraform Enterprise's Private Module Registryを利用する
技術推進室とサービス開発部兼務の宇津井です。 前回、前々回から連続してTerraformネタです。
Terraformを利用していると、Moduleの利用は避けて通れないですよね。 そのModuleの管理方法は大きく別けても以下の７つが存在します。
https://www.terraform.io/docs/modules/sources.html
Generic Git, Mercurial repositories
GMOメディアではこれまでLocal file pathsを利用してきました。Terraform RegistryとGitHub共に実質的には全公開状態でしか運用できなかったためです。
最近になって、Terraform Registryに内包される形？でPrivate Module Registryという選択肢ができました。 GitHubに対してはリポジトリへのアクセスキーをTFEに登録できるようになったため、プライベートなリポジトリでもアクセス権をコード上に記載する事なく運用できるようになりました。これは前回の記事で触れています。
今回はPrivate Module Registryの利用方法だったり特徴をまとめてみます。
主にGitHub管理に対するPrivate Module Registryの利点
Private Module Registryと言っても、ソース管理には何らかのVCSを利用することになります。 ここではGitHubでのModule管理に対するPrivate Module Registryの利点をあげてみようと思います。
これに尽きると思います。 Module開発を行っていると、どうしても後方互換性が取れない修正だったり、実行結果に変更が生まれてしまう修正が発生します。 GitHubでのModule管理を利用する方法だと常に最新Moduleを利用せざるを得ません。 GitHubにはバージョン機能あるのに！！と思いますが、ないものはない。 terraformのリポジトリでもissueあがってますが、registry使えと言い切られている状況です。
Private Module Registryにはバージョニングの考え方があるので、もし最新バージョンの修正を受け入れたくない場合は以下のようにバージョンを指定することで利用する側でコントロールができます。
module "vpc" { source = "app.terraform.io/<organization_name>/cf/aws" version = "0.9.3" }
PublicのTerraform Registryを利用しているとよく遭遇しますが、運用をしているとどうしても受け入れたくない変更が発生する場合があります。例えば以下のような状況とか。
一通り試験も終わったので、prodを作成しようとしたらModuleバージョンが1.0.0に変わった
メジャーバージョンが上がっていることもあり、出来上がる構成が変わってしまった。
セキュリティの問題があるわけでもないので、0.9.3でprod環境作りたい
Terraform Enterprise Private Module Registryを利用して入れば、上述のコードのようにversionを指定することで、上記のような状況でも、dev環境と同じものが構築できます。 この時GitHubでのModule管理を利用する方法を採用してると詰んでしまうのです。（古いバージョンのスナップショットをlocalにコピーするという方法はありますが・・・嫌です）
Private Moduleを登録すると自動で https://registry.terraform.io/ のようなサイトが構築されます。
どんなモジュールがあるのか、GitHubのリポジトリを探して回るのも辛い（専用のアカウントがあるとかなら別ですが）ので一覧性もあり検索もできるポータルが利用できるのは意外に嬉しいかもしれません。
綺麗に見せるにはREADMEとかvariableのdiscriptionを頑張って記載する必要があります。この辺りは色々トライしていこうと思います。
主にGitHub管理に対するPrivate Module Registryの欠点
Private Module Registryは１モジュールに対してVCSを１リポジトリ必要とします。 その所以で以下のような欠点があります。
GMOメディアにあるモジュール数は現在26個あります。これらに対して、新たにリポジトリを作成して別々に管理していく必要があります。 新たにモジュールが必要になった時に一々リポジトリ作成していくのはちょっと重厚な感じがしますね。
新しい料金プランを利用している場合はユーザ数課金で、リポジトリ数は無制限なので問題にならないです。
GMOメディアはGitHubの旧プランを利用しています。旧プランはリポジトリ数に応じて月額の料金が変わっていきますので負担が増加します。
Private Registry登録方法(GitHubを利用した場合)
Private Registryを利用するにはBitBucket Serverか、GitHub、GitHub Enterpriseのリポジトリが必要です。 ここではGitHubを利用したPrivate Registry登録方法を記載します。
VCSのリポジトリ名に以下のような命名規則があるので注意が必要です。
terraform-<provider>-<name>
今回はAWS CloudFront用のリポジトリを用意してみましょう。このような名前のリポジトリを作成します。 （GMOメディアではGitHubのリポジトリもTerraformで管理しているので、この名前でPull Requestを送る形になります）
リポジトリの作成が済んだら、TFEとの連携に使用しているGitHubユーザーにAdminのアクセス権をつけておきます。
リポジトリの中身は標準的なモジュール構成に準拠する必要があります。 難しそうに見えますが、最小構成はこんな感じですのであまり障害にならないと思います。
$ tree minimal-module/ . ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf
サブモジュール(./modules/)だったり利用例(./examples/)を盛り込む場合はこんな感じ。
$ tree complete-module/ . ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf ├── ... ├── modules/ │ ├── nestedA/ │ │ ├── README.md │ │ ├── variables.tf │ │ ├── main.tf │ │ ├── outputs.tf │ ├── nestedB/ │ ├── .../ ├── examples/ │ ├── exampleA/ │ │ ├── main.tf │ ├── exampleB/ │ ├── .../
例としては記載しましたが、GMOメディアではサブモジュールを利用していませんし、READMEも結構いい加減です。 Private Registryは身内だけが利用するのでREADMEの書き方、コメントの入れ方、コードフォーマット等、利用者のサジ加減で調節可能です。
Moduleの作成が完了したらGitHubでリリース番号を振りましょう。 https://help.github.com/articles/creating-releases/
今回はv1.0.0を作成しておきます。 なお、この番号の命名にも規則があって、具体的には v1.0.4 か 0.9.3 というタグである必要があります。いわゆるSemantic Versioningってやつです。
Private Module RegistryにModuleを登録
ここまできたらいよいよPrivate Module RegistryにModuleを登録できます。 https://www.terraform.io/docs/enterprise/registry/publish.html
ここでGitHub側にリリースタグがないとエラーになります。
CLI Configuration File(.terraformrc)の用意
認証情報を記載した .terraformrc というファイルを用意します。 中身はこんな感じで、$HOME_DIRに置いてください。
credentials "app.terraform.io" { token = "xxxxxx.atlasv1.zzzzzzzzzzzzz" }
tokenはpersonal API tokenで取得できるものを指定します。
Private Repositroyを利用したコード
冒頭にも書きましたが、こんな感じです。 利用するModuleのProvision Instructions欄にも表示されています。
module "vpc" { source = "app.terraform.io/<organization_name>/cf/aws" version = "1.0.0" }
例としてversionを指定していますが、versionは有っても無くても構いません。 基本的には必要な時だけ記載する方が良いと思います。
やはりリポジトリとか設定ファイルを用意するのとかがちょっと面倒です。 でも、バージョンが使えるメリットは絶大なので、悩みどころですね。
GMOメディアではコード管理上GitHubの利用は必須で、バージョニングの機能を必要としていたので、モジュールの管理方法としてPrivate Module Registryを利用することを決定し、徐々に移行しています。
当社での採用事例がHashiCorpさんのブログにも掲載されていますので、是非そちらもご覧ください。
discoholicmusic
gummygunk
snowghoul
titsay