サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC24
12factor.net
XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する プロセスフォーメーションは、アプリケーションが実行されたときにアプリケーションの通常の役割(Webリクエストの処理など)に使われるプロセス群である。それとは別に、開発者はしばしばアプリケーションのために1回限りの管理・メンテナンス用のタスクを実行したくなる。例えば: データベースのマイグレーションを実行する。(例:Djangoにおける manage.py migrate やRailsにおける rake db:migrate) 任意のコードを実行したり、生のデータベースに対してアプリケーションのモデルを調査したりするために、コンソール(REPLシェルとも言われる)を実行する。多くの言語ではインタプリタを引数なしで実行する(例:python や perl)ことでREPLを利用できるが、別のコマンドを用意している場合もある(例
I. コードベース バージョン管理されている1つのコードベースと複数のデプロイ Twelve-Factor AppはGitやMercurial、Subversionなどのバージョン管理システムで常に変更を追跡している。リビジョン追跡データベースのコピーは コードリポジトリ と言われ、単に リポジトリ とも言われる。 コードベース は、単一のリポジトリ(Subversionのような集中バージョン管理システムの場合)またはルートコミットを共有する複数のリポジトリ(Gitのような分散バージョン管理システムの場合)である。 コードベースとアプリケーションの間には、常に1対1の関係がある。 もし複数のコードベースがある場合、それはアプリケーションではない – それは分散システムである。分散システムのそれぞれのコンポーネントがアプリケーションであり、個別にTwelve-Factorに適合することができ
VII. ポートバインディング ポートバインディングを通してサービスを公開する WebアプリケーションはWebサーバーコンテナの内部で実行されることがある。例えば、PHPアプリケーションはApache HTTPD内部のモジュールとして実行されるかもしれないし、JavaアプリケーションはTomcatの内部で実行されるかもしれない。 Twelve-Factor Appは完全に自己完結 し、Webに公開されるサービスを作成するために、コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。Webアプリケーションは ポートにバインドすることでHTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。 ローカルの開発環境では、開発者はアプリケーションによって公開されたサービスにアクセスするために、http://localhost:5000/のようなサービスのURLにア
IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する Twelve-Factor Appの プロセス は 廃棄容易 である、すなわち即座に起動・終了することができる。 この性質が、素早く柔軟なスケールと、コード や 設定 に対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を高める。 プロセスは、 起動時間を最小化する よう努力するべきである。理想的には、1つのプロセスは、起動コマンドが実行されてから数秒間でリクエストやジョブを受け取れるようになるべきである。起動時間が短いと、リリース作業やスケールアップのアジリティが高くなる。さらに、プロセスマネージャーが必要に応じてプロセスを新しい物理マシンに簡単に移動できるようになるため、堅牢性も高くなる。 プロセスは、プロセスマネージャーから SIGTERMシグナルを受け取ったときに、グレースフルにシャットダウンす
III. Config Store config in the environment An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes: Resource handles to the database, Memcached, and other backing services Credentials to external services such as Amazon S3 or Twitter Per-deploy values such as the canonical hostname for the deploy Apps sometimes store c
X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ 歴史的に、開発環境(開発者が直接変更するアプリケーションのローカルデプロイ)と本番環境(エンドユーザーからアクセスされるアプリケーションの実行中デプロイ)の間には大きなギャップがあった。これらのギャップは3つの領域で現れる。 時間のギャップ: 開発者が編集したコードが本番に反映されるまで数日、数週間、時には数ヶ月かかることがある。 人材のギャップ: 開発者が書いたコードを、インフラエンジニアがデプロイする。 ツールのギャップ: 本番デプロイではApache、MySQL、Linuxを使うのに、開発者がNginx、SQLite、OS Xのようなスタックを使うことがある。 Twelve-Factor Appでは、継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ。 上で述べた3つのギャップを見る。
XI. ログ ログをイベントストリームとして扱う ログ は実行中のアプリケーションの挙動を可視化する。サーバーベースの環境では、ログは一般的にディスク上のファイル(“ログファイル”)に書き込まれる。しかしこれは出力フォーマットの一つに過ぎない。 ログは、すべての実行中のプロセスとバックエンドサービスの出力ストリームから収集されたイベントが、集約されて時刻順に並べられたストリームである。生の状態のログは、通常1行が1つのイベントを表すテキストフォーマットである(例外のバックトレースは複数行に渡る場合もあるが)。ログには固定の始まりと終わりはなく、アプリケーションが稼動している限り流れ続ける。 Twelve-Factor Appはアプリケーションの出力ストリームの送り先やストレージについて一切関知しない。 アプリケーションはログファイルに書き込んだり管理しようとするべきではない。代わりに、それ
VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する アプリケーションは、実行環境の中で1つもしくは複数の プロセス として実行される。 最も単純な場合では、コードは単体のスクリプトであり、実行環境は言語ランタイムがインストールされた開発者のローカルノートPCであり、プロセスはコマンドラインから実行される(例:python my_script.py)。対極にあるのは、複数の実行プロセスとしてインスタンス化される多くのプロセスタイプを使う洗練されたアプリケーションの本番デプロイである。 Twelve-Factorのプロセスはステートレスかつシェアードナッシング である。永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービス(典型的にはデータベース)に格納しなければならない。 プロセスのメモリ空間やファイルシステムは、短い単一のトランザク
III. 設定 設定を環境変数に格納する アプリケーションの 設定 は、デプロイ(ステージング、本番、開発環境など)の間で異なり得る唯一のものである。設定には以下のものが含まれる。 データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル Amazon S3やTwitterなどの外部サービスの認証情報 デプロイされたホストの正規化されたホスト名など、デプロイごとの値 アプリケーションは時に設定を定数としてコード内に格納する。これはTwelve-Factorに違反している。Twelve-Factorは 設定をコードから厳密に分離すること を要求する。設定はデプロイごとに大きく異なるが、コードはそうではない。 アプリケーションがすべての設定をコードの外部に正しく分離できているかどうかの簡単なテストは、認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソ
II. 依存関係 依存関係を明示的に宣言し分離する ほとんどのプログラミング言語は、サポートライブラリを配布するためのパッケージ管理システムを提供している。例えば、PerlにおけるCPANやRubyにおけるRubygemsなどである。パッケージ管理システムでインストールされるライブラリは、システム全体(“site packages”と言われる)にインストールされる場合と、アプリケーションを含むディレクトリのスコープ(“vendoring”または“bundling”と言われる)にインストールされる場合がある。 Twelve-Factor Appは、システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない。 すべての依存関係を 依存関係宣言 マニフェストで完全かつ厳密に宣言する。さらに、実行時には 依存関係分離 ツールを使って、取り囲んでいるシステムから暗黙の依存関係
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portab
このページを最初にブックマークしてみませんか?
『The Twelve-Factor App』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く