Applications made with Twelve-Factor-App

@koudaiii

Profile

id: koudaiii fullname: Kodai Sakabe

• https://speakerdeck.com/takai/continuous-delivery-in-cookpad

• https://speakerdeck.com/takai/continuous-delivery-in-cookpad

継続的にデリバリーできる 仕組みって？

Twelve-Factor AppWebApplication、SaaSを作り上げるための方法論

• http://twelve-factor-ja.herokuapp.com/

Twelve-Factor Appって？• 寄稿者が何百何千ものアプリケーションの開発・運用・スケールを経験してきた知見であり方法論

• Herokuプラットフォーム上を前提としている

方法論• セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。

• 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。

• モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。

• 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。

• ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。

1. コードベース (Codebase)

2. 依存関係 (Dependencies)

3. 設定 (Config)

4. バックエンドサービス (Backing Services)

5. ビルド、リリース、実行 (Build, release, run)

6. プロセス (Processes)

7. ポートバインディング (Port binding)

8. 並行性 (Concurrency)

9. 廃棄容易性 (Disposability)

10.開発/本番一致 (Dev/prod parity)

11.ログ (Logs)

12.管理プロセス (Admin processes)

CodeBase

• バージョン管理されている1つのコードベースと複数のデプロイ

• Git,SVN等

• 常に1対1の関係

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

• CPANやRubyGem等。~env系のツール

• すべての依存関係を 依存関係宣言 マニフェストで完全かつ厳密に宣言する(Gemfile)

• 宣言したものを利用する(bundle exec)

Config• 設定を環境変数に格納する

• アプリケーションの 設定 は、デプロイ（ステージング、本番、開発環境など）の間で異なり得る唯一のもの

• 設定をコードから厳密に分離すること

• 環境変数に格納(qt)または、dotenv等(database)を用いる

Backing Services• バックエンドサービスをアタッチされたリソースとして扱う

• Twelve-Factor Appのデプロイは、

• アプリケーションのコードに変更を加えることなく、

• ローカルで管理されるMySQLデータベースをサードパーティに管理されるサービス（Amazon RDSなど）に切り替えることができるべき

Backing Services(続き• リソースは自由にデプロイにアタッチしたり、デプロイからデタッチしたりできる。

• ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、

• アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げる。

• そして現在の本番データベースをデタッチし、

• 新しいデータベースをアタッチする-コードを一切変更せずに。

Backing Services(続き

Build, release, run• ビルド、リリース、実行の3つのステージを厳密に分離する。

Capistrano等

• releasesという名前のサブディレクトリに格納し、

• 現在のリリースは現在のリリースのディレクトリへのシンボリックリンクとなる。

• Capistranoのrollbackコマンドを使うと、簡単かつ即座に以前のリリースにロールバック

• 今だとBule-Green deployment

Processes• アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

• プロセスはステートレスかつシェアードナッシング である。

• 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービス（典型的にはデータベース）に格納しなければならない。

Port binding• ポートバインディングを通してサービスを公開する

• WebアプリケーションはWebサーバーコンテナの内部で実行されることがある。

• Twelve-Factor Appは完全に自己完結 し、Webに公開されるサービスを作成するために、コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。

• Webアプリケーションは ポートにバインドすることでHTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。

• APPとWebはPort間でつなげ独立させる

Concurrency• プロセスモデルによってスケールアウトする

Concurrency(続き• プロセスは決してデーモン化するべきではないし、PIDファイルを書き出すべきではない。

• その代わりに、OSのプロセスマネージャー（例：Upstart、クラウドプラットフォームの分散プロセスマネージャー、あるいは開発環境におけるForemanのようなツール）を頼ることで、

• 出力ストリームを管理し、プロセスのクラッシュに対応し、ユーザーによる再起動やシャットダウンを処理すべき

Disposability• 高速な起動とグレースフルシャットダウンで堅牢性を最大化する

• プロセス は 廃棄容易 であり即座に起動・終了することができる。

• この性質が、素早く柔軟なスケールと、コード や 設定 に対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を高める

Dev/prod parity• 開発、ステージング、本番環境をできるだけ一致させた状態を保つ

• 3つのギャップをなくす

• 時間のギャップ・・コードが本番に反映される時間

• 人材のギャップ・・リリースは運用担当者

• ツールのギャップ・・開発と本番のMiddlewareが違う

Dev/prod parity(続き• 継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ

• 開発者が書いたコードは数時間後、さらには数分後にはデプロイされる

• コードを書いた開発者はそのコードのデプロイに深く関わり、そのコードの本番環境での挙動をモニタリングする。

• 開発環境と本番環境をできるだけ一致させた状態を保つ。

Logs• ログをイベントストリームとして扱う

• ログは、すべての実行中のプロセスとバックエンドサービスの出力ストリームから収集されたイベントが、集約されて時刻順に並べられたストリームである。

• 生の状態のログは、通常1行が1つのイベントを表すテキストフォーマットである

Logs(続き• FluentdやSplunk,BigQuery等を組み合わせで以下の利点

• 過去の特定のイベントを見つける。

• 大きなスケールの傾向をグラフ化する。（1分あたりのリクエスト数など）

• ユーザー定義のヒューリスティクスに基づいて素早くアラートを出す。（1分あたりのエラー数がある閾値を超えた場合にアラートを出すなど）

Admin processes• 管理タスク(マイグレーション等)を1回限りのプロセスとして実行

• 1回限りの管理プロセスは、アプリケーションの通常の長時間実行されるプロセスと全く同じ環境で実行されるべき

• これらのプロセスは、あるリリースに対して実行され、そのリリースに対して実行されるすべてのプロセスと同じコードと設定を使う。

• デプロイ時に一緒にされるべきである。(db:migrate等)

1. コードベース (Codebase)

2. 依存関係 (Dependencies)

3. 設定 (Config)

4. バックエンドサービス (Backing Services)

5. ビルド、リリース、実行 (Build, release, run)

6. プロセス (Processes)

7. ポートバインディング (Port binding)

8. 並行性 (Concurrency)

9. 廃棄容易性 (Disposability)

10.開発/本番一致 (Dev/prod parity)

11.ログ (Logs)

12.管理プロセス (Admin processes)

CodeBase

Dependencies

Config

Disposabilityproviderを変えることで違う環境へ構築。または、

bundle exec knife solo bootstrap webapp等

Dev/prod parity同じBuild STEPで同じMiddleware。同じVagrantfile。

Continuous Integration

初期構築 ６ヶ月　⇒　30m

学習コスト 役割毎に分割

プロビジョニングログ 実機による確認

上記から変に１から学ぶ必要がない

はまった作業は Commitメッセージ&コメント

commitにより、設定情報だけではなく、

なんのためにcommitしたかを追えるTagにより、アークテクチャーのバージョン管理

!!

リリース作業 bundle exec cap production deploy

環境を選ばない bundle exec knife solo bootstrap YourServer

ubuntu & CentOSの確認

bundle exec kitchen test

テスト済みのインフラ基盤 bundle exec rake spec

Continuous delivery

Next Step Blue-Green Deployment!

ChatOps!

Reference• http://twelve-factor-ja.herokuapp.com/

• twelve-factor-app

• https://speakerdeck.com/takai/continuous-delivery-in-cookpad

• continuous-delivery-in-cookpad

• http://www.atmarkit.co.jp/ait/articles/1312/03/news033.html

• 継続的デリバリ／デプロイを実現する手法・ツールまとめ

• http://easyramble.com/warn-missing-cookbook-dependency.html

• WARN: MissingCookbookDependencyとChefで警告が出る場合の対処

• http://qiita.com/cazador/items/e0db714555f2f36d98c6

• 大規模にchefを使い倒すためのcookbook pattern

• 書籍「入門Chef Solo - Infrastructure as Code」「Vagrant入門ガイド」「Chef活用ガイド　コードではじめる構成管理」「Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) 」