新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

コンテナ化とは何か

みなさん、こんにちは。IBMのデベロッパー・アドボケイト、Sai Vennamです。今回はコンテナ化についてお話します。

ビデオをお楽しみください。

コンテナ化テクノロジーの歴史

コンテナというと最近のDockerやKubernetesを思い浮かべますが、実はコンテナはかなり前から存在しているテクノロジーです。

それは2008年、LinuxカーネルでのCグループ(コントロール・グループ)の導入にまで溯ります。これが、今日の多様なコンテナ・テクノロジーに至る道を開いたのです。これには、Dockerだけでなく、Cloud FoundryやRocket、そしてその他のコンテナ・ランタイムも含まれます。

コンテナ化の利点を示す例

例を挙げて説明しましょう。私は開発者で、作成したNode.jsアプリケーションを実稼働環境にpushするとします。ここでは2種類のフォーム・ファクターを使って、コンテナ化の利点を説明します。

An example to illustrate the advantages of containerization

まずVMについて説明し、その後コンテナについて説明しましょう。

we’ll talk about VMs and then we’ll talk about containers.

仮想マシン(VM)とNode.jsアプリケーション

まず、こちらから説明しましょう。ここにあるのはハードウェア本体です。この大きい箱がそうです。それからゲスト、あるいはホスト・オペレーティング・システム、それからハイパーバイザーがあります。VMのスピンアップを可能にするのがハイパーバイザーです。

Virtual machines (VMs) and the Node.js application

次に、リソースの共有プールを見てみましょう。ホストOSとハイパーバイザーがあるので、これらのリソースの一部はおそらく既に使用されています。

we can assume that some of these resources have already been consumed.

Linux VMのスピンアップ

次に、この.jsアプリケーションをpushします。それにはLinux VMが必要です。では、そのLinux VMの概要をお話しましょう。このVMには、重要な要素がいくつかあります。まず、ホストOSとは別のオペレーティング・システム。これはゲストOSになります。さらに、バイナリーとライブラリーです。

Spinning up Linux VMs

これが一般的なLinux VMです。アプリケーションはごく軽量のものですが、そのLinux VMを作成するには、ここにゲストOSと一連のバイナリーおよびライブラリーを含めなければなりません。そのため、サイズが非常に大きくなります。実際、私が見た最も小さいNode.jsでも、容量は400 MBを超えていました。ただし、そのNode.jsランタイム・アプリケーション自体は15 MBもなかったはずです。

さて、こちらが用意できたところで、今度はこの.jsアプリケーションをその中にpushします。これだけで、ある程度のリソースが消費されます。

we’re gonna consume a set of resources.

VMのスケールアウト

次に、これをスケールアウトしましょう。このコピーをさらに2つ作成します。これらはまったく同じアプリケーションですが、独立したゲストOSとライブラリーを使用しデプロイする必要があります。これを3回行います。

Scaling out the VM

その結果、この特定のハードウェアでは、基本的にすべてのリソースが消費されたと考えられます。

we’ve consumed all of the resources.

コンテナとアジャイルDevOps

まだお話していないことが1つあります。この.jsアプリケーションは、自分のMacBookで開発しました。これをVMに組み込もうと実稼働環境にpushしたところ、問題がいくつか判明したうえ、互換性も一部確保できませんでした。このような問題から端を発して辻褄が合わない事態が発生することがあります。ローカル・マシン上では何も問題なく動作していたのに、実稼働環境にpushしようとすると、いきなりトラブルに見舞われるのです。これはアジャイルDevOpsと継続的インテグレーションおよびデリバリーにとって、手痛い妨げになります。

コンテナを作成する3段階のプロセス

この問題はコンテナを使用すると解決します。コンテナに関する何らかの操作を行ってそれをpushするとき、あるいはコンテナを作成するときには、3段階のプロセスを使用します。ほとんどの場合、最初に登場するのがマニフェストです。これはコンテナ自体の詳細を記述するものです。DockerではDockerfile、Cloud Foundryではマニフェスト・ファイル(YAMLファイル)になります。

A three-step process for creating containers

次は、実際のイメージ本体の作成です。このイメージは、Dockerで作業している場合はDockerイメージ、 Rocketで作業している場合はACI(Application Container Image)になります。コンテナ化テクノロジーにはさまざまなものがありますが、このプロセスは同じです。

regardless of the different containerization technologies, this process stays the same.

最後は、実際のコンテナ本体です。これにはアプリケーションの実行に必要な、すべてのランタイム、ライブラリー、バイナリーが含まれています。

contains all of the runtimes and libraries and binaries needed to run an application.

コンテナのコンポーネント

このアプリケーションはVMにとてもよく似たセットアップで動作しますが、こちら側でまず必要になるのは、やはりホスト・オペレーティング・システムです。違うのは、ハイパーバイザーの代わりに、ランタイム・エンジンのようなものが必要になる点です。Dockerを使用している場合、これはDocker Engineで、他のコンテナ化テクノロジーを使用している場合は異なるエンジンになります。これらのエンジンがコンテナを実行します。

Components of a container

こちらにも共有リソース・プールがあります。これだけでリソースの一部が消費されていると考えられます。

we can assume that that alone consumes some set of resources.

テクノロジーのコンテナ化

次に、実際にこのテクノロジーをコンテナ化しましょう。ここまで3段階のプロセスについて話してきました。Dockerfileを作成し、イメージをビルドし、レジストリーにpushして、コンテナが完成します。ではこれをコンテナとしてpushしましょう。

これのよい所は大幅に軽量化される点です。複数のコンテナをデプロイするものの、ゲストOSは不要なので、ライブラリーとアプリケーション本体だけで済みます。

Containerizing the technology

これを3倍にスケールアウトしますが、こちらにあるオペレーティング・システムへの依存関係を丸ごと複製する必要はなく、作成するVMのサイズも大きくならずに済むため、使用リソースは少なくなります。ですからここには別の色を使いましょう。3倍にスケールアウトしても、まだかなりの量のリソースが残っています。

we still have a good amount of resources left.

サード・パーティー・サービスの活用

さて、同僚がこの.jsアプリケーションでサード・パーティーを利用しよう、例えばコグニティブAPIを使って画像認識などをやってみようと言い出したとします。サード・パーティー・サービスは確保しているので、それにPythonアプリケーションを使ってアクセスします。

Taking advantage of a third-party service

同僚がサード・パーティーのAPIにアクセスするサービスを作成してくれたので、このNode.jsアプリケーションを使ってそのPythonアプリケーションにアクセスし、そこから先ほどのサービスにアクセスします。

これをVMで行う場合、自分なら基本的に.jsアプリケーションとPythonアプリケーションの両方からVMを作成します。なぜなら、それによって既存のVMを事実上引き続いて使用できるからです。

that would allow me to continue to use the VMs that I have.

しかし、これは本当のクラウド・ネイティブではありませんよね?.jsはスケールアウトしてPythonアプリケーションはそのままにしておきたいと思っても、両者が同じVM上で実行されていれば無理だからです。これを本当のクラウド・ネイティブの方法で行うには、これらのリソースの一部を解放しなければなりません。基本的にはこれらのVMの1つを削除し、代わりにPythonアプリケーションをデプロイします。これはもちろん理想的とは言えません。

I would have to free up some of these resources—basically, get rid of one of these VMs, and then deploy the Python application in it instead

コンテナ・ベースのアプローチ

しかし、コンテナ・ベースのアプローチであれば、私たちはこれを簡単な方法で実現できます。これはモジュール式なので、Pythonアプリケーションを1つだけデプロイすればよいのです。その結果を別の色で表しましょう。これによってもう少しリソースが消費されます。

The container-based approach

さて、これらのリソースが残っていますが、コンテナ・テクノロジーの優れたところは、実行中のすべてのプロセスでこれを共有できる点にあります。優れた点はそれだけではありません。これらのコンテナ・プロセスが CPUやメモリーを実際に使用していない場合、これらの共有リソースはそのハードウェア内で実行されている他のコンテナからアクセス可能になるのです。

クラウド・ネイティブ・ベースのアーキテクチャーとコンテナの活用

コンテナ・ベースのテクノロジーでは、クラウド・ネイティブ・ベースのアーキテクチャーを本格的に活用できます。今回は、コンテナのポータビリティーやスケールアウトの容易性について説明しました。そして3段階のプロセスをコンテナのpushに使用することで、よりアジャイルなDevOpsと継続的インテグレーションおよびデリバリーが可能になることをお話しました。

最後までご覧いただき、ありがとうございました。

Sai Vennam Developer Advocate—IBM Cloud Kubernetes Service