はじめまして。
2020年新卒として、ecbeingのプロダクト開発統括部に所属している太田と申します！
普段は、スクラムやモブプロなどアジャイルな開発手法に触れながら、新たなSaaSサービスの開発に携わっております。
さて今回の記事は、私が配属されて初めて任された仕事であるTerraformを使ったインフラ構築についてです。
現在もチームで開発を進めていく上で私は、Terraformを使って迅速に新たな開発環境を提供するという、開発サポート的な役割も担当しています。
そんな私がこの記事を書く約半年前、Terraformと果たした運命的な出会いについて紹介していきたいと思います。
- そもそもTerraformとは？
- はじめてのおしごと
- Terraformの構造
- ドキュメントとの戦い
- Terraformの実行方法
- いざ、動作確認
- Terraformはやべーやつ
- はじめてのおしごと を終えて
- 現在
- まとめ
そもそもTerraformとは？
Terraformを一言で表すと、クラウド上のインフラ構築を自動化するツールです。
クラウドサービスについて
１つのアプリケーションを作るためには、サーバーやネットワークなど、構築すべきものが多数あります。
かつて、これらのリソースはオンプレミスで構築しており、
初期構築や保守管理などの時間がとてもかかっていました。
ところが近年ではAWSやAzureなどのクラウドサービスが登場し、このインフラ構築はとても手軽になりました。
必要なサーバーやネットワークは、クラウドサービスのサイト上で必要な情報を入れて、マウスをポチポチすればものの数分で構築することができます。
クラウドサービスの課題
しかし、クラウドサービスで環境を構築・管理するにも問題は出てきます。
１つのアプリケーションといえど、必要なリソースは何十個、場合によってはそれ以上の数になる場合もあります。それらのリソースを開発用・デモ用・本番用で毎回構築するのは大変面倒ですし、人力で行うとミスも発生します。同じ設定を何回も繰り返し入力するだけの単純作業になる場合もあり、進んでやりたいと言う人は居ないでしょう。
そこで、これらの問題を解決できるIaC（Infrastructure as Code）のツールとして注目されているのがTerraformです。
Terraformを使うと、ソースコード上でインフラの構成を宣言し、インフラの構築を行うことできます。
△部内でTerraformに関するプレゼンを行った際のスライドです。
はじめてのおしごと
私が初期研修を終え、配属されて初めて与えられた仕事は次の内容でした。
Terraformのソースコード中で、ハードコーティングしている部分を設定ファイルに外出しする。
背景
そのときアサインされたプロジェクトでは、Azureの開発環境を手動で構築していました。上司がその環境をTerraformのソースコードに落とし込んでいたのですが、あらゆる値がハードコーディングになってしまっていたため、その部分を別の設定ファイルに移してしてほしい。といった内容でした。
最初にこれを説明されたとき、私はTerraformはおろかクラウドサービスについての知識すらままならない状態でしたが、
「設定ファイル化するだけの作業だし、そんなに難しくなさそう」と楽観視していました。この後、沼にハマることも知らずに…。
Terraformの構造
Terraformはmain.tfと、変数を格納するvariables.tfという2つのファイルで構成されています。
開発用・デモ用などと必要なリソースは同じだが、微妙に名前や設定を変更したいという場合に、variables.tfに環境ごとで異なる内容を定義しておきます。（例：各リソースにつけるdev,demo,prodといった名前・IP制限など
つまり具体的な仕事内容としては、このmain.tfにハードコーディングしている値をvariables.tfに設定ファイル化するという内容でした。
ソースコード
▼main.tf(ハードコーディングされている状態)
resource "azurerm_sql_server" "webapp" {
name = "ecbeing-sqlsvr"
version = 12.0
}
▼main.tf(ハードコーディング部分を設定ファイルへ移動した状態)
resource "azurerm_sql_server" "webapp" {
name = "${var.name}-sqlsvr"
version = var.sql_server_version
}
$var.~と書かれている部分は、
▼variables.tfへ記述することで、設定ファイル化しています。
variable "name" {
default = "ecbeing"
}
variable "sql_server_version" {
default = "12.0"
}
<br>
ドキュメントとの戦い
設定ファイル化するだけとはいえ、その値が何者かを理解しておく必要はあります。
また、変数の説明がないと、せっかく設定ファイル化しても何の設定値なのか分かりません。
当然、それらの設定値の意味を調べながら作業を行いました。しかし、Azure環境用のTerraformのドキュメントは英語しかありませんでした。
今の時代、Google翻訳にかければ英語は読めなくもないのですが、技術系特有の英単語は単純に翻訳ソフトにかけても無駄です。英語自体は苦手では無かったので、時折出てくる技術系の英単語に苦戦しながら、淡々と作業を進めていました。
当時こそ単純作業と思っていましたが、今振り返ると様々なAzureのリソース１つ１つに深く触れることができて貴重な時間だったと思います。そもそもAzureのAの字すら知らなかった私ですが、毎日のようにAzureのサービスや言葉をシャワーのように浴びることで、Azureについての理解を猛スピードで深めました。
終わりました！
さて、設定ファイル化が完了して、「後は動作確認すれば終わり」と当時の私はまたもや楽観的でした。
エンジニアの皆様なら分かると思います。これは完全なフラグになりました。
Terraformの実行方法
実行方法は以下の5ステップです。
1. 事前にTerraformをインストールしておく。
2. コマンドプロンプトを起動し、main.tfとvariables.tfを配置しているディレクトリに移動する。
3. $ terraform initを実行し、初期化する。
4. $ terraform planを実行し、実行される内容を確認する。
5. $ terraform applyを実行すると、リソースが作成される。
いざ、動作確認
さて、実際に動作確認をしてみると、大量のエラーメッセージが出てきました。
今でこそ何とも思いませんが、新人だった当時の私はかなり焦りました。大量にエラーが出ましたし、全部英語でしたし、おまけに全部赤文字・・・。
どこから手を付ければいいか分からず困っていましたが、先輩に見てもらいながら、上から順番に１つ１つ内容を確認しながらエラーを潰していきました。
TerraformのソースコードはYAMLという形式で書かれており、JSONに近いフォーマットを持っています。よって、閉じ括弧が１つ足りないだけで沢山怒られます。
他にも、「この価格帯ではこの設定は使えない」というエラーもありました。認証・権限系のエラーもありました。もちろん打ち間違いもたくさんありました。。。。
そんな細かいミスを地道に潰していくまさに沼でしたが、なんとか大量のエラーメッセージを無くすことができました。
今回、元となるTerraformのソースコードを作った上司も、同様に色んな沼にハマったと嘆いていました。よろしければこちらの記事もお読み下さい！
blog.ecbeing.tech
Terraformはやべーやつ
↑この見出しは、実際に上司に言われた言葉でした。
というのも、Terraformは環境を簡単に構築することができる大変便利なツールですが、逆を言うと簡単に環境を破棄することができるツールでもあります。
実際に私が起こしてしまった「やべーやつ」について解説していこうと思います。
Terraformが環境を管理する仕組み
terraform applyのコマンドを実行した後、Terraformが管理するリソースの状態を表す.tfstateファイルが生成されます。
これは何に使うかと言うと、例えば
- 現状のDBの価格プランはA
- 価格プランをBに変えたい
このようなとき.tfファイル上で、価格プランは「A」と定義している部分を「B」に書き換えます。
その後再びterraform applyを実行すれば、前回実行時に作られた.tfstateファイルとの差異であるA→Bのみが実行されることになります。
では、この.tfstateファイルはどこに保存するかというと、デフォルトではローカルの環境に保存されますが、我々のチームではクラウド上に.tfstateファイルを保存する共有ストレージを作成していました。
やべーことが起きた
ある時、私は上司にもらったTerraformのソースコードをもとに、新たなテスト環境用のソースコードを書いて、構築→削除を繰り返して検証していました。しかし、ここでとあるミスをしていました。
.tfstateファイルの名前は、.tfファイルの中で決めることができます。
私がもらったソースコードは既に存在する環境のソースコードだったため、既に存在する.tfstateファイルの名前が定義されています。このままterraform applyを実行すると、既に存在する環境の.tfstateファイルと、新しく作った.tfファイルが競合してしまいます。
勘のいい方はお気づきと思いますが、そう、私は既に存在するテスト環境を上書いてしまったのです。そして、構築→削除を繰り返していたので、削除までしてしまいました…。
当時の私に足りなかったのは以下の点です。
- terraform plan コマンドで実行される内容をきちんと確認しよう
- .tfstateファイルの名前指定をきちんと確認しよう
幸いこのとき、消してしまった環境はすぐにTerraformで再び作ることが出来ました。
とはいえ、「Terraformはやべーやつ」ということを身にしみたので、今では指を指して「ヨシ！」と１つ１つ確認するようになりました。
はじめてのおしごと を終えて
最初は設定ファイル化するだけの簡単なお仕事だと思っていましたが、この仕事を通して沢山の知識を得られました。
- Terraformに関する知識
- Azureの様々なサービス
- インフラの構成
- エラーメッセージの対処方法
- エディタの活用方法 etc...
その中で最も身についたのは、沼にハマっても這い上がる心かもしれません。
実際に他の開発を行っていても、うまく行かないことは多々あります。
今も日々の業務でうまく行かないことは多々ありますが、諦めず、どうしても困っているときは上司に早めにアラートを上げるよう心がけています。
今後もこの初心を忘れずに、エンジニアとして成長していきたいです。
現在
冒頭で述べたとおり、現在、私はTerraformを使って迅速に新たなリソースを提供するという開発サポート的な役割を担当しています。
また、それ以外のフロントエンドやバックエンドのコーディングも行うようになり、改めて、インフラが準備されていることの嬉しさを実感しています。
まだインフラに関して勉強すべきことは多いですが、自分の１つの強みとしてTerraformを身につけられて本当に良かったと思います。
当時こそ、いきなりインフラに触れるというハードな試みでしたが、逆にAzureについての知識を急スピードでつけることができ、とても良かったと感じています。
また、クラウドのインフラ構築については沢山触っているのですが、逆にオンプレミスの環境を触ったことがない私はクラウドネイティブ人間です。今後オンプレミスの環境に触れる機会があれば触ってみたいです。
まとめ
今回は新人の私とTerraformの運命的な出会いについて紹介しました。
この記事ではTerraformについてほんの一部しか紹介できていません。
実際には、構成や実行時などで他にも多くのプロセスがありました。
TerraformやIaCについての深堀りは、また別の機会で紹介しようと考えています。
ここまでお読み頂きありがとうございました！
ecbeingでは沼にハマっても這い上がるエンジニアを募集しています！！
careers.ecbeing.tech
