📖
【前半】Twelve-Factor Appを図で書いて理解する
Twelve-Factor Appとは？
Webアプリケーションの設計や構築に関するベストプラクティスを示す方法論を定義したものです。
その名のとおり全部で12あります。
コンテナ学習の礎とするため、今回はこれを図を書いてまとめてみました。
※今回の記事は1~6までで、7~12は次回の記事に記載します。
※図ではTwelve-Factor Appの意図に沿ったAWSサービスを登場させます。
参考
本家
AWS/ECS(Fargate)でTwelve-Factor Appを解説
GoogleCloud
1. コードベース
- コードベースとアプリケーション関係は1対1とする
- 別のアプリケーションと共有するソースコードは外部ライブラリとして切り出す
2. 依存関係
- 明示的にパッケージの依存関係を宣言し管理する
- システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない
例 ：サーバにデフォルトでインストールされているパッケージをアプリケーションで使用しない。使用するものはパッケージマネージャ、手順書で管理する
例2 ：パッケージの把握のために、Dockerfileで環境を構成する
3. 設定
- 良い①💡：設定を環境変数へ入れる
- 良い②💡：パラメータストアなどの情報格納用ストレージへ入れる
- 悪い💀：コード内にベタがき
①
②
4. バックエンドサービス
- ファイル システム、データベース、キャッシュ システム、メッセージ キューなどは外部サービスとして扱う
- 構成変更の際にアプリケーションコードの変更を変更する必要がないようにする
- ネットワーク越しに利用するサービスをアプリから切り離すイメージ
- 構成変更の際は環境変数などから行う
5. ビルド、リリース、実行
- ソフトウェアのデプロイプロセスは、ビルド、リリース、実行の 3 つの段階に分けることが重要
-
ビルド：テストをパスしたコードをビルドして実行可能（なアーティファクト）にする
- アプリケーションの実行環境で直接ソースコードを変更しない
-
リリース：ビルドステージで生成されたアーティファクトを受け取り、現在のデプロイ設定と合わせてリリースを作成する
- リリースは一意の識別出来るIDを持つ
- リリースをコミットIDなどで追跡できることが大切
- 実行：リリースをデプロイする
※この図はビルド、リリース、実行がうまく記載出来ていないので後に差し替える
6. プロセス
- プロセスはステートレスかつシェアードナッシングであること
- プロセスの生成・削除によって環境が移り変わるため、プロセス内の状態に依存させない
- このようにすることでプロセスの拡大、移植が容易となる
- 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービスへ保存する
- データベース、インメモリキャッシュ等
Discussion