コンテナ・イメージとは

コンテナ・イメージは、オペレーティング・システム上でコンテナを作成するために必要なすべてのコンポーネントをまとめたもので、複数のイメージ・レイヤーが積み重なって構成されています。コンテナ・イメージは不変であり、テンプレートと同様の機能を持ちます。

コンテナ・イメージは、ファイル・システムのような役割を果たすコンテナ・イメージ・レジストリー（またはContainer Registry）に保存されます。Container Registryは、コンテナ・イメージを保管・取得するためのデータ・リポジトリー（または複数のリポジトリ）です。

Container Registryの大きな利点の1つは、KubernetesやDockerなどのコンテナ・オーケストレーション・システム／プラットフォームと非常にスムーズに連携できる点です。さらに、Container Registryはコンテナベースのアプリケーション開発において、DevOpsの一環として活用することができ、最適化されたワークフロー統合を実現します。

コンテナ・イメージは、以下のようなレイヤーを積み重ねて構成された集合体です。

• ベース・イメージ
• ライブラリー
• バイナリー
• 依存関係
• 構成ファイル

スクラッチ（ゼロ）から新しいイメージを構築する場合、最下層にあるベース・イメージから始まります。ベース・イメージは、多くのコンテナベースの開発ワークフローの出発点です。多くのベース・イメージは、Debian、Ubuntu、Red Hat® Enterprise Linux（RHEL）、Rocky Linux、Alpineといった基本的または最小限のLinux®ディストリビューションで構成されています。ベース・イメージには、コンテナのファイル・システムのファイルが格納されます。ベース・イメージの作成プロセス（「ビルド」として知られています）によって、開発者は標準化された環境を構築でき、それによりカスタム・コンテナ・イメージの開発が可能になります。

その後、ファイル・システムのレイヤーが順に追加され、ベース・イメージの上に積み重ねられていきます。これには、以下のようなものが含まれます。

• 必要なライブラリー：プログラマーが一般的なデータ構造（例：リスト、スタック、キューなど）を作成する際に使用できる、アルゴリズムやクラス・テンプレートの標準的な集合です。

• 必要なバイナリー：さまざまなプログラムやコマンドを実行するために必要な実行ファイルです。バイナリー・フォルダは、ユーザーが必要な実行ファイルに迅速にアクセスできるように設計されています。

• コンテナの作成と動作を制御するする、さまざまな依存関係。

• 対象のコンテナを実行するために必要な構成ファイル（configs）。

既存のイメージを取り込んだコンテナ・イメージでは、それら既存イメージのベース・イメージは親イメージと呼ばれます。一方、完全に独自に作成されたイメージには、親イメージが存在しないとされます。

コンテナ・イメージはContainer Registryに保存され、イメージはそのレジストリーにアップロード（「プッシュ」）されたり、別のシステムにダウンロード（「プル」）されたりします。

Container Registryは、コンテナ・イメージに関するメタデータを記述するためにObject Storageを使用します。これにより、そうしたメタデータの転送が可能になりますが、限界もあります。たとえば、複数のイメージに関連するデータの場合、利用可能なタグの一覧数には制限があります。

依存関係コンテナは、もう1つのストレージ手法を提供します。これらのコンテナは、アプリケーション内の依存関係の管理、登録、解決を可能にします。依存関係とは、あるオブジェクトやプロセスが機能する前に、別のオブジェクトやプロセスが実行されている必要がある状況を指します。

オンライン・セキュリティーの重要性が増している中、リポジトリへのアクセスを許可された個人の認証は不可欠です。認証は、そのContainer Registryに固有の一連の権限を使用して行われます。権限とは、Container Registryからコンピューター・リソースを使用することが認められている人物を定義するものです。

ランタイムという概念は非常に重要です。コンテナ・ランタイムとは、コンテナがホスト・システム上で動作できるようにするソフトウェアのことです。コンテナ・ランタイムは、コンテナの作成を実行するために一連のステップを使用します。これらのステップには、アプリケーションとその依存関係を含むコンテナ・イメージに基づいて、コンテナを構築し、その実行環境を初期化するまでのプロセス全体が含まれます。

コンテナおよびコンテナ・イメージの利用において中心的な役割を果たすコンテナ・オーケストレーション・プロバイダーは、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を代わりに使用することがよくあります。

コンテナ・イメージ・プロバイダーの市場は流動的かつダイナミックであり、多くの企業が参入・退出を繰り返しています。しかし、以下のプロバイダーはこの分野で確固たる評判を築いています。

• Amazon：Amazon Web Services（AWS）は、Amazon Elastic Container Registry（ECR）を運営しており、コンテナ・イメージの脆弱性スキャンを管理するAmazon Inspectorを統合しています。ECRはアカウント間およびリージョン間の複製もサポートしており、イメージへのアクセスをより容易にしています。

• Apache：Apacheは、オープンソースのWebサーバー・ソフトウェアであり、Apache Software Foundationによって無償で提供されています。同財団によると、Apacheソフトウェアは全Webサーバーの約30％で稼働していると推定されています。

• GitHub：現在はMicrosoft傘下にあるGitHubプラットフォームは、コードの共有、管理、共同作業を可能にするこの独自ソフトウェアの仕組みが高く評価され、多くの開発者から広く支持されています。

• IBM：IBM® Cloud Container Registryを使用すれば、ユーザーは簡単に自分専用のレジストリーを立ち上げ、プライベート・イメージをレジストリーにプッシュしてIBM Cloud Kubernetes Serviceと組み合わせて利用することができます。ユーザーは、専用でフルマネージドなレジストリーを持つことによるプライバシーの恩恵を受けられます。このサービスは無料で試用可能で、従量課金制が採用されており、使用した分だけ支払う仕組みです。

• Microsoft：MicrosoftのAzureプラットフォームでは、DockerイメージやOpen Container Initiative（OCI）イメージを保持し、OCIアーティファクトもサポートするAzure Container Registry（ACR）が使用されています。ACRの接続レジストリー機能（プレミアム・サービス・レベルの一部）では、オンプレミスまたはリモートにレプリカを構築し、クラウド上のACRとコンテナ・イメージやOCIアーティファクトを同期させることができます。これはWindows®とLinuxの両方のイメージに対応しています。コンピューター・プログラムと対話する方法の1つに、コマンドラインと呼ばれるテキストの行を記述して入力するという手法があります。この方式を採用しているオペレーティング・システムでは、コマンドライン・インターフェース（CLI）が用いられます。現在ではほとんどのユーザーがグラフィカル・ユーザー・インターフェース（GUI）を利用していますが、自動化のためにスクリプトを書くユーザーの間では、依然としてCLIが好まれています。Azureでは、Docker CLIを使って主要なコンテナ・イメージ操作を実行する柔軟性が提供されています。

• Python：Pythonは、Python Software Foundationによって提供されている、インタプリタ型でオブジェクト指向の高水準プログラミング言語です。組み込みのデータ構造により、Pythonは迅速なアプリケーション開発を必要とするワークロードに最適です。ソフトウェア開発者にとってのPythonの主な利点は、その使いやすさにあります。これは、コンパイル工程が不要であることに大きく起因しています。これにより、プログラマーは高速化されたデバッグ・サイクルを利用できるようになり、時間を節約できます。

• Red Hat：Red Hatは、1993年の創業以来、Linuxベースのプログラミングを推進してきました。Red Hatが提供するContainer RegistryであるOpenShift® Container Platform（OCP）は、ユーザーが必要に応じて自動的にイメージ・リポジトリーへアクセスできるようにし、さらにアプリケーションのビルドによって生成されたイメージをプッシュするための標準的な場所も提供します。