コンテナレジストリを選択するにはどうすればいいですか?ここに9つの選択肢があります

2013 年にオープンソースの Docker エンジンがリリースされて以来、コンテナ化はクラウド アプリケーション開発プロセスの近代化の第一歩となっています。 Docker Engine が登場する前は、ユーザーは特定のコンピューター/ハードウェアに合わせてアプリケーションを構成する必要がありました。このアプローチの欠点は、アプリケーションとデータをあるサーバーから別のサーバーに移動するのに時間がかかることです。

しかし、Docker Registry の導入により、コンテナ レジストリの管理と整理という長年の課題が解決されました。実際、Docker Registry はソフトウェア業界の標準として急速に普及しました。現在、Docker Registry は、多くの企業がソフトウェア開発プロセスのさまざまな段階でコンテナ イメージを一元的に収集、保存、配信するのに役立っています。

この記事では、ソフトウェア開発のニーズに適したコンテナ レジストリを選択するために知っておく必要のあるコンテナ レジストリのコア機能の概要を説明します。

コンテナレジストリとは何ですか?

コンテナ レジストリは、継続的インテグレーション (CI)/継続的デリバリー (CD) システム、開発者、およびテスターがアプリケーション開発中に作成されたイメージを保存できるようにする、高度にスケーラブルなサーバー側アプリケーションです。コンテナ レジストリに保存されたイメージは、Kubernetes、DevOps、コンテナベースのアプリケーション開発に使用されます。例としては、Docker Hub、Amazon ECR、Azure などがあります。

適切なコンテナ レジストリを選択するにはどうすればよいでしょうか?

コンテナ レジストリの選択に関しては、市場には独断的なオプションが溢れており、適切なものを選ぶのは困難な作業になる可能性があります。ただし、ユーザーが選択を始める前に、考慮すべき重要な問題がいくつかあります。

• コンテナ イメージに加えて他の成果物をホストしたいですか?一部のコンテナ レジストリは、Java、Node.js、さらには Python パッケージなど、他の種類のファイルもサポートします。一方、コンテナ イメージのみをサポートするものもあります。
• 追加のセキュリティが必要ですか?ユーザーがイメージをレジストリにプッシュするたびに脆弱性スキャンを実行するなど、セキュリティを超えた機能を提供するコンテナ レジストリはごくわずかです。
• ローカル コンテナー レジストリとホストされたコンテナー レジストリのどちらを使用すればよいですか?

ユーザーがあるコンテナから別のコンテナに移行することを決定した場合、そのタスクは比較的簡単です。

どのようなコンテナレジストリが利用可能ですか?

1. AWS エラスティックコンテナレジストリ (AWS ECR)

AWS ECR は、プライベート Docker レジストリとパブリック Docker レジストリの両方をサポートするように設定できます。これらのレジストリを AWS IAM と併用して、ユーザー、サービス、アプリケーションのアクセスレベルを制御できます。本質的には、保護されたコンテナ イメージにアクセスできるユーザーを定義することができます。

AWS ECR には脆弱性イメージスキャン機能も備わっており、DevSecOps に不可欠な機能となっています。これは、発見された問題の重大度を評価するために、Clair の Common Vulnerabilities and Exposures (CVE) データベースを使用しているためです。 AWS ECR のもう 1 つの重要な機能は、不変のイメージタグです。この機能を有効にすると、イメージがコンテナ レジストリにプッシュされると、誰もそれを上書きできなくなります。

2. Azure コンテナー レジストリ (ACR)

Microsoft の Azure Container Registry は Docker Registry 2.0 に基づいており、認証は Azure RBAC によって管理されます。 Azure のコンテナー レジストリには、次のようなほとんどの競合他社がまだ提供していない機能があります。

• 古いイメージを自動的に消去します。
• タグなし在庫の保持ポリシー。
• コンテンツの信頼。

コンテンツの信頼は Docker によって作成された概念であり、Azure Container Registry にプッシュされたイメージにユーザーが署名できるようにするものであることに注意することが重要です。

本質的には、イメージを使用する可能性のあるアプリケーション/ユーザーは、署名されたイメージのみを抽出するようにクライアントを構成します。同時に、Docker クライアントはイメージの整合性を検証できるため、イメージが公開されていること、および公開されてから変更されていないことを確認できます。 Azure Container Registry は、Docker コンテナー イメージのホスティングに加えて、OCI イメージ、OCI 成果物、Helm チャートもサポートします。

価格情報に関しては、Microsoft は異なる階層システムを使用しています。

3. Docker Hub コンテナレジストリ

Docker Hub はデフォルトの Docker リポジトリであるため、現在おそらく最も人気のあるコンテナ レジストリです。これはパブリック コンテナ イメージのマーケットプレイスとして機能し、イメージを公開して配布する場合に最適な選択肢です。興味深いことに、Docker Hub の無料オプションは、一部のユーザーが自動ビルド機能を使用して暗号通貨のマイニングに使用し始めるまでは、しばらくの間非常に魅力的でした。

その結果、開発者は Docker のプル/プッシュ イメージにいくつかの制限を設け、Docker Hub を収益化する方法を再考しました。レート制限の変更と自動ビルドへの移行の詳細については、Docker Hub をご覧ください。イメージのプル/フェッチに対する Docker のレート制限を回避する 1 つの方法は、キャッシュ プロキシを使用することです。

価格設定に関しては、階層システムにより、ユーザーは有料プランを通じて特定の機能のロックを解除できます。ただし、全体的なコストは、AWS ECR や Microsoft の Azure Container Registry (ACR) などの他のソリューションを使用する場合ほど効果的ではありません。

4. GitHub パッケージレジストリ

2019 年 5 月、GitHub はパッケージ登録ソリューションを開始しました。ソリューションの成功により、同社は 2020 年 9 月にコンテナ イメージのサポートを、まずはテスト オプションとしてリリースしました。 GitHub Container Registry の魅力的な側面の 1 つは、特に開発者にとってシームレスなエクスペリエンスを提供することです。基本的に、認証は個人アクセス トークンを使用して管理されます。

もう 1 つのオプションはパブリック リポジトリを使用することですが、この場合、企業はユーザーが GitHub ユーザー アカウントで認証される必要があります。全体的に見ると、GitHub パッケージ レジストリは、最も機能が充実したコンテナ レジストリとは言えません。ただし、GitHub Actions を使用する予定の場合は、入場料を支払う必要がないため、価格設定はより競争力があります。

5. GitLab コンテナレジストリ

GitLab には、無料で使用できる独自のコンテナ レジストリがあり、Docker コンテナ イメージと Helm Charts (まだベータ版) をサポートしています。 GitLab のセルフホスト バージョンを使用する場合、またはクラウドベースの GitLab を使用する場合は、セルフホストできます。 GitLab Container Registry の優れた機能の 1 つは、特定の正規表現パターンに一致するタグを削除するクリーンアップ戦略です。

あるいは、ユーザーは GitLab Package Registry を試すこともできます。これも無料で、Composer、Conan、Generic、Maven、npm、NuGet、PyPI、RubyGem をサポートしています。プロジェクトのリポジトリにすでに GitLab を使用している場合、これは間違いなく最適な選択です。

6. Google コンテナ レジストリ (GAR)

以前は Google Container Registry (GAR) が推奨オプションでしたが、GCR では重要なセキュリティ修正のみが提供されるため、2021 年夏以降、Google は顧客に Google Container Registry (GAR) への移行を依頼しています。本質的に、GAR は、Maven、npm、Python、Apt、さらには Yum パッケージなどのコンテナ イメージと非コンテナ成果物を処理する新しい方法です。

まず、GAR は継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインと簡単に統合できるため、コンテナの構築と展開が簡素化されます。さらに、イメージをスキャンして脆弱性を検出する機能も提供しており、ユーザーはこれを手動で有効にすることができます。

7. 港湾コンテナ登録簿

Harbor は 2014 年に作成され、2016 年にオープン ソース モデルに変換されました。間違いなく、VMware の最も成功したオープン ソース プロジェクトの 1 つです。 Harbor は、ユーザーが自分でインストール、構成、管理する必要があるコンテナ レジストリです。 Docker コンテナを使用して簡単にデプロイでき、Docker をサポートする任意の Linux ディストリビューションで使用できます。 Harbor は、Helm Chart を使用して Kubernetes クラスターにデプロイすることもできることに注意してください。

Harbor コンテナ レジストリは、コンテナ レジストリに期待される次のような機能のほとんどもサポートしています。

• 脆弱性スキャン
• ガベージコレクション
• クロスリージョンレプリケーション
• コンテンツの信頼

全体として、コンテナ レジストリをホストする予定がある場合、これは適切なオプションです。

8. レッドハットキー

Quay は 2012 年に最初に作成されましたが、過去数年間で大きな変化を遂げてきました。まず、このコンテナ レジストリは 2014 年に CoreOS に買収され、その後 2018 年に Red Hat に買収されました。

Quay、Project Quay、Red Hat Quay の違いを理解するのは非常に混乱を招く可能性があります。各項目の意味を簡単に説明します。

• Project Quay: これはスタンドアロンのコンテナ レジストリであり、Sonatype Nexus Repository OSS や Harbor に匹敵する Red Hat Quay のオープン ソース ディストリビューションです。
• Red Hat Quay.io: Red Hat Cloud Platform でホストされるエンタープライズ ソリューション。プライベート リポジトリの数に応じて料金が設定されます。しかし、そのパブリックリポジトリは無料のままです。
• Red Hat Quay: Red Hat OpenShift を通じて組み込みオペレーターとともに利用できる、プライベート クラウド デプロイメント用のエンタープライズ コンテナー レジストリ。

本質的に、Quay はさまざまな環境向けに複数の製品を提供しており、そのすべてにセキュリティ スキャン (Clair を使用)、リポジトリ ミラーリング、監査ログなどの豊富な機能が備わっています。

9.Sonatype Nexus リポジトリ OSS

Harbor と同様に、Nexus Repository は追加の言語パックもサポートする別の自己ホスト型コンテナー レジストリ ソリューションです。 Sonatype には、インフラストラクチャに簡単にデプロイできる Docker イメージがあります。このコンテナ レジストリは、いくつかの追加機能を備えた Nexus リポジトリのプロ バージョンを提供します。

パッケージ/コンテナ レジストリを自己ホストする場合、多くのシナリオをカバーする広範なドキュメントが提供されているため、これが適切なオプションになる可能性があります。

9つのコンテナレジストリの比較

結論は

要約すると、コンテナ レジストリを使用する際のコストと遅延を最小限に抑えるためには、ネットワークの近接性が重要となるため、考慮すべき重要な要素となります。

最後に、企業ではクラウド コンピューティング プロバイダーが提供するコンテナ レジストリを使用することをお勧めします。たとえば、インフラストラクチャが完全に AWS クラウド プラットフォームに基づいている場合は、AWS ECR を使用することをお勧めします。

これは、すべてのクラウド コンピューティング リソースが共通の認証モデルを共有し、イメージをあるクラウドから別のクラウドに移動する必要がないため、イメージの取得が高速になるためです。

コンテナ レジストリの選び方: Florian Pialoux によるトップ 9 の選択肢