The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
コンテナ・イメージは変更されることのない静的ファイルで、実行可能なコードを含み、ITインフラ上で他と分離された状態で動作します。
コンテナ・イメージは、オペレーティング・システム上でコンテナを作成するために必要なすべてのコンポーネントをまとめたもので、複数のイメージ・レイヤーが積み重なって構成されています。コンテナ・イメージは不変であり、テンプレートと同様の機能を持ちます。
コンテナ・イメージは、ファイル・システムのような役割を果たすコンテナ・イメージ・レジストリー(またはコンテナ・レジストリー)に保存されます。コンテナ・レジストリーは、コンテナ・イメージの保管・アクセスのためのデータ・リポジトリー(または複数のリポジトリー)です。
コンテナ・レジストリーの大きな利点の1つは、KubernetesやDockerなどのコンテナ・オーケストレーション・システム/プラットフォームと非常にスムーズに連携できる点です。さらに、コンテナ・レジストリーはコンテナベースのアプリケーション開発において、DevOpsの一環として活用でき、ワークフローとの効率的な統合を実現します。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
コンテナ・イメージは、以下のようなレイヤーを積み重ねて構成された集合体です。
スクラッチ(ゼロ)から新しいイメージを構築する場合、最下層にあるベース・イメージから始まります。ベース・イメージは、多くのコンテナベースの開発ワークフローの出発点です。多くのベース・イメージは、Debian、Ubuntu、Red Hat® Enterprise Linux(RHEL)、Rocky Linux、Alpineといった基本的または最小限のLinux®ディストリビューションで構成されています。ベース・イメージには、コンテナのファイル・システムのファイルが格納されます。ベース・イメージの作成プロセス(「ビルド」として知られています)によって、開発者は標準化された環境を構築でき、それによりカスタム・コンテナ・イメージの開発が可能になります。
その後、ファイル・システムのレイヤーが順に追加され、ベース・イメージの上に積み重ねられていきます。これには、以下のようなものが含まれます。
既存のイメージを取り込んだコンテナ・イメージでは、それら既存イメージのベース・イメージは親イメージと呼ばれます。一方、完全に独自に作成されたイメージには、親イメージが存在しないとされます。
コンテナ・イメージはContainer Registryに保存され、イメージはそのレジストリーにアップロード(「プッシュ」)されたり、別のシステムにダウンロード(「プル」)されたりします。
コンテナ・レジストリーは、コンテナ・イメージに関するメタデータを記述するためにオブジェクト・ストレージを使用します。これにより、そうしたメタデータの転送が可能になりますが、限界もあります。たとえば、複数のイメージを含むデータでは、一覧表示できるタグの数に制限があります。
依存関係コンテナは、もう1つのストレージ手法を提供します。これらのコンテナは、アプリケーション内の依存関係の管理、登録、解決を可能にします。依存関係とは、あるオブジェクトやプロセスが機能する前に、別のオブジェクトやプロセスが実行されている必要がある状況を指します。
オンライン・セキュリティーの重要性が増している中、リポジトリへのアクセスを許可された個人の認証は不可欠です。認証は、そのコンテナ・レジストリーに固有の一連の権限を使用して行われます。権限とは、コンテナ・レジストリーからコンピューター・リソースを使用することが認められている人物を定義するものです。
ランタイムという概念は非常に重要です。コンテナ・ランタイムとは、コンテナがホスト・システム上で動作できるようにするソフトウェアのことです。コンテナ・ランタイムは、コンテナの作成を実行するために一連のステップを使用します。これらのステップには、アプリケーションとその依存関係を含むコンテナ・イメージに基づいて、コンテナを構築し、その実行環境を初期化するまでのプロセス全体が含まれます。
コンテナおよびコンテナ・イメージの利用において中心的な役割を果たすコンテナ・オーケストレーション・プロバイダーは、2つあります。
Dockerは、アプリケーションの作成、デプロイ、実行における複雑さを軽減するコンテナ・オーケストレーション・システムです。Dockerは、軽量で自己完結型のコンテナを構築するための簡便な手段として広く認識されており、特定のインフラに依存せず、あらゆるプラットフォーム上で動作可能です。Dockerコンテナは、あるマシンから別のマシンへと移動可能であるため、非常に高いポータビリティも提供します。さらに、Dockerはマイクロサービスをコンテナ・イメージとしてパッケージ化することにより、マイクロサービスの標準的なデプロイ手段も提供しています。
Dockerのイメージ・リソースはDockerHubであり、Dockerユーザー、ソフトウェア・ベンダー、オープンソース・プロジェクトによって共有された10万以上のイメージやその他のDockerファイルに無料でアクセスできます。プライベート利用向けには、有料のDocker Container Registryサービスも提供されています。Dockerイメージは、ログイン、プッシュ、プルといった主要な操作を可能にするDockerコマンドライン・インターフェース(Docker CLI)を使用します。ユーザーは、Docker EngineのDocker Build機能を使ってDockerイメージを作成し、ソースコードのパッケージ化とバンドルを行います。Dockerは、JavaScript Object Notation(JSON)形式の構成ファイルによって設定可能です。JSONは、すべての構成情報を一元的に保持できることから、推奨されるフォーマットとされています。
Kubernetesは、オープンソースのコンテナ・オーケストレーション・プラットフォームです。Kubernetesは、管理、デプロイ、拡張など、さまざまなソフトウェア・プロセスを自動化するために使用されます。Kubernetesサービスでは、1台以上のコンピューター(仮想マシンまたはベアメタル・サーバー)がKubernetesクラスターに接続され、さまざまな規模や種類のコンテナ・ワークロードが実行されます。Kubernetesのアプリケーション・プログラミング・インターフェース(API)サーバーは、ポッド、サービス、レプリケーション・コントローラーなどのAPIオブジェクトに対するデータを構成します。APIは、異なるソフトウェア・アプリ同士が完全に連携してデータをやり取りできるようにします。
DockerとKubernetesは類似したサービスを提供しますが、それぞれのスケール感には違いがあります。Dockerはコンテナ・ランタイムであるのに対し、Kubernetesは複数のコンテナ・ランタイムに対応できる包括的なプラットフォームです。Dockerは、Kubernetesがサポートするコンテナ・ランタイムの1つに過ぎません。
コンテナ・イメージは、Container Registryの利用における重要なコンポーネントです。
コンテナ・イメージは、コンテナを実行するために必要なすべてを保持することを目的として設計されています。コンテナ・イメージが作成されれば、あとはコンピューター・システムから適切な指示を与えるだけで、コンテナを実行できます。これにより、コンテナ・イメージは迅速な導入に最適なものとなります。
ビジネスの優先事項は一夜にして変わることもあります。あらかじめコンテナ・イメージを作成しておくことで、組織は将来的に必要となる可能性のあるあらゆるコンテナを予測し、その時点の状況や目的に最適なコンテナを後から選択することができます。コンテナ・イメージによって、状況の変化に応じて柔軟に方向転換することが可能になります。
コンテナ・イメージのセキュリティーは、Container Registryによって実施されるアクセス制御によって維持されています。これには、認証プロトコルが含まれており、認可されていない人物によるコンテナ・イメージへのアクセスを防止します。イメージの暗号化も現在では一般的に使用されており、イメージをエンコードすることで脆弱性から保護しています。
以下のようなアクティビティでは、コンテナ・イメージが広く活用されています。
コンテナ・イメージの活用によって実現されるコンテナベースのデプロイメントは、クラウドネイティブなアーキテクチャーを支え、必要な分離性と柔軟性を提供します。コンテナおよびコンテナ・イメージを活用することで、スケーラブルでクラウドネイティブなアプリの構築と最適化が可能になります。
多くのコンテナ・レジストリー(およびそこに保存されたコンテナ・イメージ)は、コンテナ・クラスター内で特定のマイクロサービスを見つけて接続するプロセスを分かりやすくすることで、マイクロサービスの利用を支援します。
仮想マシン(VM)は、1台のコンピューター上で別のコンピューターの機能を模倣するソフトウェアを使用したコンピューター・システムです。VIMはコンテナ・イメージと特有の関係にあります。特にクラウド上でコンテナを実行する必要がある場合、ユーザーはコンテナをハードウェア上で直接実行するのではなく、コンテナのホストOSとしてVMを代わりに使用することがよくあります。
コンテナ・イメージ・プロバイダーの市場は流動的かつダイナミックであり、多くの企業が参入・退出を繰り返しています。しかし、以下のプロバイダーはこの分野で確固たる評判を築いています。
AIとオートメーションの力を活用することで、問題がアプリケーションスタック全体でプロアクティブに解決します。
DevOpsソフトウェアとツールを使用して、複数のデバイスや環境でクラウドネイティブ・アプリを構築、デプロイ、管理します。
ビジネスの俊敏性と成長を加速—IBMのクラウド・コンサルティング・サービスを利用して、あらゆるプラットフォーム上のアプリケーションを継続的にモダナイズしまします。