「特定の"インフラ担当"・"開発メンバー"」や「古の記憶」に頼らず、『開発メンバー全員が拡張や移行作業を気軽にできるインフラ』を実現するために、私のチームで採用しているTerraformを使ったAWS環境運用フローをご紹介いたします。Terraformで移行および運用するフローにしたことで、構成全体に対する変更の柔軟性が高まり、コードがあることで運用および拡張期において設計の変更や手戻りを恐れずに開発を進められるようになりました。先日、door賃貸をオンプレミスからAWSに完全移行しました。移行前はテスト・本番各環境合わせて仮想サーバ50台ほどで構成されていました。移行後はマネージドなサービスを活用するなどして30台ほどになっています。運用とサービス拡充における人的負荷軽減・アジリティおよびメンテナンスビリティの向上を目的としてのAWS環境への全面移行です。Codeの考え方を参考に、AWS環境のほぼ全てをコードで記述することにしました。メインのツールとしては、PackerとTerraformを採用しました。ここでは主にTerraformの利用を中心に運用フローを述べていきたいと思います。複数人数で一度に一つの環境をコードで管理するには、各開発者の変更を矛盾無く対応させる必要があります。修正の種類によっては開発用・ステージング環境に実際に適用してみて正しいかどうかを確認する必要もあります。新機能追加のためのテスト環境の追加Terraformの採用理由TerraformとはHashiCorp社が開発した、クラウドっぽい環境に対するオーケストレーションツールです。AWSの他にAzure等のクラウド、OpenStack、VMwareなど十数種類の環境について統合的に記述できます。AWSには既にオーケストレーションツールとしてAWSよりCloudFormationが用意されておりますが、下記点を評価してTerraformを採用しました。各リソースのidを動的に解決し、さらに変数名で容易に参照出来るなど表現力の高さPackerなどのプロビジョニングツール連携が標準機能で備わっているいわゆるDryRunの機構が優れており、ミスに容易に気づける。多人数で一つのインフラ環境を構築する移行期では特に安心感が高まる。production)で切り分けてファイルを展開しています。セットとは本エントリで付けた便宜的な名前ですが、サービスのモジュールを構成するファイルのまとまりくらいにとらえてください。下に示すディレクトリ構造にはセットとして、下記が見えています。次の4つセットを分けて構築しています。手戻りに時間がかかる重篤な問題が発生してしまいがちなRoute53とRDSについては分けています。問題発見の自動的な仕組み化によってひとつにしたいですが、問題発生箇所が多岐にわたるので、今のところは分離状態です。stateファイルの部分で後述しますが、環境毎の基本的な構成はすべてtfファイルに記載されており、具体的な切り替えはtfvarsの値により変更されます。treeの結果を編集してはしょっていますが、このような内容です。*.tfstateファイルの配置Terraformは直前の状態をstateファイルに残しています。検証する事が出来ます。stateファイルは常にひとつという前提でTerraformは実行されますが、環境を変更する開発者が複数人数いる場合は、逐次状態が変化していくために開発者端末上でのstateファイルに矛盾が発生します。これに対する対処法はいくつかありますが、我々はTerraformの機能にあるS3上に配置するという手段を採用しました。移行期は試行錯誤が高い頻度で入るので特定のブランチを常に見るという運用が難しく、事前検証の結果などで細かい矛盾を把握した方が運用上早いのも理由にあります。具体的には次のようにパラメータを与えてシェルスクリプトにより実行しています。ように簡便に実行できるようなスクリプトを実行しています。Qiitaのここの記事が参考になると思います。-state=${TFSTATE_FILE}環境の定義tfvarsによる切り替えtfvarsで各環境の具体値を決定しています。シェルスクリプトでtfvarsを切り替えます。切り替え項目は具体的には次のような項目です。Subnetなら例として次のような記述になります。varで始まる${var.hoge}部分が変数化された部分で、実行時に環境毎に設定が入ります。そのほかは、実行時にAWSから取得される情報で補完されます。開発中のリソースなどは本番に出て欲しくない場合もあります。固有環境のtfファイルだけ別ディレクトリに配置しています。tfファイルの配置箇所は一つのディレクトリしか指定できないため、シェルスクリプトで各環境のtfファイルを一つのテンポラリディレクトリにコピーした上でterraformコマンドを実行しています。次にフローの概要図を示します。詳細には次のようなフローでstagingおよび本番に適用されます。masterブランチが本番環境、stagingブランチがstaging環境に対応しており、masterブランチはstagingブランチからPRを受ける前提です。ブランチからトピックブランチを生やす。各開発者はトピックブランチで修正を実施し、staging環境に対してplanし、問題が無ければstagingブランチにPRを投げる。その際CircleCIによりplanが実施され、内容がレビュワーに共有される。コードレビューで問題が無ければ、トピックブランチ上でapplyする。stagingにマージした後にapplyしないのは、Terraformのvalidationだけでは分からない問題がある場合があるためである。実際にapplyで問題があれば、再度コミットし、レビューを受け問題が無くなるまで繰り返す。実際に問題が無ければstagingブランチで本番に対してplan・applyし、masterにマージする。applyについては各メンバーは一応チャットにて実施前に宣言します。specなどの自動テストも実際の環境が存在しないとできないために、人手が介入しています。よかったこと・課題よかったことAWSのリソースがtfファイル上に記述されているため無秩序にならないAWSのほぼすべての設定について、履歴とコード管理出来るようになった。各設定の意図をコメントや変数名に表現できる。複数人数で修正してもあまり気兼ねせず、スピーディーに開発できる。移行期にstaging環境で構築検証を進めていたが、本番リリース直前期にオペミスの心配も設定だけで一度に環境を新たに構築できて最高に気持ちよかった。環境について説明するとき、GitHubのリンクを送るだけでいい。新規機能のリソースを本番に展開するのが設定の移動だけで楽になった。EC2について、AutoScale前提に、Terraformでの管理はAnsibleによるAMI作成とアドホックに稼働マシンに流す仕組みの両方をつくって、cloud-initによる管理を作ればそう問題にならない。08:30Tweet関連記事2018-09-14画像配信システムにCDNの導入を試みた話こんにちは。Inc.LIVESENSEはてなブログをはじめよう!livesense-blogさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。