Application Design for Docker and Kubernetes

Transcript

1. Docker / Kuberentes を 活かすアプリ設計のポイント THE TWELEVE-FACTOR APP と Kubernetesの使い方 with IBM 2018年10月3日 日本アイ・ビー・エム株式会社 クラウド事業本部 高良 真穂
2. © IBM Corporation 2 コンテナは 本番運用 に使えるか？
3. © IBM Corporation 3 データ命なのに コンテナには 永続性が無い
4. © IBM Corporation 4 コンテナは使捨て!? ならばアプリ保守は どうする？
5. © IBM Corporation 5 データの バックアップ
6. © IBM Corporation 6 データの バックアップ
7. © IBM Corporation 7 データの バックアップ
8. © IBM Corporation 8 データの バックアップ アプリの モジュール 入れ替え
9. © IBM Corporation 9 データの バックアップ アプリの モジュール 入れ替え
10. © IBM Corporation 10 使えないと思える材料は… △•×＃☆жЯ…
11. © IBM Corporation 11 コンテナの有効活用するには 発想の転換が必要です
12. 発想転換を提唱したのが 12Factor App
13. © IBM Corporation 13 12 Factor とは – Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための 方法論 https://12factor.net/ja/ – Herokuの創業メンバー Adam Wiggins によって書かれ、多くのSWエンジニア から支持されている。
14. © IBM Corporation 14 12 Factor とは –I. コードベース • バージョン管理されている1つのコードベースと複数のデプロイ –II. 依存関係 • 依存関係を明示的に宣言し分離する –III. 設定 • 設定を環境変数に格納する –IV. バックエンドサービス • バックエンドサービスをアタッチされたリソースとして扱う –V. ビルド、リリース、実行 • ビルド、リリース、実行の3つのステージを厳密に分離する –VI. プロセス • アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
15. © IBM Corporation 15 12 Factor とは –VII. ポートバインディング • ポートバインディングを通してサービスを公開する –VIII. 並行性 • プロセスモデルによってスケールアウトする –IX. 廃棄容易性 • 高速な起動とグレースフルシャットダウンで堅牢性を最大化する –X. 開発/本番一致 • 開発、ステージング、本番環境をできるだけ一致させた状態を保つ –XI. ログ • ログをイベントストリームとして扱う –XII. 管理プロセス • 管理タスクを1回限りのプロセスとして実行する
16. © IBM Corporation 16 1. コードベース – 一つのコードベースから、複数のデプロイを作る • コードベースとは、GitやSubversionなどのコードのバージョン管理ツール • デプロイは、開発者のPCでの実行、テスト環境、本番環境などで実行されるアプリのインスタンス – K8sでは • レジストリに、アプリの実行形式とそれが依存するOSやライブラリを含んだコンテナを登録 • レジストリに登録されたコンテナから、各環境へデプロイする コードベース コンテナ・リポジトリ 開発者#1 開発者#2 テスト環境 本番環境 デプロイ 依存ソフトウェア OSS ライブラリ 依存 コード Linux配布 コンテナ アプリ
17. © IBM Corporation 17 補足 レジストリとリポジトリの関係 – レジストリとリポジトリ コンテナ・レジストリ リポジトリ-A リポジトリ-B リポジトリ-C タグ-1 タグ-2 タグ-3 ・ ・ ・ ・ ・ ・ コンテナ#1 レジストリ名／リポジトリ名：タグ コンテナ#2 コンテナ#3 アプリ ver 1.0 アプリ ver 1.1 アプリ ver 1.2 アプリ名
18. © IBM Corporation 18 2. 依存関係 – 依存関係を明示的に宣言し分離する • OSとそのパッケージを含めたすべての依存関係を 依存関係宣言 マニフェストで完全かつ厳密に宣言 • 依存関係分離 ツール(vituralenv,pip,gemなど)を使って、暗黙の依存関係が“漏れ出ない”ことを保証 • この指定は、本番環境と開発環境の両方に対して同様に適用される。 – Dockerfileに依存関係分離ツールの実行を記述することで、アプリが依存する全てのパッケージ をコンテナへインストールする コードベース コンテナ・レジストリ 依存ソフトウェア、OS OSS ライブラリ 依存 コード Linux配布 コンテナ アプリ コンテナ Dockerfile アプリ
19. © IBM Corporation 19 3. 設定 設定を環境変数に格納する – アプリ設定 は、デプロイ（ステージング、本番、開発環境など）の間で異なり得る唯一のモノとする。 – 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる。設定ファイルとは異なり、誤ってリポジトリにチェックインされる可能性はほとんどない。 – K8sは、次の環境への保存方法と、環境からの情報取得方法を提供する • ConfigMap 設定ファイルをk8sのネームスペースに保存する • Secret ユーザーID/パスワード、証明書など資格情報を、他者に見られない様にk8sのネームスペースに保存する • Service k8sサービスとしてデプロイすることで、それ以降のポッドの環境変数で、エンドポイントを環境変数で参照可能 • ポッド・テンプレート ConfigMapやSecretの情報を、コンテナの環境変数、または、ボリュームとしてマウントして参照可能 資格情報 設定 ファイル 資格情報 設定 ファイル 本番用 テスト用 本番用ネームスペース テスト用ネームスペース アプリ コンテナ アプリ コンテナ サービス サービス K8s クラスタ
20. © IBM Corporation 20 他アプリ コンテナ 他アプリ コンテナ 4. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う – バックエンドサービス はアプリが通常の動作の中でネットワーク越しに利用するすべてのサービスを言う。 – 例としては、データストア（例：MySQL や CouchDB）、メッセージキューイングシステム（例：RabbitMQ や Beanstalkd）、電子メールを送信するためのSMTPサービス（例：Postfix）、キャッシュシステム（例：Memcached） などがある。 • k8sサービスの機能は、サービスを抽象化することで、外部サービスと内部サービスを同等にアクセスできる。 – 内部サービスを作成する場合、サービスタイプをClusterIP 設定して、対応するポッドと一致するセレクタを設定 – 外部サービスを参照する場合、サービスタイプにExternalNameを設定して、外部サービスのIPやポートを設定 アプリ コンテナ サービス-A サービス-B 他アプリ コンテナ DBaaS 内部サービス 外部サービス サービスは抽象化され 内部外部を区別しない アプリ部品など マイクロサービス データーベース マネージドサービス
21. © IBM Corporation 21 5. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する – ビルド: アプリコードと依存をまとめて、コンテナをビルドする – リリース： 設定ファイル、資格情報を環境に登録、マニフェストをk8sクラスタへ適用 – 実行： ◯◯環境でアプリを実行 アプリ コンテナ ビルド リリース 資格情報 設定 ファイル ◯◯環境 ◯◯環境ネームスペース アプリ コンテナ サービス K8s クラスタ レジストリ 依存ソフトウェア OSS ライブラリ 依存 コード Linux配布 コンテナ コードベース アプリ 実行
22. © IBM Corporation 22 6. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する • ステートレスとは、ウェブサーバーの様に、一回毎のリクエストとレスポンスだけで処理が継続する 事を意味しています。つまり、ロードバランサーのステイッキーセッションなどの機能を使って、 セッションを確立したコンテナへ固定的に振り向ける事は、コンテナ上のアプリがセッションの状態 を持つことになり、12Factor に違反することになります。 • セッションの情報は、外にあるキャッシュ・サービスなどを利用して、アプリ・コンテナの突然の停 止に備える必要があります。 • リクエストを受けてから応答する間の一時的なメモリ上のデータは対象外です。 DBサービス 永続ボリューム キャッシュ・サービス アプリ コンテナ ・ ・ ・ アプリ コンテナ アプリ コンテナ どのアプリ・コンテナにリクエストが アサインされても、同じ応答ができる
23. © IBM Corporation 23 7. ポートバインディング ポートバインディングを通してサービスを公開する • Webアプリとして、PHP、Python、Rubyなどプログラミング言語のフレームワーク等のサーバーポートをバ インドして、サービスを公開することを勧めており、公開のためにHTTPサーバーの利用を推奨していません。 • K8sでは、アプリのポートを公開するために、Nginx等のHTTPサーバーのコンテナと組み合わせ事もでき、次 の機能によってコンテナのポート番号を公開用ポート番号に対応づける事ができる。 – NodePort ポートフォワーディングと負荷分散 – Ingress URL変換、TLS暗号化、負荷分散等 アプリ コンテナ ポッド アプリ コンテナ ポッド 内部(ポッド)ネットワーク Ingress or NodePort 外部ネットワーク クライアント 公開用 ポート コンテナ ポート コンテナ ポート
24. © IBM Corporation 24 8. 並行性 プロセスモデルによってスケールアウトする • 個々のワークロードの種類を プロセスタイプ に割り当てることで、開発者はアプリケーションが多様なワーク ロードを扱えるように設計する • スケールアウトが必要になったときである。シェアードナッシングで水平分割可能なTwelve-Factor Appプロセ スの性質は、並行性を高める操作が単純かつ確実なものである フロントエンド ポッド バックエンド ポッド バッチ処理 ポッド フロントエンド ポッド フロントエンド ポッド バックエンド ポッド フロントエンド ポッド ワークロードの種類でプロセスを別ける （ワークロードの多様性） 処理能力の増減は、 並列数を増減させ る事で対応する ポッドレプリカ数 CPU、メモリ 資源量
25. © IBM Corporation 25 9. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する • コンテナの起動時間を最小化する努力は常に必要です。この素早い起動は、設定条件の変更、 ハード障害からの回復、ワークロードの急増に迅速に対応するためです。 • 終了要求シグナル（SIGTERM）を受け取ると、速やかに終了処理を実行して、プロセスを終了 することを推奨しています。 ◯◯環境ネームスペース アプリ コンテナ K8s クラスタ レジストリ コンテナのサイズが大きいと レジストリからダウンロードが 長くなり、起動に時間がかかる SIGTERM 経過時間 SIGKILL 終了処理 SIGTERMの処理が 実装されたコンテナ SIGTERMの考慮 が無いコンテナ t1 t2 t1 < t2
26. © IBM Corporation 26 10. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ • 開発者が書いたコードは、出来るだけ早くデプロイする。 • コードを書いた開発者は、デプロイ作業に関わり、その後、モニタリングする。 • 開発環境と本番環境をできだけ一致した状態に保つ K8sクラスタをネームスペースで分割して、同じハードウェア環境上で、影響なく、開発〜本番環境を共存す る事ができる。 ネームスペースで実現できる分割 – CPUとメモリの利用上限、ネットワークのアクセス範囲 – kubectlコマンドの有効範囲 – RBACベースのサービスアカウントにより、開発者やSREのアクセス範囲を限定 本番用ネームスペース ST用ネームスペース アプリ コンテナ サービス アプリ コンテナ サービス IT用ネームスペース アプリ コンテナ サービス K8s クラスタ
27. © IBM Corporation 27 K8s クラスタ 11. ログ ログをイベントストリームとして扱う – アプリケーションはログファイルに書き込んだり、ログをローテション管理しない。 – それぞれの実行中のコンテナは、イベントストリームを標準出力にバッファリングせずに書きだす – ローカルでの開発中、このストリームをターミナルで見ることで、アプリケーションのデバッグを実施 K8sではコンテナから標準出力に書き出されるイベントストレームは、Fluentd/Logstashで転送さ れElasticSearchに集約される。 Kibanaを利用して、ポッドやコンテナ横断的に、イベントの発生 状況を把握できる。 アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ Elastic Search Kibana コンテナのログは、STDOUTヘ出力 K8sクラスタのログ機能と してELKスタックが採用 Prometheus Grafana ログ分析 メトリックス 分析
28. © IBM Corporation 28 12. 管理プロセス 管理タスクを1回限りのプロセスとして実行する • アプリケーションのメンテナンスのための一回限りの処理の管理用コードは、 – 同じアプリケーションのコンテナ内で実行されるべき – 同じGitリポジトリ等に含まれるべき – アプリと同じコミットの世代が利用できる様に、同じコンテナに含まれるべき – kubectl exec ポッド名 コンテナ名、コンテナ内のファイル名を指定して実行する K8s クラスタ アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ アプリ コンテナ kubectl exec pod名 -c コンテナ名 コマンド
29. © IBM Corporation 29 コンテナのアプリ + AI技術 + NoSQL
30. © IBM Corporation 30 IBM Cloud以外からも、Watson APIを呼び出せる インターネットでアクセス可能な場所から、IBM Cloudのサービスを利用できます。 使い慣れた他社クラウド環境からも利用できます。 IBM Watson NoSQLデータベース マネージドサービス API サービス Web アプリケーション インターネット マイクロサービスとして Watson APIと KVSを利用 クラウドでも パソコンのISP 経由接続でもOK
31. © IBM Corporation 31 IBM Cloud以外からも、Watson APIを呼び出せる インターネットでアクセス可能な場所から、IBM Cloudのサービスを利用できます。 使い慣れた他社クラウド環境からも利用できます。 IBM Watson NoSQLデータベース マネージドサービス API サービス Web アプリケーション インターネット マイクロサービスとして Watson APIと KVSを利用 クラウドでも パソコンのISP 経由接続でもOK Web アプリケーション
32. IBM Cloud Watson API など多数のサービスを搭載した「IBM Cloud」に 「いつまでも無料で使える」新しいアカウント・タイプ！ 「IBM Cloud ライト・アカウント」 IBM Cloud ライトアカウント 検索