十二因子アプリ-十二因子アプリ

親愛なる読者！ Herokuプラットフォーム開発者によるThe Twelve-Factor App Webアプリケーション開発方法論の翻訳を紹介します。 私のコメントは記事中にネタバレによって隠されています。

はじめに

今日、ソフトウェアは通常、 WebアプリケーションまたはSaaS（Software -as-a- Service）と呼ばれるサービスの形で配布されます。 12の要因の適用は、次のようなSaaSアプリケーションを作成するための方法論です。

• 宣言形式を使用して、インストールおよび構成プロセスを記述します。これにより、プロジェクトに接続する新しい開発者の時間とリソースが最小限に抑えられます。
• ランタイム間の最大限の移植性を前提とするオペレーティングシステムとの合意がある。
• 最新のクラウドプラットフォームでの展開に適しており、サーバーやシステム管理の必要性がなくなります。
• 開発環境とランタイム環境の不一致を最小限に抑えます。これにより、最大限の柔軟性を得るために、 継続的な展開 （継続的な展開）を使用できます。
• また、開発ツール、アーキテクチャ、およびプラクティスを大幅に変更することなく拡張できます。

12の要因の方法論は、任意のプログラミング言語で記述され、サードパーティサービス（バッキングサービス）（データベース、メッセージキュー、キャッシュメモリなど）の任意の組み合わせを使用するアプリケーションに適用できます。

背景

このドキュメントへの貢献者は、数百のアプリケーションの開発と展開に直接関与し、 Herokuプラットフォームでの作業中に数十万のアプリケーションの開発、実行、スケーリングを間接的に目撃しました。

このドキュメントは、さまざまなSaaSアプリケーションを実際に使用および観察したすべての経験をまとめたものです。 このドキュメントは、アプリケーション開発への3つの理想的なアプローチを組み合わせたものです。時間の経過に伴うアプリケーションの有機的成長のダイナミクス、アプリケーションコードベースで作業し、 ソフトウェア侵食の影響を排除する開発者間の協力のダイナミクスに特に注意を払います。

私たちの動機は、現代のアプリケーション開発の実践で遭遇したいくつかの体系的な問題の認識を高め、これらの問題を議論するための一般的な基本概念を提供し、関連用語でこれらの問題に対する一般的な概念の解決策を提供することです。 この形式は、Martin Fowlerの「 Patterns of Enterprise Application Architecture and Refactoring」の本に触発されています。

このドキュメントは誰が読むべきですか？

SaaSアプリケーションを作成する開発者。 そのようなアプリケーションを展開および管理するエンジニアへのOps。

12の要因

I.コードベース
バージョン管理システムで監視される1つのコードベース-複数の展開

II。 依存関係
依存関係を明示的に宣言して分離する

III。 構成
実行時に構成を保存する

IV。 サードパーティサービス（バッキングサービス）
プラグ可能なリソースとしてサードパーティのサービス（バッキングサービス）を検討する

V.アセンブリ、リリース、実装
アセンブリ段階と実行段階を厳密に分離

VI。 プロセス
内部状態を保持しない1つ以上のプロセスとしてアプリケーションを実行します（ステートレス）

VII。 ポートバインディング
ポートバインドによるサービスのエクスポート

Viii。 並行性
プロセスでアプリケーションをスケーリングする

IX。 使い捨て
クイックスタートと正しいシャットダウンで信頼性を最大化

X.アプリケーション開発/作業パリティ
開発環境、ステージング環境、および本番環境を可能な限り同様に保ちます。

Xi。 ロギング
ログをイベントストリームと考える

XII。 管理タスク
ワンタイムプロセスを使用して管理/管理タスクを実行する

I.コードベース

バージョン管理システムで監視される1つのコードベース-複数の展開

Git 、 Mercurial、 Subversionなどのバージョン管理システムでは、12の要因の適用が常に追跡されます。 監視対象バージョンのデータベースのコピーはコードリポジトリと呼ばれ、多くの場合、 コードレポまたは単にレポ（レポ）に短縮されます。

コードベースは、単一のリポジトリ（Subvertionなどの集中型バージョン管理システム）または共通の初期コミットを持つ多くのリポジトリ（Gitなどの分散型バージョン管理システム）です。



コードベースとアプリケーションの間には常に1対1の対応があります。

• 複数のコードベースがある場合、これはアプリケーションではなく、分散システムです。 分散システムの各コンポーネントはアプリケーションであり、各コンポーネントは12の要因に個別に対応できます。
• 複数のアプリケーションが同じコードを共有しているという事実は、12の要因に違反しています。 この状況での解決策は、依存関係マネージャーを介して接続できるライブラリに共通コードを割り当てることです。

各アプリケーションには1つのコードベースしかありませんが、同じアプリケーションの多くの展開が存在する可能性があります。 デプロイされたアプリケーション（デプロイ）は、アプリケーションの実行中のインスタンスです。 通常、これは作業サイト展開と1つ以上の中間サイト展開です。 さらに、各開発者は自分のローカル開発環境で実行されているアプリケーションのコピーを持ち、それぞれがデプロイ済みアプリケーション（デプロイ）としての資格も持っています。

コードベースはすべての展開で同じである必要がありますが、同じコードベースの異なるバージョンを各展開で実行できます。 たとえば、開発者には、中間展開にまだ追加されていない変更がいくつかある場合があります。 中間展開には、運用展開にまだ追加されていない変更がいくつかある場合があります。 ただし、これらのデプロイメントはすべて同じコードベースを使用するため、同じアプリケーションの異なるデプロイメントとして識別することができます。

---

II。 依存関係

依存関係を明示的に宣言して分離する

ほとんどのプログラミング言語には、PerlのCPANやRubyのRubygemsなど、ライブラリを配布するためのパッケージマネージャーが付属しています。 パッケージマネージャーによってインストールされたライブラリは、システム全体からアクセス可能にインストールする（いわゆる「システムパッケージ」）か、アプリケーションを含むディレクトリ内のアプリケーションでのみ使用できます（いわゆる「ベンダー」および「バンドル」）。

12の要因の適用は、システム全体で利用可能な暗黙的に利用可能なパッケージに決して依存しません。 アプリケーションは、 依存関係宣言マニフェストを使用して、すべての依存関係を完全かつ正確に宣言します。 さらに、ランタイム依存関係分離ツールを使用して、暗黙的な依存関係が周囲のシステムから「漏れ出ない」ようにします。 依存関係の完全かつ明示的な仕様は、アプリケーションの開発と運用の両方で同じ方法で適用されます。

たとえば、Ruby Gem Bundlerは、 Gemfileを、依存関係を宣言するためのマニフェスト形式として使用し、依存関係を分離するためのbundle execを使用します。 Pythonには、これらのタスクのための2つの異なるツールがあります。宣言にはPipが使用され、分離にはVirtualenvが使用されます。 Cにも依存関係を宣言するためのAutoconfがあり、静的バインディングは依存関係の分離を提供できます。 どのツールキットを使用するかに関係なく、依存関係の宣言と分離は常に一緒に使用する必要があります。そのうちの1つだけでは、12の要因を満たすには不十分です。

依存関係を明示的に宣言する利点の1つは、新しい開発者向けにアプリケーションを簡単に構成できることです。 新しい開発者は、アプリケーションのコードベースを自分のマシンにコピーできます。必要な要件は、言語ランタイムとパッケージマネージャーの存在のみです。 アプリケーションコードの実行に必要なものはすべて、特定の構成コマンドを使用して構成できます 。 たとえば、Ruby / Bundlerの場合、設定コマンドはbundle installで、Clojure / Leiningenの場合はlein depsです。

また、12の要因の適用は、システムツールの暗黙的な存在に依存しません。 例としては、ImageMagickおよびcurlプログラムの起動があります。 これらのツールは多くのシステムまたはほとんどのシステムに存在する可能性がありますが、アプリケーションが将来動作する可能性のあるすべてのシステムに存在すること、または別のシステムで見つかったバージョンがアプリケーションと互換性があるかどうかは保証されません アプリケーションがシステムツールを実行する必要がある場合、このツールをアプリケーションに含める必要があります。

---

III。 構成

実行時に構成を保存する

デプロイメント （開発環境、中間デプロイメントおよび運用デプロイメント）の間で変更できるのはアプリケーション構成のみです。 これには以下が含まれます：

• データベース、キャッシュ、その他のサードパーティサービスなどのリソース接続識別子
• Amazon S3やTwitterなどの外部サービスに接続するためのログイン詳細
• 正規のホスト名などの展開環境固有の値

アプリケーションは、構成をコードの定数として保存する場合があります。 これは、 構成とコードの厳密な分離を必要とする12の要因の方法論に違反しています 。 構成はデプロイメント間で大きく異なる可能性があるため、コードを変更しないでください。

構成とアプリケーションコードが正しく分離されているかどうかのリトマステストは、プライベートデータを損なうことなく、いつでもアプリケーションコードベースを自由に利用できるという事実です。

この「構成」の定義には、Railsの「config / routes.rb」などの内部アプリケーション構成や、 Springでの メインモジュールの接続方法は含まれないことに注意してください。 このタイプの構成はデプロイメント間で変わらないため、コード内に保持することをお勧めします。

別の設定方法は、バージョン管理システムに保存されていない設定ファイルを使用することです。たとえば、Railsの「config / database.yml」です。 これは、コードに保存されている定数の使用に対する大きな改善ですが、この方法にはまだ欠点があります。設定ファイルを誤ってリポジトリに保存するのは簡単です。 構成ファイルがさまざまな場所およびさまざまな形式で散らばっている傾向があります。これにより、すべての設定を1か所で表示および管理することが難しくなります。 さらに、これらのファイルの形式は通常、特定の言語またはフレームワークに固有です。

12個の要素を適用すると、 環境変数 （多くの場合env varsまたはenvに短縮）に構成が保存されます 。 環境変数は、コードを変更せずにデプロイメント間で簡単に変更できます。 構成ファイルとは異なり、誤ってそれらをコードリポジトリに保存することはほとんどありません。 また、ユーザー構成ファイルやJavaシステムプロパティなどの他の構成メカニズムとは異なり、これらは言語およびオペレーティングシステムに依存しない標準です。

構成管理への別のアプローチはグループ化です。 アプリケーションは、Railsのdevelopment環境、 test環境、 production環境など、特定のデプロイメントの名前にちなんで名付けられたグループ（多くの場合「環境」と呼ばれる）に構成をグループ化します。 この方法は十分にスケーラブルではありません。異なるアプリケーションデプロイメントが作成されるほど、 stagingやqaなどの新しい環境名が必要になります。 プロジェクトがさらに大きくなると、開発者はjoes-stagingなどの独自の特別な環境を追加でき、構成の組み合わせが爆発的に増加し、アプリケーションのデプロイメントの管理が非常に脆弱になります。

12の要因の付録では、環境変数は無関係なコントロールであり、各環境変数は他の環境変数から完全に独立しています。 それらは「環境」にグループ化されることはありませんが、代わりに展開ごとに個別に管理されます。 これは、その存続期間にわたってより多くのアプリケーション展開の自然な外観に沿って徐々に拡大するモデルです。

---

IV。 サードパーティサービス（バッキングサービス）

プラグ可能なリソースとしてサードパーティのサービス（バッキングサービス）を検討する

サードパーティサービスとは、ネットワークを介してアプリケーションで使用できるサービスであり、通常の操作の一部として必要です。 たとえば、データウェアハウス（例： MySQLやCouchDB ）、メッセージキューシステム（例： RabbitMQおよびBeanstalkd ）、送信メールSMTPサービス（例： Postfix ）、キャッシュシステム（例： Memcached ）。

従来、データベースなどのサードパーティサービスは、アプリケーションを展開するシステム管理者と同じ管理者によって管理されていました。 ローカルサービスに加えて、アプリケーションはサードパーティが提供および管理するサービスを使用できます。 例には、SMTPサービス（ 消印など）、メトリックコレクションサービス（ New RelicやLogglyなど ）、バイナリデータストア（ Amazon S3など）、さまざまなサービスAPI（ Twitter 、 Google Maps、 Last.fmなど ）の使用が含まれます。 。

12の要因のアプリケーションコードは、ローカルサービスとサードパーティサービスを区別しません。 アプリケーションの場合、それらはそれぞれプラグイン可能なリソースであり、URLによって、または構成に保存されている別の場所/資格情報のペアによってアクセスできます 。 12の要因の各アプリケーションデプロイメントは 、アプリケーションコードを変更することなく、ローカルMySQLデータベースをサードパーティの管理対象データベース（ Amazon RDSなど）に置き換えることができるはずです。 同様に、コードを変更せずにローカルSMTPサーバーをサードパーティ（消印など）に置き換えることができます。 どちらの場合も、構成内のリソース識別子を変更するだけです。

異なるサードパーティサービスはそれぞれリソースです。 たとえば、MySQLデータベースはリソースであり、2つのMySQLデータベース（アプリケーションレベルでの断片化に使用）は2つの別個のリソースとして適格です。 12の要因の適用により、これらのデータベースは接続されたリソースであると見なされます。これは、それらが接続されているデプロイメントとの弱い接続を示しています。



必要に応じて、リソースを展開に接続し、展開から切断できます。 たとえば、ハードウェアの問題が原因でアプリケーションデータベースが正しく機能しない場合、管理者は最後のバックアップから復元された新しいデータベースサーバーを起動できます。 現在の作業データベースを切断し、新しいデータベースを接続することができます-これらはすべて、コードを変更することなく行われます。

---

V.アセンブリ、リリース、実装

アセンブリ段階と実行段階を厳密に分離

コードベースは 、次の3つの段階で展開に変換されます（開発用の展開は考慮されません）

• アセンブリフェーズは、コードリポジトリをアセンブリと呼ばれる実行可能パッケージに変換する変換です。 展開プロセスで指定されたバージョンのコードを使用して、ビルドフェーズはサードパーティの依存関係をロードし、バイナリファイルとアセットをコンパイルします。
• リリースフェーズは、アセンブリフェーズで取得したアセンブリを受け入れ、現在の展開構成と組み合わせます 。 結果のリリースにはアセンブリと構成が含まれ、実行時にすぐに起動する準備ができています。
• ランタイム （「ランタイム」とも呼ばれる）は、特定のリリースから特定のアプリケーションプロセスのセットを起動することにより、ランタイムでアプリケーションを起動します。

12の要因の適用では、アセンブリ、リリース、実行の各段階を厳密に分離しています。 たとえば、実行時にコードを変更することはできません。これらの変更をビルドフェーズに戻す方法がないためです。

展開ツールは、原則としてリリース管理ツールであり、重要なことに、以前のリリースにロールバックする機会を提供します。 たとえば、 Capistranoデプロイメントツールは、releasesというディレクトリのサブディレクトリにリリースを格納します。現在のリリースは、現在のリリースのディレクトリへのシンボリックリンクです。 Capistrano rollbackチームは、以前のリリースにすばやくロールバックすることを可能にします。

各リリースには、リリースタイムスタンプ（例2015-04-06-15:42:17 ）または増加する番号（例： v100 ）などの一意の識別子が必要です。 リリースは追加のみ可能で、各リリースは作成後に変更できません。 新しいリリースを作成するには、変更が必要です。

アセンブリは、新しいコードが展開されるたびにアプリケーション開発者によって開始されます。 反対に、実行フェーズの開始は、サーバーの再起動や、プロセスマネージャーによるフォールドプロセスの再起動などの場合に自動的に発生します。 したがって、実行フェーズは技術的に可能な限りシンプルにする必要があります。アプリケーションの起動を妨げる可能性のある問題は、利用可能な開発者がいない真夜中に発生する可能性があるためです。 展開を開始した開発者には考えられるエラーが常に表示されるため、ビルドフェーズはより複雑になる可能性があります。

---

VI。 プロセス

ステートレス状態を保持しない1つ以上のプロセスとしてアプリケーションを実行します

アプリケーションは、実行時に1つ以上のプロセスとして実行されます 。

最も単純な場合、コードは独立したスクリプトであり、ランタイムは言語ランタイムがインストールされた開発者のラップトップであり、プロセスはコマンドラインから起動されます（たとえば、 python my_script.pyように）。 別の極端なオプションは、必要な数のインスタンスで起動される多くのタイプのプロセスを使用できる複雑なアプリケーションの実用的な展開です。

12の要因のアプリケーションプロセスは、内部状態を保持せず（ステートレス）、 共有データを持ちません（share-nothing） 。 保存する必要のあるデータは、通常はデータベース内のステートフルなサードパーティサービスに保存する必要があります。

プロセスメモリとファイルシステムは、単一のトランザクションの一時キャッシュとして使用できます。 たとえば、大きなファイルをデータベースにロード、処理、保存します。 12の要因の適用は、メモリまたはディスクにキャッシュされたものが次のリクエストまたはタスクで利用できることを意味するものではありません-多数の多様なプロセスでは、次のリクエストが別のプロセスによって処理される可能性が高いです。 1つのプロセスが実行されている場合でも、（展開、構成の変更、またはプロセスを別の物理デバイスに転送することにより）再起動すると、すべてのローカル（メモリ、ファイルシステム）状態が破壊されます。

アセットパッカー （ Jammitやdjango-compressorなど ）は、ファイルシステムをコンパイル済みリソースのキャッシュとして使用します。 12の要因のアプリケーションは、実行時ではなく、たとえばRailsアセットパイプラインのように、 ビルドフェーズ中にこのコンパイルを行うことを好みます。

一部のWebシステムは「スティッキーセッション」に依存しています。つまり、アプリケーションプロセスメモリにユーザーセッションデータをキャッシュし、同じユーザーからの後続のリクエストが同じプロセスにリダイレクトされることを想定しています。 スティッキーセッションは12の要因に違反するため、使用したり依存したりしないでください。 ユーザーセッションデータは、 MemcachedやRedisなど、ストレージ時間を制限する機能を提供するデータウェアハウスの良い候補です。

---

VII。 ポートバインディング

ポートバインドによるサービスのエクスポート

WebアプリケーションはWebサーバーコンテナ内で実行される場合があります。 たとえば、PHPアプリケーションはApache HTTPD内のモジュールとして起動でき、JavaアプリケーションはTomcat内で起動できます。

12要素アプリケーションは完全に自己完結型であり、Webサービスを作成するために実行時にWebサーバーを挿入する必要はありません。 Webアプリケーションは、ポートにバインドしてHTTPサービスをエクスポートし、そのポートに到着する要求をリッスンします。

ローカル開発中に、開発者はフォームのURLに移動します localhost:5000/ localhost:5000/彼のアプリケーションが提供するサービスにアクセスします。 デプロイされると、ルーティングレイヤーはパブリックホストへのリクエストを処理し、それらをポートバウンドWebアプリケーションにリダイレクトします。

これは通常、依存関係宣言を使用して 、PythonのTornado 、RubyのThin 、Javaおよびその他のJVMベースの言語のJettyなどのアプリケーションにWebサーバーライブラリを追加することによって行われます。 これは、 ユーザー空間 、つまりアプリケーションコードで完全に発生します。 ランタイムとの契約は、要求を処理するためにアプリケーションをポートにバインドすることです。

ポートバインディングを介してエクスポートできるサービスはHTTPだけではありません。 ほとんどすべてのタイプのサーバーソフトウェアは、ポートにバインドされ、着信要求を待機するプロセスとして実行できます。 この例には、 ejabberd （ XMPPプロトコルを提供）およびRedis （ Redisプロトコルを提供）が含まれます。

また、ポートバインドアプローチは、消費アプリケーションの構成でサードパーティアプリケーションのURLをリソース識別子として提供することにより、1つのアプリケーションが別のアプリケーションのサードパーティサービスとして機能できることにも注意してください。

---

Viii。 並行性

プロセスでアプリケーションをスケーリングする

起動後のコンピュータープログラムは、1つ以上の作業プロセスです。 歴史的に、Webアプリケーションはさまざまな形式のプロセス実行を行ってきました。 たとえば、PHPプロセスはApache子プロセスとして実行され、着信要求を処理するのに必要な量でオンデマンドで実行されます。 Javaプロセスは反対のアプローチを使用します。JVMは、起動時に大量のシステムリソース（プロセッサとメモリ）を予約し、スレッドを使用して内部の並列処理を管理する単一のモノリシックメタプロセスです。 どちらの場合も、実行中のプロセスはアプリケーション開発者に最小限しか見えません。



12の要因の付録では、プロセスは一流のエンティティです。 12個の要素を適用するプロセスは、 デーモンを実行するためのUNIXプロセスモデルから強みを取りました。 このモデルを使用すると、開発者はさまざまなワークロードを処理するために、各タイプの作業に独自のタイプのプロセスを割り当てる必要があるようにアプリケーションを設計できます 。 たとえば、HTTP要求はWebプロセスで処理でき、長いバックグラウンドタスクはワークフローで処理されます。

これは、次のようなツールで仮想マシンまたは非同期/イベントモデルの実装を流れる内部多重個々のプロセスを使用する可能性を排除するものではないEventMachine、ツイストとのNode.js。ただし、個々の仮想マシンは限られた範囲でしかスケーリングできないため（垂直スケーリング）、アプリケーションは異なる物理マシンで複数のプロセスとして実行できる必要があります。

プロセスベースのモデルは、スケーリングに関しては本当に輝いています。共有データの欠如と12の要因のアプリケーションプロセスの水平分離同時実行性の追加は、シンプルで信頼性の高い操作です。さまざまなタイプのプロセスの配列と各タイプのプロセスの数は、プロセス形成と呼ばれます。

12要素のアプリケーションプロセスを悪魔化してPIDファイルを作成することはできません。代わりに、オペレーティングシステムのプロセスマネージャー（Upstart、クラウドプラットフォーム上の分散プロセスマネージャー、開発中のForemanなどのツール）に依存して、出力ストリームを管理し、プロセスのクラッシュに対応し、ユーザーが開始した再起動またはシャットダウンを処理する必要があります。

---

IX。使い捨て

クイックスタートと正しいシャットダウンで信頼性を最大化

12の要因の適用プロセスは1回限りです。つまり、現時点では誰でも開始および停止できます。これは、安定した柔軟なスケーリング、コードの変更と構成の迅速な展開、および運用展開の信頼性に貢献します。

プロセスは、起動時間を最小限に抑えるようにする必要があります。理想的には、プロセスは、開始コマンドが実行された時点から、プロセスが開始されて要求またはタスクを受け入れる準備が整うまで、数秒しか費やすべきではありません。起動時間が短いため、リリースの柔軟性が向上しますおよびスケーリング。さらに、プロセスマネージャーは必要に応じてプロセスを新しい物理マシンに自由に移動できるため、より信頼性が高くなります。

プロセスは、プロセスマネージャからSIGTERMシグナルを受信したときに正しく終了する必要があります。 Webプロセスの場合、サービスポートのリッスンを停止する（つまり、新しい要求を拒否する）ことで正しいシャットダウンが実現されます。これにより、現在の要求を完了してから完了できます。このモデルは、HTTPリクエストが短い（数秒以内）と想定しています。長いリクエストの場合、クライアントは接続が失われたときにスムーズに再接続を試みる必要があります。

バックグラウンドタスク（ワーカー）を実行するプロセスの場合、現在のタスクをタスクキューに戻すことにより、正しいシャットダウンが実現されます。たとえば、RabbitMQでは、ワークフローがコマンドを送信する場合がありますNACK;中Beanstalkdのワークフローが無効になって自動的にキューにタスク戻ります。タスクのロックを解除するには、遅延ジョブなどのロックベースのシステムに通知する必要があります。このモデルは、すべてのタスクがリエントラントであることを前提としています。これは通常、トランザクションの作業結果をラップするか、べき等演算を使用することによって実現されます。

プロセスもハードウェア障害の場合の突然死に対する抵抗力。これは、シグナルの正しい完了よりも起こりそうにないイベントですが、SIGTERMそれでも発生する可能性があります。推奨されるアプローチは、Beanstalkdなどの信頼できるタスクキューを使用することです。これは、クライアントが切断するか、時間制限を超えたときにキューにタスクを返します。いずれにせよ、予期しない正常なシャットダウンを処理するために、12の要因のアプリケーションを設計する必要があります。クラッシュのみの設計アーキテクチャは、この概念を論理的な結論に導きます。

---

X.アプリケーション開発/作業パリティ

開発環境、ステージング環境、および本番環境を可能な限り同様に保ちます。

歴史的に、開発（開発者がアプリケーションのローカルデプロイメントでライブ変更を行う）とアプリケーションの動作（エンドユーザーがアクセスできるアプリケーションのデプロイメント）には大きな違いがあります。これらの違いは、次の3つの領域に現れます。

• 時差：開発者は、数日、数週間、さらには数か月でのみアプリケーションの作業バージョンに入るコードを操作できます。
• 人員の区別：開発者がコードを記述し、OPSエンジニアがそれを展開します。
• ツールの違い：開発者はNginx、SQLite、OS Xなどの技術のスタックを使用できますが、Apache、MySQL、およびLinuxは実稼働展開に使用されます。

12要素アプリケーションは、アプリケーションの開発と運用の違いを最小限に抑えることにより、継続的な展開のために設計されています。上記の3つの違いを考慮してください。

• 時間差を小さくします。開発者はコードを記述でき、数時間または数分で展開されます。
• スタッフの違いを小さくします。コードを記述した開発者は、積極的に展開に参加し、アプリケーションの実行中にその動作を監視します。
• ツールの違いを小さくする：アプリケーションの開発環境と作業環境を可能な限り同じにします。

上記を表に要約します。

	従来のアプリケーション	付録12の要因
展開間隔	週間	時計
コードの作成者/デプロイする人	異なる人々	同じ人
アプリケーション開発/作業環境	いろいろ	できるだけ似ている

データベース、メッセージキューシステム、キャッシュなどのサードパーティサービスは、アプリケーションの開発および実行時にパリティが重要な領域の1つです。多くの言語は、さまざまなタイプのサービスにアクセスするためのアダプターを含む、サードパーティのサービスへのアクセスを簡素化するライブラリを提供します。いくつかの例を以下の表に示します。

種類	言語	図書館	アダプター
データベース	Ruby / Rails	アクティブレコード	MySQL、PostgreSQL、SQLite
メッセージキュー	Python / Django	セロリ	RabbitMQ、Beanstalkd、Redis
キャッシュ	Ruby / Rails	ActiveSupport ::キャッシュ	メモリ、ファイルシステム、Memcached

開発者は、ローカル環境で軽量のサードパーティサービスを使用すると便利な場合がありますが、作業環境ではより深刻で信頼性の高いサードパーティサービスが使用されます。たとえば、作業環境ではSQLiteをローカルで使用し、PostgreSQLを使用します。または、開発中にキャッシュ用のメモリを処理し、作業環境でMemcachedします。

12要素のアプリケーション開発者は、開発および作業環境でさまざまなサードパーティサービスを使用する誘惑に抵抗する必要があります。、アダプタが理論的にサードパーティのサービスの違いから抽象化されている場合でも。使用されるサードパーティサービスの違いは、わずかな非互換性が存在する可能性があることを意味します。これにより、開発および中間展開中に機能し、テストに合格したコードが作業環境で機能しなくなります。このタイプのエラーは、継続的な展開の利点を相殺する干渉を作成します。この干渉とそれに続く継続的な展開の復元のコストは、アプリケーションの寿命全体で合計すると考えると非常に高くなります。

ローカルサービスのインストールは、かつてないほど魅力的なタスクになりました。 Memcached、PostgreSQL、RabbitMQなどの最新のサードパーティサービスは、Homebrewやapt-getなどの最新のパッケージマネージャーのおかげで、インストールや実行が難しくありません。さらに、ChefやPuppetなどの宣言型環境準備ツールとVagrantなどの軽量仮想環境を組み合わせることで、開発者は作業環境に可能な限り近いローカル環境を実行できます。これらのシステムをインストールして使用するコストは、アプリケーションの開発/運用パリティと継続的な展開から得られる利点と比較して低くなります。

さまざまなサードパーティサービス用のアダプタは、比較的簡単に新しいサードパーティサービスを使用するようにアプリケーションを移植できるため、依然として有用です。ただし、すべてのアプリケーションデプロイメント（開発者環境、中間デプロイメントおよび作業デプロイメント）は、各サードパーティサービスの同じタイプと同じバージョンを使用する必要があります。

---

Xi。ロギング

ログをイベントストリームと考える

ロギングは、実行中のアプリケーションの動作を視覚的に表現します。通常、サーバー環境では、ログはディスクファイル（「logfile」）に書き込まれますが、これは出力形式の1つにすぎません。

ログは、実行中のすべてのプロセスと補助サービスの出力ストリームから収集された、時間順に集約されたイベントのストリームです。未加工の形式のジャーナルは、通常、1行に1イベントのテキスト形式で表示されます（ただし、例外トレースは複数行にまたがることがあります）。ログの開始と終了は固定されておらず、アプリケーションの実行中はメッセージフローが継続します。

12の要因のアプリケーションは、出力ストリームをルーティングおよび保存することはありません。アプリケーションは、ログをファイルに書き込み、ログファイルを管理するべきではありません。代わりに、実行中の各プロセスは、標準出力にバッファリングせずにイベントのストリームを書き込みますstdout。ローカル開発中に、開発者は端末でこのスレッドを表示して、アプリケーションの動作を観察することができます。

中間および実稼働デプロイメントでは、各プロセスの出力ストリームがランタイムによってキャプチャされ、他のすべてのアプリケーション出力ストリームとアセンブルされ、表示および長期アーカイブのために1つ以上の最終的な宛先にリダイレクトされます。これらのアーカイブエンドポイントは、アプリケーションからは見えず、アプリケーションによってカスタマイズ可能ですが、代わりにランタイムによって完全に制御されます。オープンソースのログルーター（例：LogplexおよびFluent）は、この目的に使用できます。

アプリケーションイベントストリームは、ファイルにリダイレクトしたり、リアルタイムで端末で表示したりできます。最も重要なことは、イベントのフローをSplunkなどのインデックス作成およびログ分析システム、またはHadoop / Hiveなどの汎用ストレージシステムに向けることができることです。これらのシステムは、次のようなアプリケーションの動作を長期にわたって徹底的に分析するための優れた機能と柔軟性を備えています。

• 過去の特定のイベントを検索します。
• 大規模な傾向グラフ（1分あたりのリクエストなど）。
• ユーザーが定義したヒューリスティックルールに基づくアクティブなアラート（たとえば、1分あたりのエラー数が特定のしきい値を超えた場合のアラート）。

---

XII。管理タスク

ワンタイムプロセスを使用して管理/管理タスクを実行する

プロセスシェーピングは、アプリケーションの実行時にアプリケーションの通常のタスク（Web要求の処理など）を実行するために必要な一連のプロセスです。これに加えて、開発者は次のようなアプリケーションの1回限りの管理および保守タスクを定期的に実行する必要があります。

• データベースの移行を開始します（たとえば、manage.py migrateDjango、rake db:migrateRails）。
• ( REPL ), . REPL - (, python or perl ), ( irb Ruby, rails console Rails).
• , (, php scripts/fix_bad_records.php ).

1回限りの管理プロセスは、通常の長期実行アプリケーションプロセスと同一の環境で実行する必要があります。これらは、このリリースを実行する他のプロセスと同じコードベースと構成を使用して、リリースレベルで起動されます。同期の問題を回避するには、管理コードにアプリケーションコードを提供する必要があります。すべてのタイプのプロセスに同じ依存関係分離メソッドを使用する必要があります。たとえば、Ruby Webプロセスがコマンドを使用する場合、データベースを使用して移行する必要があります。同様に、Virtualenvを使用するPythonプログラムの場合は、提供されている

bundle exec thin startbundle exec rake db:migratebin/pythonTornado Webサーバーを起動し、manage.py管理プロセスを開始します。

12要素の方法論では、すぐに使えるREPLラッパーを提供し、1回限りのスクリプトを簡単に実行できる言語を好みます。ローカル展開では、開発者はアプリケーションディレクトリ内のコンソールコマンドを使用して1回限りの管理プロセスを実行します。実稼働デプロイメントでは、開発者はsshまたはランタイムが提供する別のリモートコマンド実行メカニズムを使用して、このようなプロセスを開始できます。

---

バグ修正とより適切な翻訳を送信できます。

• ここにコメント
• プライベートメッセージ
• 上のプルrekvest GitHubの
• ( )

amalinin litchristina