Skip to content

Instantly share code, notes, and snippets.

@corrupt952

corrupt952/the-twelve-factor-app-checlist.md

Created August 7, 2019 02:20
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save corrupt952/e6cbc62fb90349ec4e3cdd32fdbc82a5 to your computer and use it in GitHub Desktop.
Save corrupt952/e6cbc62fb90349ec4e3cdd32fdbc82a5 to your computer and use it in GitHub Desktop.
Download ZIP
Containerization checklist
Raw
the-twelve-factor-app-checlist.md

The Twelve-Factor App checklist

これはアプリケーションをコンテナ化するために必要な項目のチェックリストである.

Codebase

  • Codebaseとアプリケーションは1対1であること
    • アプリケーション≠サービス
    • 複数のCodebaseから1つのアプリケーションが作られる場合はパイプラインが複雑になってしまうため
    • Configが異なる環境が複数あるのはアプリケーションが複数あるのではなく、デプロイが複数あると解釈する
  • 1つのCodebaseから複数の環境で実行可能な状態であること
    • ただし環境ごとに異なる設定についてはここでは触れない

Dependencies

システム側にインストールされるパッケージのことを、便宜上Site packagesと呼ぶ. また、システム側にインストールされないGemなどのパッケージのことを、便宜上Vendoringと呼ぶ.

  • アプリケーションの実行に必要なSite packagesは、開発・テスト・ステージング・本番で利用される共通コンテナイメージでインストールしていること
    • libmysql-clientやimagemagickなどのパッケージのこと
  • アプリケーションから外部コマンドを実行しないこと
    • Rubyの場合、systemメソッドなどで外部コマンドを実行するのが該当する
  • アプリケーションの実行に必要なVendoringは、Gemfileなどのファイルに定義していること
  • アプリケーションの実行に必要なVendoringは、ステージング・本番向けのコンテナイメージにはインストールしていること

Config

Configは

  • データベースなどのバックエンドサービスへの接続情報
  • AWSやTwitterなどの外部サービスの認証情報
  • ホスト名や環境ごとに異なる値

のようなものを指す.

  • 環境によって異なる設定ファイルを定義しないこと
    • Frameworkなどが提供する設定ファイル（config/environments/test.rbなど）は対象外とする
  • 環境によって異なる設定値は環境変数で上書き可能な状態であること
  • 認証情報などのセンシティブな設定値はCodebaseに含めないこと
    • 「開発・テストでしか使わない情報」かつ「ステージング・本番で使う情報と異なる」場合はCodebaseに含めても良い

Backing services

Backing servicesは、アプリケーションがネットワーク越しに利用する全てのサービスやアプリケーションを指す.

  • 環境によって異なる接続先であっても、Codebaseを変更せず環境変数の変更のみで切替えられること

Build, Release, Run

  • デプロイメントパイプラインは、Build, Relase, Runの3つのステージに分離していること
    • Build ... アプリケーションが実行可能なコンテナイメージにビルドされること
    • Release ... コンテナイメージをRegistryにアップロードし、k8sのManifestやECSのTask Definitionが生成していること
    • Run ... Releaseで生成されたManifestなどを元にアプリケーションが実行されること
  • 全てのReleaseは一意のIDから特定できること
    • 連番やタイムスタンプなど一意に特定できれば良い

Processes

  • アプリケーションはステートレスであること
    • 例）セッション情報をオンメモリに保存しない
  • アプリケーションが何らかのステートを持つ場合は、ステートフルなBacking servicesに保存していること

Port binding

  • アプリケーションは単体でポートを公開し、サービスとして動作すること
    • RubyであればUnicornやPumaなどのアプリケーションサーバでUnix Domain Socketではなく、ポートで動作させることが例となる

Concurrency

  • 水平スケール可能なアプリケーションになっていること
    • Processesが守られていればこちらも守られているといえる

Disposability

  • SIGTERMシグナルが送られたプロセスはグレースフルに終了すること
    • Webプロセスの場合は、新規にリクエストを受け付けず、決められた時間内にレスポンスを返すこと
    • Workerプロセスの場合は、決められた時間内にジョブを完了させるか、ジョブのロックを解除し終了すること

Dev/prod parity

  • 開発・ステージング・本番で動作する環境はできる限り同一であること
    • できる限りはチーム内で合意を取り進める
  • アプリケーション開発者がステージング・本番環境へデプロイ可能であること

Logs

  • ログ収集の仕組みに乗せないログは、stdout,stderrに出力していること
  • ログ収集の仕組みに乗せるログは、チームで合意をとった方法で出力していること

Admin processes

Ruby on Railsならrails db:migrateがAdmin processesに該当する.

  • 一度のみ実行されるようなAdmin processesはデプロイパイプラインに組み込まれていること
  • Admin processesで実行されるスクリプトやコードは、アプリケーションと同じコードベースで管理していること
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment