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
-
事例
[横河レンタ・リース株式会社] AIの全社活用が加速 トヨタ・コニック・プロに学ぶ「AI PC調達」の秘訣 -
製品資料
[横河レンタ・リース株式会社] 人材不足時代の「PC調達」ガイド：知っておきたいリースとレンタルの違い -
製品資料
[横河レンタ・リース株式会社] PC調達に「レンタル」を選ぶことのメリットは？ リース・購入との違いも解説 -
技術文書・技術解説
[セコムトラストシステムズ株式会社] SCS評価制度時代の「SASE選定」ガイド -
比較資料
[セコムトラストシステムズ株式会社] なぜ「SASE選定は難しい」と言われるのか？ 多くの人が陥る失敗パターンを解説
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に？ ベテランエンジニアを追い込む“54歳の壁”
-
2
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
3
パッチなしで「今すぐサーバを落とせ」 Kiteworks異例警告の波紋
-
4
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
5
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
6
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
7
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
8
「契約業務のAI活用」に関するアンケート
-
9
【基本情報技術者試験】メモリ不足でもアプリが動くのはなぜ？ OSを支える「仮想記憶」
-
10
Copilot導入で陥る“目的化”の落とし穴 定着の鍵は「作り込まない」こと
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
2
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
3
システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
-
4
AI駆動攻撃にどう対抗する？ 超速の攻撃からエンドポイントを保護する方法
-
5
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは？
-
8
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
9
「IT史に名を残すシステム障害」8選
-
10
最速72分でデータが流出？ 最新の脅威トレンドや侵入手法から分かった防衛策
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー