💬

【読書メモ】詳解Terraform Infrastructure as Codeを実現する【1章】

2024/07/06に公開

Terraform

IaC

idea

1章

DevOps とは何か

DevOpsのゴールは、ソフトウェアのデリバリを今までよりはるかに効率的にすることである。

Infrastructure as Code とは何か

「インフラを定義し、デプロイし、更新し、削除するためにコードを書いて実行する」という考え方。
IaCツールには大きく分けて5つのカテゴリがある。

アドホックなスクリプト
設定管理ツール
サーバテンプレーティングツール
オーケストレーションツール
プロビジョニングツール

アドホックなスクリプト

何かを自動化するのに一番単純な方法。
タスクを個別のステップに分割して、
スクリプト言語（Bash、Ruby、Pythonなど）を使って各ステップをコードとして定義する。
それをサーバ上で実行する。

例として、依存関係のあるパッケージをWebサーバにインストールし、
ソースコードをGitリポジトリからチェックアウトし、Apache Webサーバを起動するスクリプトを考える。

#!/bin/bash  
# Webサーバを設定するスクリプト

set -e

# apt-getキャッシュのアップデート
sudo apt-get update

# PHPとApacheをインストール
sudo apt-get install -y php apache2

# リポジトリからコードをコピー
sudo git clone https://~

# Apacheを起動
sudo service apache2 start

利点

広く使われている汎用的なプログラミング言語を使用して、自由にコードを書ける。

問題点

どのようにでも書けてしまうため、開発者毎に異なるスタイルとなってしまう恐れがある。
→その他IaCツールではコードに一定の構造を強いることができる。

アドホックなスクリプトは1回限りのタスクには最適。
全てのインフラをコードとして管理したいなら、その他IaCツールを使うべき。

設定管理ツール

Chef、Puppet、Ansibleなどのツール。
Bashとコードは似ているが、Ansibleのようなツールを使うといくつもの利点を得られる。

コーディング規約
ドキュメント、ファイルのレイアウト、パラメータ、機密情報の管理といった点に関して、
一貫性があって予測可能な構造を強制する。
冪等性
何度実行したかに関わらず正しく動くコードを、冪等性のあるコードという。
Bashスクリプトを冪等性のあるコードにするにはif文を大量に書かないといけないが、
Ansibleの多くの関数はもともと冪等性がある。
配布
Bash等のスクリプトは1台のローカルマシン上で動かすように作成されていることが多い。
Ansibleなどの設定管理ツールは、たくさんのリモートサーバを管理することに特化して設計されている。

サーバテンプレーティングツール

代表的なものとしてはDockerやPacker。
OS、ソフトウェア、ファイル、その他すべてを含んだ完全な「スナップショット」を使ったイメージを作成する。

オーケストレーションツール

仮想マシンやコンテナを管理するためのツール。
代表的なものとしてはKubernetes。

プロビジョニングツール

サーバ自身を作成する役割を持ったもの。
サーバだけでなく、データベース/キャッシュ/ロードバランサ/キュー/監視設定/ネットワーク/証明書など、
インフラに関するあらゆるものを作成できる。
代表的なものとしてはTerraform、CloudFormation。

Infrastructure as Codeの利点とは

端的に言うと、ソフトウェアのデリバリプロセスを劇的に改善できる。

セルフサービス
いわゆる属人化を防ぐことができる。
スピードと安全性
自動化されたプロセスは確実で再利用が可能。
手動で行うことによるミスから解放される。
ドキュメント化
インフラ構成をシステム管理者しか知らない場合、その管理者が休暇・退職した際に詰む。
一方でインフラがコードとして定義されていれば、インフラの状態はコードの中に書かれていることになる。
つまり、IaCはドキュメントとしての役割も果たす。
バージョン管理
コードということはGit等のバージョン管理ツールを使用できる。
変更履歴をいつでも確認できるし、切り戻すことも簡単になる。
バリデーション
コードレビュー、自動化テストなどによって問題発生の可能性を大きく下げられる。
再利用性
インフラを再利用可能なモジュールとしてパッケージすることで、既知でドキュメントもあり、実環境でテストされたコードを再利用できる。
幸福
手動でコードをデプロイし、手動で管理するのは退屈なこと。
IaCを導入することでそれら煩雑な作業から解放される。

Terraformはどう動くのか

クラウドプロバイダにAPIコールしている（省略）

Terraformと他のIaCツールとはどう違うのか

多種多様なIaCツールの選択法について。

設定管理ツールか、プロビジョニングツールか
Ansibleでもサーバをデプロイ可能だし、Terraformを使って設定スクリプトを実行することも可能。
「Terraform + Docker」 or 「Terraform + Ansible」という構成は多い。

ミュータブルなインフラか、イミュータブルなインフラか
Chef、Puppet、Ansibleなどの設定管理ツールはミュータブルなインフラ。
DockerやPackerはイミュータブルなインフラ。

手続き型言語か、宣言型言語か
手続き型言語：ある一定の望ましい状態に到達するための1つ1つの手順を定義するようにコードを書く
宣言型言語：一定の望ましい状態を定義するようにコードを書き、その状態をどのように実現するかはそれぞれのツールに任せる

汎用言語か、ドメイン特化言語か
汎用言語：JSとかPythonなど。すでに習得している場合は学習コストが0。コミュニティも大きい
ドメイン特化言語：HCLなど。シンプルであるため習得が容易。簡潔。

マスタか、マスタレスか
マスタサーバを用いると管理面において負担となる場合がある。
Terraformの場合、クラウドプロバイダのAPIサーバがマスタサーバであると言えるが、
ユーザが管理する必要はない。

エージェントか、エージェントレスか
こちらも管理面において負担となる場合がある。

有償か、無償か
有償サービスの場合、倒産・買収・価格モデル変更には注意する必要がある。
何らかの理由で有償サービスが使えなくなったとしても、
選択したIaCツールが使い続けられるのか理解しておくことが重要。
Terraform、Chef、Puppet、Ansibleの無償版は、どれも本番環境で問題なく使用できる。

大きなコミュニティか、小さなコミュニティか
当然コミュニティが大きいほうがメリットが大きい。

成熟か、最先端か
最近ではTerraformも安定し、信頼できるツールになっている

複数ツールの組み合わせ
「Terraform + Ansible」
インフラのすべてをTerraformでデプロイし、Ansibleを使ってサーバ上にアプリケーションをデプロイする。
利点：追加のインフラが必要なく、最初に取り組むには簡単。
欠点：Ansibleは通常ミュータブルであるため、手続き的なコードを書く必要がある。コードが肥大化するにつれてメンテナンスが難しくなる。

「Terraform + Packer」
Packerでアプリケーションを仮想マシンとしてパッケージ。
その仮想マシンイメージを使ったサーバと、その他インフラをterraformでデプロイ。
利点：追加のインフラが必要なく、イミュータブルであるためメンテナンスが容易
欠点：仮想マシンのビルドとデプロイには時間がかかってしまう

「Terraform + Packer + Docker + Kubernetes」
Packerを使ってDockerとKubernetesがインストールされた仮想マシンイメージを作成。
イメージを使ってサーバのクラスタを起動し、Terraformを使用してインフラをデプロイ。
Docker化したアプリケーションを動かして管理するKubernetesクラスタを構成する。
利点：Kubernetesのビルトイン機能を利用できる / ビルドが高速
欠点：Kubernetesの学習コスト/ 複雑性が高まってしまう