有名な
herokuプロバイダーは、Twelve-Factor Appと呼ばれるマニフェストをサポートしています。 これは、あらゆるプラットフォームで最新のWebアプリケーションを開発するためのベストプラクティスのセットです。 開業医は準備ができているアプリケーションについて説明します。
- 水平スケーリングへ。
- 継続的な展開へ。
- 最新のクラウドホスティングへ。
マニフェストの一部は広告であると想定できます。12要素アプリケーションがherokuに最も便利にデプロイされます。 しかし、マニフェストの人気が高まるにつれて、一部のクラウドプロバイダーは環境にベストプラクティスを取り入れており、これらのプラクティスは開発者とアプリケーションを展開および管理する人々の両方に役立ちます。
マニフェスト （ハブに
優れた翻訳があります）は詳細すぎるため、詳細な研究には適していません。 同じ記事で、主な利点に簡単に焦点を当てます。
1つのアプリケーション-1つのリポジトリ
すべてのアプリケーションコードはバージョン管理システム内にある必要があります。 また、1つのリポジトリから開発、テスト、および運用サーバーにデプロイします。 ただし、デプロイメントでは、リリースにまだ追加されていないさまざまなブランチにコードが存在する可能性があることを除外していません。
共通コードを使用するアプリケーションが複数ある場合は、共通コードを別のライブラリに割り当て、依存関係として宣言する必要があります。 開発のある段階で、1つのリポジトリに複数の疎結合アプリケーションがある場合、アプリケーションをいくつかに分割し、それぞれを12ファクターアプリケーションにする必要があります。
明示的な依存関係
アプリケーションに暗黙的な依存関係を持たせないでください。 まず、システムとライブラリの両方のすべての依存関係を依存関係マニフェストに記述する必要があります。 最新の言語はすべて、依存関係マニフェストを備えたパッケージマネージャーによって提供されます。 さらに、システムライブラリがアプリケーションに「リーク」しないように、依存関係を分離する必要があります。
したがって、Rubyでは、依存関係を宣言するためのマニフェスト形式としてGemfileを使用し、依存関係を分離するためにexecを使用します。 異なるプラットフォームでのアプリケーションの同じ操作に加えて、これにより新しい開発者はプロジェクトにすばやく参加したり、新しい依存関係をすばやく接続したりできます。
ここでは、OSのen望さえも分離して明示的に宣言するDockerに言及する価値があります。
設定はランタイムプロパティです
構成は、アプリケーションが実行されている場所に応じて変化するすべてのパラメーターです。
- ログイン、パスワード、およびデータベースアドレス。
- サードパーティのサービスとAPIキー。
コードは環境に依存しませんが、構成は依存します。 したがって、コードはリポジトリに、構成は環境に保存する必要があります。 個人アカウントを危険にさらすことなく、パブリックドメインでコードを公開できる場合、すべてを正しく実行しています。
かなり一般的なオプションは、事前に構成された構成セット（開発、テスト、および本番）を使用することです。 新しい環境（開発ジョー、qa、ステージング）を追加すると、サポートする必要があるパラメーターの数が不均衡に増加するため、この分離は良いソリューションとは見なされません。
ローカルおよびサードパーティのサービス
サードパーティのサービスは、データベース、メールサービス、キャッシュサーバー、およびさまざまなサービスのAPIです。 12要素アプリケーションでは、ローカルサービスとリモートサービスを区別しないでください。 各サービスは接続されたリソースであり、接続先のデータ（アドレスと資格情報）を構成に保存する必要があります。
ローカルデータベースをAmazon RDSに置き換えたり、ローカルメールサーバーをサードパーティのものに置き換えたりしても、アプリケーションコードに影響はありません。
アセンブリ、リリース、実行の分離
アプリケーションの展開は、3つの個別の手順で構成されます。
- アセンブリとは、コードを実行可能パッケージに変換することです。依存関係の読み込み、ファイルおよびリソースのコンパイルです。
- リリース -アセンブリと構成を組み合わせます。 リリースはすぐにランタイムで実行する準備ができています。
- 実行 -リリースからの多数のプロセスの起動。
12因子のアプリケーションを開発する場合、これらの手順は厳密に分離する必要があります。 アセンブリは、開発者が変更を投稿する準備ができたときに開始されます。 これは長いプロセスである可能性がありますが、この後リリースコードを変更することはできません。 一方、実行フェーズは、開発者の介入なしに機器のシャットダウンやその他のエラーが発生した場合に自動的に実行できるように、できるだけシンプルにする必要があります。
アプリケーション-一連のプロセス
アプリケーションは、内部状態を保持しない1つ以上のプロセスとして実行する必要があります。 アプリケーションは、RAMまたはディスク上のデータを一時ストレージとして使用できます。 たとえば、画像を再コーディングする場合。 ただし、ユーザーデータは永続的なストレージ（プラガブルリソース）に格納する必要があります。
次のユーザー接続は別のプロセスに発生する可能性があるため（ハードウェア障害またはプロセッサの再起動のため）、これは主にセッションデータに関連しています。
アプリケーションはサーバーに依存しません
PHPアプリケーションは、Apache HTTPD内のモジュールとして起動するか、JavaアプリケーションをTomcat内で起動できます。 それどころか、12因子アプリケーションは完全に自給自足型であり、Webサーバーに依存しません。
これは通常、依存関係宣言を使用して、WebサーバーライブラリをPythonのTornado、RubyのThin、JavaのJetty、PHPのReactPHPなどのアプリケーションに追加することによって行われます。
プロセス規模
異なるプロセスで異なるタスクを処理する必要があります。 たとえば、HTTP要求はWebプロセスで処理でき、長いバックグラウンドタスクはワークフローで処理されます。 これにより、将来的に必要なプロセスのみをスケーリングできるようになります。
プロセスを悪魔化しないようにすることが重要です（プロセスは開始せずに実行する必要があります）。 プロセスマネージャは、アプリケーションの出力ストリームを監視し、プロセスエラーとクラッシュに対応する必要があります。
クイックスタートと正しい終了
これは、状態を維持しないプロセスの論理的な結果です。 プロセスがクラッシュした場合でも、迅速に開始して正しくシャットダウンするプロセスで信頼性を最大化します。
バックグラウンドプロセスは現在のタスクをキューに返し、リクエスト処理プロセスはリクエストを正しく完了する必要があります。 すべてのプロセスの各タスクは、繰り返し実行できるようにする必要があります（たとえば、トランザクションを使用）。
開発を展開に移す
現在、開発と展開の間には大きな違いがあります-異なる人が、異なる時間に、異なるツールでそれを行います。 12の要素を導入するときは、開発と展開を可能な限り近づけるようにしてください。
- 時間 -コードは、開発者が書いてから数時間後に作業バージョンに入る必要があります。
- 人 -開発者はコードの展開に参加し、作業中の作業を監視する必要があります。
- ツール -開発環境は、テスト環境（サードパーティサービス、OS）に最大限対応する必要があります。
stdoutにログインします
ログはイベントのストリームであり、イベントのストリームとしてアクセスする必要があります。 アプリケーションは、ログファイル自体にデータを書き込むべきではありません。ファイルの管理（アーカイブまたは削除）を減らす必要があります。.12ファクターアプリケーションは、その作業のログを標準出力に表示します。 プロセスを開始するマネージャーは、分析またはアーカイブシステムをロジックに誘導する必要があります。
これにより、アプリケーションプロセスとサードパーティサービスの両方を含む、さまざまなプロセスからのイベントを集約できます。 ログ分析システムにより、システム全体の現在の状態の分析、および以前の作業の分析が可能になります。
開発者の環境では、ログは単にコンソールで表示されます。
管理タスク
1回限りの管理プロセス（移行、データベースの修正）は、他のプロセスと同じルールに従う必要があります。
- タスクコードは、メインアプリケーションのコードと一致するリポジトリに存在する必要があります
- 依存関係は、依存関係のメインマニフェストで宣言する必要があるため、通常の展開中にプロセスを完了できます。
- 異なる環境で実行できるように、タスクの構成は環境変数になければなりません