IaC：Infrastructure as Code¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. IaC¶
IaCとは¶
構成ファイルの実装に基づくプロビジョニングによって、インフラの構成を管理する手法のこと。
補足として、ここでいう『インフラ』は、ハードウェアと一部のソフトウェア (OS、ミドルウェア) を合わせたものである。
メリット¶
▼ 変更をコードレビュー可能¶
画面上からインフラを変更する場合、画面共有しながら操作し、レビューと変更を同時に行うことになる。
コード化により、レビューを事前に行ったうえで変更する、という手順を踏める。
▼ ヒューマンエラーが減る¶
画面上からの変更であると、ヒューマンエラーが起こってしまう。
コード化すれば、これが減る。
▼ 再利用や冗長化が簡単¶
複数のアプリケーションのために、同様の設定で同様のインフラを作成する場合や、1つのアプリケーションのために、インフラを冗長化する場合、いくつも手動で作成する必要があり、労力がかかる。
コード化すれば、これが楽になる。
▼ 過去の変更が記録に残る¶
画面上からの変更であると、過去の変更履歴が残らない。
コードをバージョン管理すれば、Issueと紐付けて、履歴を残せる。
デメリット¶
▼ 変更のスピードが落ちる¶
変更時に、画面上からの操作であればすぐに終了する変更であるのにも関わらず、コード化により、変更までに時間がかかる。
そのため例えばAWSとすると、運用時に変更する頻度が多いインフラ (例：API Gateway (VPCリンクを含む) 、IAMユーザ (紐付けるロールやポリシーを含む) ) はコード化せず、あえて画面上から作成する。
▼ クラウドプロバイダーの機能追加に追従しにくい¶
クラウドプロバイダーは日々をオプションを追加している。
画面上からの操作であればすぐにオプションを使用できるが、コード化により、ツールのバージョンをアップグレードしなければ、こを使用できない。
運用時に便利なオプションを使用できず、インフラを改善できないことに繋がる。
▼ リリースの心理的ハードルが高い¶
画面上から変更すれば、インフラ変更のリリース中に予期せぬエラーが起こることはまずない。
しかし、コード化ツールでは、変更のリリース中に予期せぬエラーが起こる可能性は決して低くないため、リリースの心理的ハードルが高くなる。
02. 手続き型¶
手続き型とは¶
インフラの構成順序を手続き的に定義することによって、インフラを作成/更新/削除する手法のこと。
インフラの操作順序を人間が理解しておく必要があり、インフラの構成管理のコストが高い。
一方で、順番さえ理解していれば、構成ファイルを簡単に実装できるため、学習コストが低い。
サーバー系¶
▼ サーバープロビジョニング (物理/仮想)¶
- Ansible
- Chef
コンテナ系¶
▼ コンテナプロビジョニング¶
- Ansible Container
- Dockerfile
クラウドインフラストラクチャ系¶
▼ クラウドインフラストラクチャプロビジョニング¶
- Ansible
03. 宣言型¶
宣言型とは¶
インフラのあるべき状態を定義することによって、インフラを作成/更新/削除する手法のこと。
ツールごとに独自の宣言方法を持っており、学習コストが高い。
その一方で、最終的な状態を定義しさえすれば、作成/更新/削除の順序はツールが解決してくれるため、インフラの構成管理のコストが少ない。
サーバー系¶
▼ サーバープロビジョニング (物理/仮想)¶
- CFEngine
- Puppet
- Vagrantfile
▼ マシンイメージプロビジョニング¶
- Packer
コンテナ系¶
▼ コンテナプロビジョニング¶
- Vagrantfile
▼ コンテナイメージプロビジョニング¶
- Packer
▼ コンテナオーケストレーション¶
- Ansible Container
- Docker compose
- Docker Swarm
- Kubernetes
クラウドインフラストラクチャ系¶
▼ クラウドインフラストラクチャプロビジョニング¶
- AWS CloudFormation
- Azure Resource Manager
- Google Cloud Deployment Manager
- SAM
- Serverless Framework
- Terraform
- Vagrant
▼ クラウドインフラストラクチャイメージプロビジョニング¶
- Packer
04. プロビジョニング¶
サーバープロビジョニング¶
▼ サーバープロビジョニングとは¶
サーバーを最終的な状態に至らせるまでの一連の処理のこと。
コンテナプロビジョニング¶
▼ コンテナプロビジョニングとは¶
コンテナを最終的な状態に至らせるまでの一連の作業のこと。
クラウドインフラプロビジョニング¶
▼ クラウドインフラプロビジョニングとは¶
クラウドインフラを最終的な状態に至らせるまでの一連の作業のこと。
05. コンテナオーケストレーション¶
コンテナオーケストレーション¶
複数のコンテナの稼働 (プロビジョニング、デプロイメインと、スケーリング、コンテナ間ネットワーク、など) を一括で管理する。
コンテナオーケストレーションの種類¶
▼ 単一ホストの場合¶
単一ホスト上のコンテナが対象である。
異なるDockerfileを基に、コンテナイメージのビルド、コンテナレイヤーの作成、コンテナの作成、コンテナの起動、を実行できる。
- Docker
- Docker Compose
▼ 複数ホストの場合¶
複数ホスト上のコンテナが対象である。
どのホスト上のdockerデーモンに対して、どのコンテナに関する操作を行うのかを選択的に命令できる。
- Docker Swarm
- Kubernetes
05-02. デザインパターンの種類¶
サイドカーパターン¶
▼ サイドカーパターンとは¶
アプリコンテナと同じPod内や、AWS ECSタスク内に、アプリケーションの一部の機能のみを持つコンテナを配置する。
▼ サイドカーパターンの使用例¶
| 例 | 説明 |
|---|---|
| ロギングコンテナの配置 | ログルーティングコンテナをサイドカーコンテナとして稼働させ、アプリコンテナから受信したログをログ監視バックエンドに送信する。 |
| メトリクス収集コンテナの配置 | メトリクス収集コンテナをサイドカーコンテナとして稼働させ、アプリコンテナからメトリクスのデータポイントを収集する。 |
アンバサダーパターン¶
▼ アンバサダーパターンとは¶
アプリコンテナと同じPod内や、AWS ECSタスク内に、リバースプロキシコンテナ (Envoy、Linkerd、など) を配置する。
サービスメッシュを実現するために採用される。
サイドカーパターンではないが、このプロキシコンテナのことをサイドカーコンテナともいう。