コンテナ技術が変えるアプリケーション開発 2019 Apr

2 Agenda • はじめに • コンテナ技術（Docker／Kubernetes）の概要 • コンテナの利点と開発の流れ • まとめ 主にアプリケーション開発の観点から、コンテナ技術について以下を理解する • コンテナ技術の導入によりアプリ開発がどう変わるのか • コンテナの特徴やメリットを活かしたコンテナ・ベースのアプリ開発とは ポイント

はじめに

4 コンテナ技術についての疑問 • Docker/Kubernetesを中心に次世代のインフラ技術として注目されることが多いコンテナ技術 • 開発のスピードアップや生産性向上を達成するには、アプリ開発の視点でも理解することが不 可欠 コンテナの活用方法がわからない なぜ開発スピードが向上するの？ 開発時の注意点は？ ベストプラクティスは？ なぜポータビリティが高いの？ コンテナでアプリ開発はどう変わる？ コンテナイメージは誰が どうやって作成するの？ とあるアプリ開発者

コンテナ技術（Docker／Kubernetes）の概要

6 インフラ技術としてのコンテナとDocker • コンテナ型仮想化 - OS機能はホストを利用しプロセスごとに分離された環境で実行することでリソースを大幅に節約 - CPUやメモリなどのリソース、Disk/File SystemやN/Wなどを分離 - 仮想環境のイメージサイズが小さく、起動が短時間 • Docker - 2013年にDocker社によってリリース、現在コンテナ型仮想化技術のスタンダードに - コンテナ環境を可搬性のあるDockerイメージとして定義 - イメージファイルを共有するためのレジストリ（Docker Hub）が提供されている ハイパーバイザー型仮想化 コンテナ型仮想化 - 仮想化によりアプリから OS以下を抽象化 - SW依存関係のパッケージング • 迅速な起動 • リソース活用の効率化 • 高いポータビリティ

7 スケールアウト ポリシーベースでの可用性 負荷分散 ローリング アップデート ネットワーク管理 永続ストレージ管理 CPU/Memory リソース管理 Kubernetesによるコンテナ・オーケストレーション • Kubernetes（k8s） - Googleで自社のため開発されたコンテナ管理ソフト BorgをベースにOSS化 - コンテナ管理の標準になりつつあるオープンソースのコンテナ管理ツール 実際のシステム運用において必要な管理機能を提供 宣言されたポリシーに基づく自動運用を実現

8 DockerとKubernetesによるコンテナ作成・実行 • Dockerはコンテナの実行環境およびコンテナイメージを開発、共有する仕組みを提供 • Kubernetesはあるべき姿を宣言したマニフェストをベースとしたコンテナ管理を実現 Dockerレジストリ Master xx docker build docker push docker pull kubectl create kubectl apply docker run Dockerホスト Kubernetesクラスター Dockerfile Docker イメージ マニフェスト docker commit

コンテナの利点と開発の流れ

10 コンテナ技術とポータビリティ • アプリと実行環境（依存S/W）をコンテナとして一つにパッケージング • 複数環境に対して同じようにデプロイ・稼働する（＝ポータビリティ） - 異なる環境へのデプロイ時においてミドルウェア設定の差異等による障害の発生が抑えられる M/W アプリ M/W アプリ ステージングコンテナ 検証コンテナ ＜コンテナによる実行環境構築＞ コンテナをデプロイ M/W アプリ 本番コンテナ • ビルド済コンテナを各環境にデプロイするだけ • 実行環境（M/W）がパッケージされているので同じように動作する 検証サーバー アプリをデプロイ ＜従来の実行環境構築＞ M/W（dev） アプリ OS（dev） ステージングサーバー M/W（test） アプリ OS（test） 本番サーバー M/W（prod） アプリ OS（prod） • 環境ごとに個別に導入・設定された実行環境（M/W）上にアプリ のパッケージをデプロイする • M/W設定の差異等がアプリの動作に影響する可能性あり

11 実行環境をオンデマンドに構築する • コンテナのポータビリティを活かしてアプリの実行環境を迅速に構築することが可能に アプリ 開発者 インフラ 担当者 インフラ 担当者 デプロイ 依頼 検証サーバー ステージングサーバー サーバー構築 M/W導入 アプリ デプロイ • サーバーごとの構築作業を行う （アプリ側と事前の日程調整や依頼が必要） • 構築・デプロイがインフラ担当者の作業の場合、完了 までアプリ開発者は待ち時間になる ＜従来の実行環境構築＞ M/W アプリ OS M/W アプリ OS コンテナ環境構築・運用 M/W アプリ M/W アプリ アプリ 開発者 ステージング コンテナ 検証コンテナ • コンテナ環境をインフラ担当者が構築してしまえばあと はコンテナをデプロイするだけ • デプロイ手順はCLIやツールで統一されているのでアプ リ開発者でも実施可能 ＜コンテナによる実行環境構築＞ アプリ（コンテナ） デプロイ

12 実行環境をオンデマンドに構築する • コンテナ基盤を活用すれば、用途に応じた柔軟な実行環境の運用が可能となる M/W 標準 ＜ローカル環境へ標準イメージ配布＞ • 標準化された開発者の実 行環境を迅速に構築 • 開発者の負荷軽減 ＜アドホックな実行環境＞ 1.0 Fix 1.1β 検証 緊急 障害対応 β版 確認 ステージング • 異なるバージョンの実行環 境を迅速に構築、並行稼 働も容易 • 廃棄・ロールバックも容易 開発ツール環境 アプリ スタブ DB 自動テスト実行 デプロイ 自動テスト環境 ＜開発ツール／自動テスト環境＞ • 構成管理やCI/CDツール等の開発ツー ル環境もコンテナで構築可能 • テスト実行のためのテストランナー、スタ ブやテスト用DBの自動テスト環境もオン デマンドに用意して利用 Push

13 Dockerfileとコンテナイメージの生成 • Dockerのコンテナイメージは通常Dockerfileをビルドして生成する - 他の作成済イメージをベースイメージとして差分を記述することにより新規イメージの作成が可能 - 利用可能なベースイメージがあれば開発者が一からコンテナイメージを作成する必要はない パブリックレジストリ Docker Hub xx # ベースイメージを指定 FROM websphere-liberty:19.0.0.3-kernel # ビルド済アプリをコンテナ内にコピー COPY --chown=1001:0 Sample1.war /config/dropins/ # アプリ個別の設定をコピー COPY --chown=1001:0 server.xml /config/ # フィーチャー追加 RUN installUtility install --acceptLicense defaultServer ・・・・ 例）WAS Libertyで稼働するアプリのためのコンテナイメージ用Dockerfile アプリ Dockerfile ベースイメージ 新規イメージ(w/アプリ) アプリ ソース WAS Liberty WAS Liberty xx アプリ ベースイメージ と同じ Dockerfile による差分 ベースイメージ＋Dockerfileの 内容から新規イメージを生成 FROMに指定したベースイメー ジをレジストリからビルド時に 取得する docker build • Dockerfileによりイメージの内容がコードとして 記述されている • 構成管理の仕組みによりバージョン管理も可能 • アプリPKGは従来通りに作成してコンテナ内に搭載

14 Dockerfileとコンテナイメージの生成 • コンテナイメージについての作業の切り分け（既存の体制で対応するとしたら） M/W アプリ Orchestration OS アプリ 開発者 インフラ 担当者 ？ ？ M/Wの設定もすべて アプリ開発者がやるの？ アプリ開発者に任せられる？ ＜ベンダー提供の公式イメージを使う＞ ＜インフラ担当者が独自の標準イメージを作成＞ M/W アプリ M/W Docker Hub • 負担も少なく、最も手っ取り早い • ベンダー提供のイメージがないケースもある • 安全なイメージを利用する M/W アプリ M/W • 標準化やセキュリティに厳しいケースに対応 • アプリ・インフラの分担を実現できる • 標準イメージの作成WLは必要 公式 標準

15 コンテナベースの開発の流れ • アプリそのものは同じだが、実行環境と共にパッケージされたコンテナがデプロイ単位 • ビルド済のコンテナイメージを複数の実行環境に統一された方法でデプロイする Source Build Test Deploy • ベースイメージの取得 • アプリの設計・実装 • Dockerfileの作成 • manifestの作成 • リポジトリへの登録 • 本番環境へのデプロイ • アプリのコンパイル • 単体テスト • アプリのパッケージング • コンテナイメージのビルド • イメージのレジストリ登録 • 検証／ステージング環境 へのデプロイ • 統合／受入テストの実施 構成管理 リポジトリ アプリ ソース Dockerfile イメージ レジストリ 検証環境／ステージング環境 本番環境 1.0 1.0 1.0

16 コンテナベース開発におけるCI/CDパイプライン • コンテナベースの開発ではGit・Jenkins・Mavenなどのオープン・テクノロジーを使って、 継続的なビルド・デプロイの自動化を開発時点で初期構成しておくのが望ましい • アプリ開発者がインフラ担当者に依存していた環境構築やデプロイ作業を含めて自動化するこ とにより、継続的なサービスの改善や障害対応のスピードを加速させることができる CI/CDパイプライン アプリビルド コンテナビルド 統合テスト デプロイ リポジトリ レジストリ 本番環境 ステージング環境 検証環境 x.x x.x Jenkins CircleCI TravisCI Gitlab GitHub Nexus Harbor Maven Gradle JMeter Docker Selenium kubectl Helm Spinnaker • 各ツールの選択や連携がポイント 予めツールセットを揃えたソリューションを活用することも可能

まとめ

18 まとめ • コンテナ技術について アプリ開発の観点から特徴や利点を理解することが重要 • コンテナ技術の活用で開発者が 開発作業に集中できる開発・実行環境を実現 • コンテナ技術による開発スピードアップで デジタル・トランスフォーメーションに取り組む 土台作りを CNCFのCloud Native Trail Map https://github.com/cncf/trailmap

End of File