はじめに
こんにちは、ラクスでインフラを担当しているftkenjです。
弊社ではサービスの製品サイトをAWSで運用していますが、リソースの追加・変更が発生するたびにコンソールにログインをして画面をポチポチして行っています。
オンプレよりは楽ですが、クラウドサービスの利点を生かし切れていませんでした。
そこでサービスでも利用してるTerraformで構成管理を行っていくことにしました。
コード化していく中で苦労したことなどを伝えられればと思います。
目次
Terraformって何？
Terraformとは、HashiCorpがGo言語で開発したオープンソースのツールです。
AWSやGCPといったクラウドサービス上のインフラ構成をコード管理するために使用します。
ここにGitも組み合わせることでインフラ構成をバージョン管理することも可能になります。
最終的にはCI/CDまで実装することができれば、複雑な手順や数時間とかかっていた作業も不要になります。
とはいえ、既存環境をコード化するのも一筋縄とはいかず・・・
きっかけ
新規サーバ・サイトの追加時のたびにAWSのWebコンソールで操作をしていました。 コンソールからの操作はどうしても画面遷移が多く、横にもう一つコンソールを出して既存設定と見比べながら設定することが大変でした。
この作業を楽にしたい、というのがコード化のきっかけになります。
苦労したこと
ディレクトリの構成
始めはenvおよびmodules配下それぞれを本番環境と検証環境で分けていました。
しかし、これだとmodulesでコードが重複してしまい煩雑になってしまいます。
そのためmodulesは共通化して環境の差分は変数(env)で補完する、という構成にしました。
例)
.
┣━ env
┃ ┣━ 検証環境
┃ ┃ ┗━ main.tf
┃ ┃
┃ ┗━ 本番環境
┃ ┗━ main.tf
┃
┗━ modules
┣━ サービス名1
┃ ┣━ AWSサービス名1.tf(メインとなるtfファイル)
┃ ┣━ variables.tf
┃ ┗━ (output.tf)
┃
┣━ サービス名2
┃ ┣━ AWSサービス名2.tf
┃ ┣━ variables.tf
┃ ┗━ (output.tf)
...
どちらかの環境にしか存在しないリソースも存在していますが、三項演算子を使用して制御しています。
詳しくは次回紹介できればと思います。
リソースの取り込み
コードを書くよりも、実環境の状態を取り込む方が大変でした・・・
terraform importは取り込むリソースを指定して実行することで、「terraform.tfstate」というファイルにjson形式で取り込まれます。
ただし、取り込みには対象のリソースのIDやARN(Amazon Resource Name)が必要であり、基本的にTerraformでコード化しているすべてのresource分を行わなければいけません。
細かいところですと、Route53のレコードやELBのListener Ruleが1項目ずつ取り込むことになります。
AWSで新しく環境構築する、もしくは始めたばかりのうちにコード化しておく方が結果的に少ない労力で済みますね・・・
一応「terraformer」という既存環境を一括で取り込めるOSSがあります。
こちらはtfファイルも自動生成してくれますが、各リソースの設定値がハードコーディングされているなど、生成後に手を加える必要があります。
いち早く既存環境をコード化して運用していきたい、という場合は使ってみるのもアリではないでしょうか。
実環境との差分埋め
すべての取り込みが完了したら「terraform plan」(dry-runのイメージ)の実行です。
これで実環境との差分が出なければ、めでたくコード化完了となりますが・・・
実行後、以下のように「変更の詳細」とadd、change、destroyの総数が表示されます。
特にchange、destroyは実環境が壊れてしまうので注意しなければいけません。
‐ add：新規追加されるリソース数
‐ change：変更されるリソース数
‐ destroy：削除されるリソース数
… ここから上は変更の詳細 … Plan: 8 to add, 0 to change, 0 to destroy. ─────────────────────────────────────────────────────────────────────────────────────── Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.
なお取り込みできないresourceも存在するため、terraform applyの初回実行までaddが残ってしまうこともあります。
その場合は、取り込めないresource以外に変更されない状態するまで差分を埋めていきます。
良かったこと
terraformの知見が広がった
これまでTerraformを触ったことがなかったので、試行錯誤しながら進めていました。
ピンポイントでほしい情報が載っている技術ブログが見つからないなどありましたが、公式ドキュメントが分かりやすく一番重宝しました。
terraform import実行時に必要なリソースID等も公式ドキュメントで確認することができます。
上の方でも書きましたが、今回コード化していく中で役立ちそうなところを次回紹介できればと思います。
運用面の変化
コード化してからの運用がどうなったかをかければよかったのですが、まだ運用開始できるところまでできていません。 機会があればコード化前後でどういった変化があったのかをお伝えできればと思います。
今後について
コード化までは完了しているため、Terraformの運用/管理を整理していきます。 作成者でしかTerraformから構成変更・追加ができない状態ではコード化した意味がありません。
CI/CDのパイプラインも設計していきたいですが、こちらは先が長くなりそうです。
おわりに
Terraformを触り始めてまだ半年程度ですが、コードを書くこと自体は難しくはありませんでした。
それよりも煩雑にならないための事前設計と既存環境との差分をなくしていくことが大変でした。
あとはなんといってもterraform importです。
IDやARNが必要になるため、どうしても1つずつしか取り込めないのが手間でした。
そういった意味でも、コード化するのであれば最初からTerraformで構築する方が楽だと実感しました。
もしくはAWSであれば、料金がかかってしまいますがCloudFormationをを利用することでコード化の難易度は下がるのかもしれません。
