Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Container-based Application Design Reference and Practice #dockertokyo

Container-based Application Design Reference and Practice #dockertokyo

#dockertokyo で発表したコンテナベースでのアプリケーション設計についてです。

元資料
https://docs.google.com/presentation/d/1kDdUWte7B2czfyObhEPjS6W9FSrdFQWOPHtecBxQuCc/edit?usp=sharing

Kazuki Higashiguchi

February 26, 2019
Tweet

More Decks by Kazuki Higashiguchi

Other Decks in Technology

Transcript

  1. @hgsgtk Kazuki Higashiguchi job is … Software Engineer lang is

    ... PHP, Go ...etc belongs to ... BASE BANK株式会社 (BASE株式会社の100%子会社) worked with … Docker, AWS(ECS/Fargate) 3
  2. = Beyond the Twelve-Factor App Principles of container-based application design(Redhat)

    6 Container-based design Guide and Principle https://content.pivotal.io/blog/beyond-the-twelve-factor-app https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
  3. = • Pivotal社が公開しているガイドライン ◦ https://content.pivotal.io/blog/beyond-the-t welve-factor-app • オリジナルは、The Twelve-Factor App

    ◦ https://12factor.net/ ◦ Herokuの中の人が書いたクラウドアプリケー ションのベストプラクティス • Original 12 + New 3 = 15 principles • 参考 ◦ https://speakerdeck.com/tayasu/beyond-the -twelve-factor-app 8 Beyond the twelve factor app
  4. 15 factors ~ Beyond the twelve factor app ~ 9

    1. One codebase, one application 2. API first 3. Dependency management 4. Design, build, release, and run 5. Configuration, credentials, and code 6. Logs 7. Disposability 8. Backing services 9. Environment parity 10. Administrative processes 11. Port binding 12. Stateless processes 13. Concurrency 14. Telemetry 15. Authentication and authorization
  5. 15 factors 抜粋 ~ Beyond the twelve factor app ~

    10 1. One codebase, one application 2. API first 3. Dependency management 4. Design, build, release, and run 5. Configuration, credentials, and code 6. Logs 7. Disposability 8. Backing services 9. Environment parity 10. Administrative processes 11. Port binding 12. Stateless processes 13. Concurrency 14. Telemetry 15. Authentication and authorization
  6. = 設定・認証情報はコードから分離 • バージョン管理にも含めない • 環境ごと(dev, stg, prd)にグルーピングすべきではない • Treat

    Your Apps Like Open Source ◦ “今すぐにでもコードをオープンソース化できるか ” • 設定を分離する一番の方法は環境変数への格納 外部化された設定・認証情報 • YAMLファイルや、web.configといった方法は anti-patterns • コードから分離されていない • 推奨:クラウド利用であれば下記のようなサービス(があれば) ◦ 構造的に管理 ◦ 安全にアプリケーションに渡すことができる • 推奨:設定外部化のための製品 ◦ ex. Spring Cloud Config Server ◦ https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html 11 05. CONFIGURATION, CREDENTIALS, AND CODE
  7. 05. 実践例 05. CONFIGURATION, CREDENTIALS, AND CODE 12 • AWS

    ECS(Fargate) • 設定情報は、Parameter Storeに格納 • Key Management Storeを活用して暗号化 • コンテナ実行時にParamter Storeから取得し た設定を注入 • https://devblog.thebase.in/entry/2019/01/16/110000
  8. 06. 実践例 14 06. LOGS • アプリケーションが書き出すログは全て標準出 力へ • ECS

    タスクから標準出力をCloudWatchLogs に流れる用に設定 ◦ https://dev.classmethod.jp/cloud/aws/e cs-cloudwatch-logs/ • CloudWatchLogs → ElasticSearch&Kibana ◦ 「ECS on Fargateで動いているプログラ ムのログをElasticsearch/Kibanaで可視 化」 by @tomy103rider ◦ https://qiita.com/tomy103rider/items/44 1313808aa337dd4500
  9. = • 必要な3つの監視 • Application performance monitoring (APM) ◦ パフォーマンス

    • Domain-specific telemetry ◦ KPI、ビジネス指標 • Health and system logs ◦ 死活監視 18 14. TELEMETRY
  10. 14. 実践例 14 TELEMETRY 19 • ヘルスチェック用のエンドポイントを用意する ◦ HTTPサーバのみ ◦

    DBサーバ・Redisサーバへの接続も含む • Mackerel を利用してエンドポイントに対して チェックを行う ◦ https://mackerel.io
  11. Principles ~ Principles of container-based application design(Redhat) ~ 21 1.

    SINGLE CONCERN PRINCIPLE (SCP) 単一関 心の原則 2. HIGH OBSERVABILITY PRINCIPLE (HOP) 高 観測可能性の原則 3. LIFE-CYCLE CONFORMANCE PRINCIPLE (LCP) ライフサイクル適合の原則 4. IMAGE IMMUTABILITY PRINCIPLE (IIP) イ メージ不変性の原則 5. PROCESS DISPOSABILITY PRINCIPLE (PDP) プロセス廃棄性の原則 6. SELF-CONTAINMENT PRINCIPLE (S-CP) 自 己完結性の原則 7. RUNTIME CONFINEMENT PRINCIPLE (RCP) ランタイム制限の原則
  12. Principles 抜粋 ~ Principles of container-based application design(Redhat) ~ 22

    1. SINGLE CONCERN PRINCIPLE (SCP) 単一 関心の原則 2. HIGH OBSERVABILITY PRINCIPLE (HOP) 高 観測可能性の原則 3. LIFE-CYCLE CONFORMANCE PRINCIPLE (LCP) ライフサイクル適合の原則 4. IMAGE IMMUTABILITY PRINCIPLE (IIP) イ メージ不変性の原則 5. PROCESS DISPOSABILITY PRINCIPLE (PDP) プロセス廃棄性の原則 6. SELF-CONTAINMENT PRINCIPLE (S-CP) 自 己完結性の原則 7. RUNTIME CONFINEMENT PRINCIPLE (RCP) ランタイム制限の原則
  13. = • Like “Single Responsibility Principle” (単一責任の原則) ◦ “クラスはただ一つの責任をもつべきだ ”

    • コンテナイメージの再利用・置換可能性が狙い • 一つのプロセス(コンテナ)は一つの関心に対処する • 複数の関心に対処する必要がある場合、サイドカーといったパターンやInit Containerを使用 ◦ https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar ◦ https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ 23 SINGLE CONCERN PRINCIPLE (SCP)
  14. SCP 実践例 24 SINGLE CONCERN PRINCIPLE • API アプリケーション・mackerel-agentをサイド カーで動かす

    • mackerel-container-agent ◦ https://mackerel.io/ja/docs/entry/howto/ container-agent ◦ コンテナオーケストレーションプラット フォームを対象とした専用の監視エージェ ント
  15. IIP 実践例 28 IMAGE IMMUTABILITY PRINCIPLE 外部化された設定情報 • 環境ごとに異なる設定情報は、AWS Parameter

    Storeに保存 ランタイム情報の実行時注入 • コンテナ実行時に、環境変数に注入する
  16. Summary Container-based Application Design Reference and Practice 32 • APIアプリケーションをコンテナベースで動かす

    ためにはコンテナを前提とした設計が必要。 • 自身のアプリケーションがガイドライン・原則を 満たしているか改めて見直してみると理解が 深まる