IT部門もアジャイル、DevOpsで行こう【第3回】
Dockerが提唱する“Container as a Service”とは、早い話がPaaSである（1/2 ページ）
DockerとPaaSは、DevOpsを支援する技術として相反するもののように見えるが、実際は対立関係ではなく協力関係にある。具体的にどういうことか。両者の仕組みを図で解説する。
DockerとPaaSの違い
前回（アプリケーションの開発と運用を加速するDockerとPaaS、両者の違いは？）は、「Docker」と「PaaS（Platform as a Service）」の違いについて解説したが、もう一度簡単に両者についておさらいしてみよう。
まずDockerは、コンテナ技術を応用したソフトウェアであり、アプリケーションのポータビリティ性を高め、さまざまな場所で環境差分なく展開できる仕組みを備えている。開発者と運用者の橋渡しに最適なツールだ。
PaaSはカテゴリの名称であり、各サービスによって差異はあるものの、簡易な操作でアプリケーションをデプロイでき、かつ運用を一任できるようなサービスを指す。アプリケーション開発の現場から、運用という仕事をなくしてしまうことで生産性を高めるのがPaaSだ。
広がる“Docker＋PaaS”
さて、既に述べたようなDockerとPaaSの違いを考えると、「アプリケーション開発の生産性向上のために、DockerとPaaSのどちらを採用すべきか」という疑問に至るだろう。だがちょっと待ってほしい。DockerとPaaSは相いいれないものなのだろうか――そんなことはない。それどころか、両者の相性は非常によいものなのだ。
Dockerは以前、dotCloudという名称の企業であった。そのdotCloudが行っていた事業は、何とPaaSなのである。dotCloudが、社名と同じ「dotCloud」というPaaSを開発・運用する中で生まれたもの、それがDockerなのだ。もともとPaaSのために作られた仕組みなのだから、相性が悪いはずもない。それでは、PaaSの中で生きるDockerとは、どのような仕組みで動いているのだろうか。
図1は、ユーザーがアプリケーションをデプロイした際に、PaaS内部で行われる作業を示したものだ。
図1 PaaSでアプリケーションを実行するまでの流れ
第1フェーズとして、ユーザーはアプリケーションをCLI（Command Line Interface）や「Git」、GUI（Graphical User Interface）などでPaaSにアップロードする。PaaS側では、APIを提供しているコントローラーがそれを受け取り、然るべき場所に保存する。この作業を「Upload（アップロード）」と呼ぶこととする。
第2フェーズとして、アップロードされたアプリケーションを実行可能な形にする作業が入る。これは2つの作業に分けられる。まず、アップロードされたアプリケーションがどのような言語／フレームワークで作られているか検出する。これを「detect（ディテクト）」という。次に、検出された言語／フレームワーク向けに必要な環境を整え、イメージ化する作業が入る。これを「compile（コンパイル）」という。例えばRubyアプリケーションであれば、「Rubyランタイムの配置」「bundle installの実行（必要なライブラリのダウンロード）」などが行われる。こうして出来上がったファイル一式をアーカイブして、実行イメージとして然るべき場所に保存する。この第2フェーズのことを「Staging（ステージング）」と呼ぶ。
第3フェーズでは、出来上がったイメージを実行ノードにコピーし起動する。負荷分散や冗長化のために複数インスタンス実行が指示されている場合は、指示された個数だけコピーして起動する。このフェーズのことを「Run（実行）」と呼ぶ。
このUpload、Staging、Runの3フェーズがPaaSの肝となっているのだ。
それでは、DockerとPaaSを組み合わせた場合はどうなるか。勘のいい読者はお気付きかもしれないが、Stagingはイメージを作成する作業だ。ユーザーが「Docker image」を所持しているならば、それをStagingの代わりとすればよいのだ。
DockerとPaaSの融合を図にすると以下のようになる。
図2 Dockerでアプリケーションを実行するまでの流れ
この形を取ることで、ユーザーは動作実績のあるDocker imageを手元で利用しながら、かつ本番環境ではPaaSに運用を委任するという、いいとこ取りが可能になるわけだ。
「Dockerfile」やDocker imageを作るのが面倒だというユーザーもいるだろう。そういったユーザーは、従来のソースコードアップロードの仕組みを利用すればいい。この場合、Staging時に生成されるイメージの形式をDocker imageとすればいい。
第3世代のPaaSとは
これまでのPaaSは、デプロイの容易性や運用を一任できる利便性が評価される一方、その内部の不透明性からくるトラブルシューティングのしづらさやPaaS間での互換性の低さ、柔軟性の低さが指摘されてきた。
固定的な言語や環境しか使えなかった世代を第1世代。汎用的な技術や他環境との相互運用性を意識し、複数の言語や環境を扱えるように改良された世代を第2世代とすると、Dockerを採用し、高い相互運用性や自由な環境構成を達成したPaaSは第3世代といえるだろう。
新たに登場したPaaSの他、既存のPaaSも追加機能としてDocker対応を果たしつつある。以下にDockerに対応しているPaaSを列挙する。
OpenShift v3
Red Hatが中心となって開発しているPaaS「OpenShift」。OpenShiftは2012年にOSSとして公開されたPaaSだが、2015年に公開されたバージョン3（以下、OpenShift v3）でアーキテクチャを一新し、Dockerを扱えるPaaSとして生まれ変わった。
OpenShift v3は、Googleが中心となって開発しているDockerコンテナの管理機構「Kubernetes」をベースとしており、KubernetesにPaaSとしてのユーザビリティを組み合わせたものになっている。
Deis
「Deis」もまた、Dockerが扱えるPaaSの1つだ。PaaSベンダーであるEngine Yardが開発しているOSSのDeisは、Docker imageやDockerfileが扱えるだけでなく、「Heroku」ライクな使い勝手も実現し、注目されつつある。
Cloud Foundry
OSS PaaSの代表格「Cloud Foundry」も、内部的なアーキテクチャを一新。以前からの互換性を残しながら、Docker image互換を果たした。
AWS Elastic Beanstalk
「Amazon Web Services（AWS）」が提供するPaaS「AWS Elastic Beanstalk」は、2014年4月というかなり早い時期からDocker対応を果たしている。
Google App Engine
Googleが提供するPaaS「Google App Engine（GAE）」も、2014年からDocker対応を果たしている。
Copyright © ITmedia, Inc. All Rights Reserved.
IT部門もアジャイル、DevOpsで行こう
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は？ 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは？ -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める？ -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
2
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
3
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
4
「ノートPC派」は損をしている？ Dellと考える“自作PC”のメリット
-
5
エンジニアの生産性はどう測る？ マネジメントに不可欠な可視化の実現方法とは
-
6
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
7
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
8
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
9
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
10
IT製品の導入に関するアンケート「PC＆デバイス」編
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー