Docker Hub の pull リクエスト制限に備え Google Cloud のデプロイを準備する
Google Cloud Japan Team
※この投稿は米国時間 2020 年 10 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。
Docker Hub は、公開コンテナ イメージのホスティングに広く使用されているレジストリです。今年の夏の初め、Docker は「無料プラン」ユーザーによるサービスへの pull リクエスト回数のレート制限を開始すると発表しました。匿名ユーザーによる pull リクエストでは、この制限は 6 時間あたり 100 件の pull リクエストになります。認証されたユーザーには、6 時間あたり 200 件の pull リクエストの制限があります。11 月 1 日にこの新しいレート制限が有効になると、Cloud Build での自動化された構築とデプロイのプロセスが中断されたり、Docker Hub からGoogle Kubernetes Engine（GKE）、Cloud Run または App Engine Flex にアーティファクトをデプロイする方法に支障をきたしたりする場合があります。
使用している Google Cloud サービスが Docker Hub からイメージを pull していることが把握されていないケースが多いことが、この状況をより困難なものとしています。たとえば、Dockerfile に「FROM debian:latest」のようなステートメントがあったり、Kubernetes Deployment のマニフェストに「image: postgres:latest」のようなステートメントがあったりする場合は、Docker Hub からイメージが直接 pull されています。これらのケースを特定するために、Google Cloud は Docker Hub のようなサードパーティのコンテナ レジストリからコードベースとワークロードをスキャンしてコンテナ イメージの依存関係を確認する手順を説明したガイドをご用意しました。
Google は、信頼性の高いワークロードと自動化プロセスを実行できるようサポートする取り組みを行っています。ブログ記事の残りの部分では、これらの新しい Docker Hub の pull レート制限がさまざまな Google Cloud サービス上で実行しているデプロイにどのような影響を与えるのかと、潜在的な影響を軽減するための戦略について説明します。この投稿は定期的に更新していきますので、今後も随時ご確認ください。
Kubernetes と GKE への影響
これらの Docker Hub の変更で特に影響を受ける可能性のあるグループの一つは、マネージド コンテナ サービスのユーザーです。他のマネージド Kubernetes プラットフォームと同様に、Docker Hub は GKE をデフォルトで匿名ユーザーとして扱います。これは、構成ファイルで Docker Hub の認証情報を指定していない限り、クラスタが IP ごとに 6 時間あたり 100 件のイメージ pull という新しいスロットルの対象となることを意味しています。また、GKE 上の多くの Kubernetes の Deployment では、公開イメージが使用されています。実際のところ、gcr.io など、コンテナ レジストリの接頭辞を持たないコンテナ名はすべて Docker Hub から pull されます。例としては、nginx や redis が含まれます。
Container Registry は、Google Cloud から特にリクエストの多い Docker Hub イメージのキャッシュをホストし、GKE はデフォルトでこのキャッシュを使用するように構成されています。これは、GKE ワークロードによるイメージの pull の大部分が Docker Hub の新しいレート制限の影響を受けることがないことを意味します。さらに、イメージが将来キャッシュに保存されない可能性を排除するために、依存関係を Container Registry に移行することをおすすめします。そうすることによって、管理下にあるレジストリからすべてのイメージを pull できるようになります。
その間、影響を受けているかどうかを確認するために、クラスタが消費する Docker Hub イメージのリストを生成できます。
使用しているイメージがキャッシュに含まれているかどうかを確認することができます。キャッシュは頻繁に変更されますが、簡単なコマンドで現在のイメージを確認できます。
キャッシュのヒット率を予測することは、特に使用方法が劇的に変わる可能性が高い時期には、非現実的ですが、Google では、キャッシュ内にあるほとんどのイメージがキャッシュに残るように、キャッシュの保持時間を増やしています。
GKE ノードには独自のローカル ディスクのキャッシュもあるため、Docker Hub の使用状況を確認する際には、GKE ノードから作成された一意のイメージの pull（キャッシュにないイメージ）の数だけを数えます。
限定公開クラスタの場合、すべてのイメージの pull は単一の NAT ゲートウェイを経由してルーティングされるため、クラスタ全体のイメージ pull の総数を考慮してください。
一般公開クラスタの場合、ノードごとに一意のイメージの pull 数を考慮するだけなので、少し余裕があります。一般公開のノードの場合、影響を受けるには一意で一般公開されキャッシュに保存されていないイメージが 6 時間あたり 100 件以上チャーンされる必要がありますが、これはかなり珍しいことです。
クラスタが影響を受ける可能性があると判断した場合は、Docker Hub 上のコンテナ イメージを参照するすべての Pod に対して Docker Hub の認証情報を使用して imagePullSecretsを追加することで、Docker Hub への認証ができます。
GKE は Docker Hub のレート制限の影響を受ける可能性のある Google Cloud サービスの一つですが、類似する Cloud Build、Cloud Run、App Engine など、コンテナ イメージに依存しているサービスはすべて影響を受ける可能性があります。
進むべき正しい道を見つける
有料の Docker Hub アカウントにアップグレードする
Docker Hub の新しいレート制限に対する最もシンプルで、しかしながら高価な解決策は、有料の Docker Hub アカウントにアップグレードすることです。そうすることを選択し、Cloud Build、Cloud Run on Anthos、または GKE を使用している場合は、認証情報を使って pull するようにランタイムを構成できます。以下に、それぞれのサービスの構成方法の手順を示します。
Container Registry への切り替え
この問題を回避するもう一つの方法は、使用するコンテナ アーティファクトを Docker Hub から Container Registry に移行することです。Container Registry は、イメージを Google Cloud Storage オブジェクトとして保存し、コンテナ イメージ管理を Google Cloud 環境全体の一部として取り入れることができます。さらに言えば、限定公開イメージ リポジトリを選択することで、組織のソフトウェア配信の方向性を制御できるようになります。
移行をサポートするために、前述のガイドでは、コンテナ イメージの依存関係を Docker Hub やその他のサードパーティのコンテナ イメージ レジストリから Container Registry にコピーする方法についても説明しています。これらの手順はすべてを網羅するわけではありませんのでご注意ください。コードベースの構造に基づいて調整する必要があります。
また、Google によってセキュリティ脆弱性に対するパッチが自動的に適用されるマネージド ベースイメージを使用できるため、プロジェクトのアップストリーム（GitHub など）から入手可能な最新のパッチを使用できます。これらのイメージは、GCP Marketplace で入手可能です。
変化を乗り切るためのサポート
Docker Hub の pull リクエストに対する新しいレート制限は、組織がコンテナベースのアプリケーションを構築してデプロイする方法に迅速かつ重大な影響を与えることになります。Google では、コンテナ形式とランタイムに関するオープンな業界標準を提供するコミュニティ、Open Container Initiative（OCI）とのパートナーシップにより、皆さまがこの変化を可能な限りスムーズに乗り切ることができるよう最善を尽くしています。
-Cloud CI / CD プロダクト リード Michael Winser
-ソリューション アーキテクト Dhaivat Pandit
