Terraformの基本とディレクトリ構造
こんにちは、シニアソフトエンジニアのリロルです。このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回はですね、インフラエンジニアの必須ツールといっても過言ではない、Terraformについて、どういうふうに使っているのかを語ろうと思います。
私はね、CDKとかクラウドフォメーションとかではなくてですね、完全にTerraform派ですね。
Googleクラウドを触る時もありますし、AWSを触る時もありますし、最近はないけどオンプレ触ることもあるので、いろんなものが扱えるTerraformっていうのを割と愛用しています。
Terraformどんなツールかと言いますとですね、インフラストラクチャーアザコードっていうジャンルがあるんですけども、インフラの構成をですね、手動でやるのではなくて、
コードで書いて、その構造を実行することでインフラを作ろうという試みになっています。
これ何が嬉しいかというとですね、インフラの構造は構造で管理されているので、再作成とか再利用とか、削除とかそういうものが簡単になりますし、
あとはですね、インフラって結構何を変えたかとか全然記録残らないんですけれども、構造で管理することで構造の状態を見ればインフラの状態もわかるという感じになっています。
Terraformなんですけれども、最初にディレクトリレイアウトの話からしましょうか。
大体ですね、EnvironmentっていうディレクトリとModuleっていうディレクトリの2種類を大きく使います。
Moduleというのはですね、実際に例えばAWSで言うとEC2を作りますとか、EKSを作りますとか、ECSを作りますとか、RDBMSを作りますとか、
そういうある程度の単位で同じ作業を繰り返すことがあるんですけれども、その作業を一つに固めたものをモジュールって言います。
単純にEC2を立てるっていうだけのモジュールを作ってもいいですし、VPCとEC2とインターネットゲートウェイとナットゲートウェイと、
あとなんかサブネットを4つぐらい作るみたいな構成でモジュール作ってもいいんで、そこの自由度は結構ありますね。
簡単に言うと使い回せるユーティリティの関数を作るような感じでしょうか。そのことをモジュールって言ってますね。
Environmentsっていうのは何かというと、その環境ごとにどういうものを作るかっていうのを定義する場所ですね。
Environmentsの下にですね、DevとかStagingとかProductionみたいなディレクトリを作って、
さらにそれぞれのディレクトリの下で実際にどういうインフラを作るのかっていうのを書いていますね。
そこから先ほど定義したモジュールを適宜呼び出すという感じでしょうか。
なので例えばAWSの場合だと、AWSのアカウントを環境ごとに分けるケースが多いかなと思うので、
EnvironmentsのDevの下にはDevのAWSアカウントに対して、IAMとかEC2とかVPCとかそういうものを作るようなコードを書いていきます。
あとはですね、Environmentsの中にもしかしたらコモンみたいなディレクトリを掘りまして、
環境共通で定義するようなものとか使うこともあったりしますね。
まあそうだな、例えばECRとかRoot53とかACMとか、なんか共通的に使うものとかは結構そういうところで管理したりしますね。
これがざっくりTeleformのディレクトリレイアウトです。
CI/CDと変更管理
ワークスペースとかは使ったことないですね。
Teleformにワークスペースっていう機能があって、環境ごとに切り替えられるみたいなものがあるんですけど、
別にそれごとにあんまりこう分けるよりもディレクトリで分けた方が楽というか、結構推奨されることが多いかなと思うので、それでやっています。
で、Stateっていうものがありまして、実際にインフラがどういうふうに構築されているのかっていうのをTeleformが解釈するための設定ファイル、設定ファイルというかは状態管理なんですけども、
こちらに関してはですね、ちょっと分け方はいろいろパターンがあるんですけども、
環境ごとに分けるパターンだったり、全環境で一つにするパターンだったり、
例えばエンバイロメンツの出文の中にもさらにEC2用とかAWSのRDS用みたいな感じでディレクトリを掘って、
その中に対して一個ずつのステートファイルを用意するみたいな形式もいろいろあります。
このステートファイルにですね、いろんなインフラを構築する行動を入れていくとですね、
どんどんどんどんステートファイルが肥大化していって動作が重くなるっていうデメリットがあるので、
割とステートファイルはうまく分割していくっていうのがより良い選択肢なのかなと個人的には思っています。
はい、要するにざっぷりTeleformのディレクトリレイアウトの話をしました。
続いてですね、Teleformのコードを書きました。その後どうするかっていうんですけども、
それでGitHubとかのケースを考えるとですね、プルリクベースで変更コードに対して行っていくんですけれども、
プルリクを作った際にはですね、まずCIということでTeleformのプランというものを実行するCIを用意します。
これは何かというとですね、実際に自分が修正したコードを実際のAWSのアカウントに対して接続して作った場合、
こういう風なものができるよ、もしくは壊されるよ、みたいなことが差分として出てくるような機能になっています。
この時点でですね、何かおかしいフォーマットとかおかしい書き方をする場合はエラーで落ちるので、
そこでTeleformプランっていうものを叩くことで、問題がないかどうかとか、どういう変更が入るんだっけみたいなことがわかる感じですね。
で、問題がなくてプルリクが回しされたらTeleform ApplyっていうCDのジョブが動きまして、
実際に環境が変更されていくという感じになっています。
なのでこれで基本的にはTeleformの一連の流れが皆さんわかったかなという感じですね。
基本的にTeleformを使ってインフラ構築する際にはですね、最初の時はもしかしたらTeleformをローカルで動かすっていうのがやることになるんですけども、
だいたい出来上がってきたらですね、CICDのパイプライン上に載せた方が都合がいいので、
Gitのプルリクベースでやるっていう感じでしょうか。
プロバイダーの概念とその利便性
あとあるかな、Teleformもあり。
あ、プロバイダーの概念を説明しなかったですね。
TeleformってOSSで存在していて、ハシコープっていう会社が作ってくださっているんですけれども、
Teleformの本体に他にプロバイダーという概念があります。
これは何かというと、便利なライブラリといったような感じでしょうか。
例えばAWSのプロバイダーとか、Googleクラウドのプロバイダーとかがあるんですけども、それが何をしているかというと、
AWSの例えばEC2とかRDSを作ったり変更するAPIというものがAWSから提供されているんですけども、
それをですね、うまくラップしてTeleformの行動からその代わりにAWSのAPIを呼んでくれるみたいな機能を持っているやつですね。
なので、Teleformを使って、例えばそのプロバイダーを切り替えることで、
一つのTeleformからAWSも触れるし、Googleクラウドも触れるっていう感じになっています。
またですね、プロバイダーっていうのは自分で作ることもできるので、
例えば、あんまりまだ認知度が高くないSaaSがあったとして、そこのAPIが公開されていますと。
本来であれば、APIを直接叩いて何とかしないといけないんだけれども、
Teleformでインフラとかは管理しているので、そのSaaSのですね、プロバイダーを自分で作ってあげることで、
そのSaaSをTeleform経由で管理することもできるんですね。
メジャーなプロバイダーも誰かが作ってくれたりとか、公式が作ってくれたりしているので、
あんまり作るケースってのは多くないんですけれども、あると便利ですよね。
で、なんか管理できる幅本当に広くて、
例えばGitHubのオーガニゼーションの中に誰がどういう権限を持つかみたいなメンバーの管理もできますし、
デポジトリの作成とかもできるはずですね。
なんで本当に管理したいものっていうのは多分いっぱいあると思うので、
それがTeleform一つに入れられると便利ですし、それを便利にしたのがプロバイダーという感じでしょうか。
その代わりですね、なんかこう失敗者とか意図しない差分が出た場合は、
Teleformが悪いのか、プロバイダーが悪いのか、
もしくはただいさきのAPIをホスティングしているIWSとかGoogleクラウドみたいなところが悪いのかっていうのが一見するとわからなかったりするので、
そういうところの切り分けみたいなのは一定、その手で作ったときには発生しない問題があるかもしれませんね。
手で作っているときはね、得られたらもうそこのサイトの問題なんで絶対そこってわかるけど、
Teleformだとわかんないですよね、まずどこか。
エラーよく見ればわかるんですけど、ちょっと一見するとわかりづらいという感じでしょうか。
今回はインフラエンジニアがよく使うツールですね、Teleformについて、
ディレクトリレイアウトからCACD、あとはプロバイダーっていうものだったりとか、その他注意事項みたいなことをお伝えしました。
本当に必須のツールなんですけども、ちょっと文法の特殊ってのがあるんですけども、
すごいシンプルに作れますし、今はねAIでバンバン作れると思いますので、
ぜひですね、ちょっとインフラを構築するとか、インフラじゃなくてもなんかちょっとしたねサーバー立ち上げるとか、
ホスティングするためにS3使うとか、そういうぐらいのタイミングでもですね、使ってみるといいんじゃないかなと思います。
はい、このポッドキャストはハッシュタグユライティで皆様からの感謝コメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。
ありがとうございました。
