🚙

Infrastructure as Codeは最初からやったほうがいい

2021/03/08に公開

最近不慣れな GCP を触ることがあったのですが、最初から Terraform で書くようにしたほうが楽だったので、それについて解説しようと思います。

Web のコンソールを触るのが怖い

他のサービスが同居しているアカウントでインフラを操作すると、他のサービスに影響を与えてしまうのでは…という不安があります。関係のないサービスは別アカウントにするというのがベストプラクティスですが、様々な事情によりそれができない場合もあります。

最初から IaC で触っていれば、コードで生成したインフラ以外を触ることがなく、削除する時も間違えることがなく削除することができ、何度も作り直して試すことが容易になります。

Webのコンソールでも、コマンドラインツールでも同様ですが、作業した内容を記録しておく必要があります。記録していない場合、同じ環境を再現することができません。

最初からコード化をしていれば、手順を覚えておく必要もありません。

コンソールで触っていると、どのサービスとどのサービスが繋がっているかというのがわかりにくいですが、例えば Terraform では必須パラメーターとして存在していることが多く、依存関係を設定していないと適用する前にエラーになってくれたりするので迷うことが少なくなります。

また、サンプルで組み合わせた書き方が充実していたり、組み合わせサンプルのコードが用意されていたりするので、手順を読んで試行錯誤するより確実にインフラ構築をすることができます。

特に AWS で CDK や Copilot といったツールを使っておくと、複雑なサービス間の依存関係を考えることがなく構成を立ち上げることができます。

依存関係と同様に、全てのパラメーターがドキュメントに書かれているので、「このリソースではこれが設定できる」とか「このリソースはこの設定をすることができない」というのがドキュメントを読むだけで把握することができます。

ただし GCP の Cloud Run のようなメタデータでパラメーターを指定するような類のものの場合や、AWS RDS のパラメーターグループのような任意のものを指定するようなものはドキュメントには書かれていないので、そこはオフィシャルのドキュメントやコンソールの画面を併せて読む必要があります。

コンソールで試行錯誤するより、最初からコードで書いて試行錯誤したほうが良いことが多いです。手作業を後からコード化するのは二度手間にもなるので、学習目的とかでない限りは最初からコードを書きましょう。

もちろんある程度の IaC ツールに慣れておく必要や、クラウドインフラの使い方に慣れておく必要がありますので、そこは基礎教養として素振りしておきましょう。