コンテナレジストリとは

コンテナレジストリは、コンテナイメージの保存とアクセスに使用されるリポジトリ (またはリポジトリのコレクション) です。コンテナレジストリはコンテナベースのアプリケーション開発をサポートでき、多くの場合 DevOps プロセスの一環として使用されます。コンテナレジストリは、 Docker や Kubernetesなどのコンテナ・オーケストレーション・プラットフォームに直接接続できます。 

コンテナレジストリはシステム間でコンテナイメージを共有するための仲介役として機能し、クラウドネイティブ・アプリケーションの作成と提供にかける開発者の貴重な時間を節約します。

コンテナ イメージには、アプリケーションを構成するファイルとコンポーネントが含まれています。 仮想マシン (VM)とは違ってコンテナはソフトウェアの軽量パッケージであり、Linux® オペレーティングシステム (OS) 上で実行されます。コンテナイメージは、ワークロードの変化に合わせて何倍にもスケーリングできます。一般的に、アジャイル開発、DevOps 手法、 継続的インテグレーションと継続的デリバリー (CI/CD) で使用されます。 

コンテナイメージには、システムライブラリ、システムツール、およびアプリケーションの実行に必要なその他のプラットフォーム設定が含まれているため、開発者は可搬性とアジリティというメリットを得て、迅速にアプリケーションを拡張したり、新しいアプリケーションを作成したりできます。

Buildah のようなオープンソースツールを使用すると、Dockerfile や既存のコンテナイメージを開始点として使用するかどうかにかかわらず、OCI および Docker 互換のイメージを作成できます。そのため、プロセスでの当て推量の多くが不要になります。 

コンテナイメージを作成する場合、作成したコンテナイメージを保存、共有、アクセスできる場所が必要ですが、この場所にあたるものがコンテナレジストリです。

コンテナレジストリは基本的に、開発者がコンテナイメージを格納し、レジストリへのアップロード (プッシュ) や Kubernetes クラスタなど別のシステムへのダウンロード (プル) のプロセスを介してそれらを共有する場所として機能します。 

イメージをプルすると、イメージに含まれるアプリケーションをそのシステムで実行できます。

レジストリには、コンテナイメージに加えて、アプリケーション・プログラミング・インタフェース (API) のパスと、コンテナ間通信のためのアクセス制御パラメーターも格納されます。API は、変更を制限し、システム停止の一般的な原因となっている意図しない結合を排除するのに役立ちます。特に、ハイブリッドクラウド環境ではアプリケーションが同じデータセンターには存在しないので、これは大きな意味を持ちます。

コンテナイメージは、サービスメッシュ (コンテナ化されたサービス間のインフラストラクチャレイヤーで、スケーリングに役立つ) 上で通信することもできます。マイクロサービス・アーキテクチャで構築されたクラウドネイティブ・アプリケーションの場合、サービスメッシュは、多数の独立したサービスを機能的なアプリケーションにまとめる手段となります。

Cloud Native Computing Foundation は、コンテナ (コンテナイメージとレジストリを含む) とマイクロサービスは、クラウドネイティブ・アプリケーション開発の基盤であると述べています。コンテナとマイクロサービスは完全に自己完結型であるため、可搬性のあるクラウドネイティブ・アプリケーションを作成するための強力なツールになります。 

コンテナは、アプリケーションプロセス、ランタイムファイル、および OS の依存関係をシステムの他の部分から分離します。ハイブリッドクラウド環境全体での可搬性が高く、仮想マシン (VM) よりもはるかに短い期間でデプロイできます。これにより、開発者はコンテナレジストリで必要なものを簡単にプッシュおよびプルできるため、基盤となるインフラストラクチャや実行の詳細に気を取られることなく、優れた製品の構築に集中できます。

DevOps 環境では、コンテナ(およびコンテナイメージ/レジストリ)を使用することで、開発者は各アプリケーションサービスを個別にデプロイできるため、コード変更をマージする必要がなくなり、テストが改善され、テスト環境と本番環境の両方で問題の分離が容易になります。

コンテナレジストリには、パブリックとプライベートの 2 種類があります。 

パブリックレジストリは一般的に、レジストリーをできるだけ早く使い始めたい個人や小規模なチームで使用されます。 しかし、組織の規模が大きくなるにつれて、パッチの適用、プライバシー、アクセス制御など、セキュリティに関する複雑な課題が発生する可能性があります。 

プライベートレジストリでは、リモートあるいはオンプレミスでホストされるエンタープライズ向けのコンテナイメージのストレージにセキュリティとプライバシーを組み込むことができます。これらのプライベートレジストリの多くには、高度なセキュリティ機能とテクニカルサポートが付属しています。

Google の Google Container Registry、AWS の Amazon Elastic Container Registry (ECR)、マイクロソフトの Azure Container Registry など、ほとんどのクラウドプロバイダーはプライベートイメージレジストリサービスを提供しています。

プライベートな内部レジストリを使用すると、セキュリティと構成の可能性を最大に引き出せますが、そのためには、レジストリのインフラストラクチャとアクセス制御が組織内で維持されるように慎重に管理する必要があります。

エンタープライズ向けのプライベート・コンテナ・レジストリ・サービスを選択する際に考慮すべき重要な点には次のようなものがあります。

• 複数の認証システムをサポートしているか

• ローカルイメージにロールベースのアクセス制御管理 (RBAC) を使用できるか

• 脆弱性スキャン機能が備わっており、セキュリティと構成を強化できるか

• 監査可能なログに使用状況を記録して、アクティビティを単一のユーザーまで追跡できるようにする機能があるか

• 自動化のための最適化がされているか

プライベートレジストリにエンタープライズ対応機能があれば、安全かつ効率的な方法でコンテナイメージに内部からアクセスできます。複数の認証システムが、そこに保存されているコンテナイメージを検証するための手段を講じています。

たとえば、イメージをレジストリにプッシュする前に、アップロードするユーザーがデジタル署名する必要があります。また、アクティビティの追跡が有効になっており、不正なユーザーによるアップロードを防ぎます。

RBAC は、個人のロールに基づいて、どのユーザーアクションを許可するかを管理します。たとえば、開発者はレジストリへのアップロードだけでなく、レジストリからのダウンロードにもアクセスが必要ですが、チームメンバーやテスターに必要なのはダウンロードへのアクセスのみです。Active Directory (AD) や Lightweight Directory Access Protocol (LDAP) などのユーザー管理システムを使用している組織では、そのシステムをコンテナレジストリに直接リンクして、RBAC に使用できます。

レジストリをデプロイする際の選択肢には、独自のコンテナレジストリを作成してデプロイするか、商用サポートされているプライベート・レジストリ・サービスを利用するかの 2 つがあります。

Red Hat® OpenShift® はエンタープライズ対応の Kubernetes コンテナ・プラットフォームであり、あらゆるクラウド・インフラストラクチャにわたって一貫性を提供し、ハイブリッドクラウド、マルチクラウド、エッジ・デプロイメントを管理します。Red Hat OpenShift を使用すると、新しいマイクロサービスやアプリケーションの環境を数分でプロビジョニングできます。ミドルウェア、言語、フレームワーク、データベースなどの他のクラウドサービスに加えて、コンテナイメージを管理するための基本的な機能を提供するプライベートレジストリがすでに含まれています。 

プライベートレジストリは、 Red Hat の豊富なパートナーエコシステムから、クラウドプロバイダー上の Red Hat OpenShift マネージドサービスの一部としてデプロイでき、Azure、Amazon Web Services (AWS)、IBM Cloud、Google Cloud でシームレスなエクスペリエンスを提供します。Red Hat OpenShift は、JFrog’s Artifactory や Sonatype Nexus など、すでに使用している他のプライベート・レジストリとの統合もサポートしています。

Red Hat は、ハイブリッドクラウドを基盤とするセルフマネージド型のサービスも提供しており、セキュリティ機能が強化され、データセンターで使用できるソフトウェア要素が追加されています。より高度なセキュリティ機能やテクニカルサポート機能が必要な場合は、Red Hat Quay をスタンドアロンのスケーラブルなエンタープライズレジストリとして利用できます。

Red Hat Quay のメリットの詳細