Quay IO について
はじめに
この包括的なガイドは、堅牢で機能豊富なコンテナーレジストリーサービス Quay.io を最大限に活用するために必要な知識とツールをユーザーに提供します。
第1章 Quay.io の概要
Quay.io はコンテナーイメージを保存およびビルドするためのレジストリーですが、コンテナーイメージとその他のアーティファクトの両方を配布するためにも使用できます。さまざまなユーザーのニーズに対応するために無料と有料の両方の層が提供されており、主に米国 (Amazon Web Services の us-east-1
リージョン) でホストされ、CDN エッジサーバーが世界中に分散されています。
Quay.io は柔軟性があり、使いやすく、ユーザーがコンテナーイメージをアップロードして管理できるようにします。開発者はプライベートリポジトリーを作成して、機密コードや独自コードを組織内で安全に保つことができます。さらに、ユーザーはアクセス制御を設定し、チームのコラボレーションを管理できるため、指定されたチームメンバー間でコンテナーイメージをシームレスに共有できます。
Quay.io は、統合イメージスキャナー Clair を介してコンテナーのセキュリティー問題を対処します。このサービスは、既知の脆弱性やセキュリティーの問題についてコンテナーイメージを自動的にスキャンし、潜在的なリスクに関する貴重な洞察を開発者に提供し、修復手順を提案します。
Quay.io は自動化に優れており、一般的な継続的インテグレーション/継続的デプロイメント (CI/CD) ツールおよびプラットフォームとの統合をサポートし、コンテナーのビルドおよびデプロイプロセスをシームレスに自動化を可能にします。その結果、開発者はワークフローを合理化し、手動介入を大幅に削減し、全体的な開発効率を向上させることができます。
Quay.io は、大規模と小規模の両方のデプロイメントのニーズに対応します。このプラットフォームは、大量のコンテナーイメージトラフィックを処理でき、コンテナーイメージをさまざまな地理的場所に配信するための効率的なレプリケーションおよび配布メカニズムを提供します。
Quay.io を使用すると、開発者は他のユーザーが共有しているビルド済みのパブリックコンテナーイメージのコレクションを見つけることができるため、プロジェクトに役立つツール、アプリケーション、サービスを見つけやすくなります。
第2章 Quay.io のサポート
テクニカルサポートは、Quay.io コンテナーレジストリーサービスの重要な側面であり、コンテナーイメージの管理だけでなく、ホストされるプラットフォームの機能と可用性の確保も支援します。
機能関連の問題を抱えるユーザーを支援するために、Red Hat は Quay.io の顧客にいくつかのリソースへのアクセスを提供しています。Red Hat ナレッジベース には、Red Hat の製品とテクノロジーの可能性を最大限に引き出す貴重なコンテンツが含まれています。ユーザーは、Red Hat 製品のインストール、設定、利用に関するベストプラクティスを概説する記事、製品ドキュメント、およびビデオをご利用になれます。また、既知の問題に対する解決策のハブとしても機能し、根本原因の簡潔な説明と修復手順を提供します。
さらに、Quay.io の顧客は、質問に対処し、問題のトラブルシューティングを行い、プラットフォームのエクスペリエンスを最適化するためのソリューションを提供するテクニカルサポートチームを頼ることができます。特定の機能の理解、設定のカスタマイズ、コンテナーイメージのビルドの問題の解決など、サポートチームは明確さと専門知識を持って各ステップをユーザーにガイドすることに専念しています。
有料サービスをお使いのお客様は、Quay.io ステータスページ に記載されていないサービスの中断やパフォーマンスの問題に関連するインシデント (可用性や機能に関する懸念など) について、Red Hat カスタマーポータル からテクニカルサポートチケットを発行できます。サービスインシデントは、プラットフォームの複数のユーザーに影響を及ぼす、計画外のサービスの中断またはサービス品質低下として定義されます。
この包括的な技術サポートシステムを導入することで、Quay.io はユーザーが自信を持ってコンテナーイメージを管理し、プラットフォームエクスペリエンスを最適化し、発生する可能性のある課題を克服できるようにします。
関連情報
現在の Red Hat Quay および Quay.io ユーザーは、トラブルシューティングとサポートの詳細は、Red Hat Quay トラブルシューティングガイド を参照してください。
第3章 Quay.io ユーザーインターフェイスの概要
Quay.io のユーザーインターフェイス (UI) は、プラットフォームのエコシステム内でコンテナーイメージを管理および操作するためのユーザーのゲートウェイとして機能する基本コンポーネントです。Quay.io の UI は、直感的でユーザーフレンドリーなインターフェイスを提供するように設計されており、あらゆるスキルレベルのユーザーが Quay.io の機能を簡単に操作して利用できるようになります。
このドキュメントセクションは、Quay.io の UI の主要な要素と機能をユーザーに紹介することを目的としています。UI のレイアウト、ナビゲーション、主要な機能などの重要な側面をカバーし、ユーザーが Quay.io のコンテナーレジストリーサービスを探索して最大限に活用するための強固な基盤を提供します。
このドキュメント全体を通じて、次のトピックに関する段階的な手順、視覚的補助、および実践的な例が提供されます。
- アプリケーションとリポジトリーの探索
- Quay.io チュートリアルの使用
- 価格と Quay.io プラン
- サインインして Quay.io 機能を使用する
このドキュメントをまとめると、ユーザーが UI の微妙な違いをすぐに把握し、Quay.io を使用してコンテナー化の手順をうまく進めることができるようになります。
3.1. Quay.io ランディングページ
Quay.io ランディングページは、ユーザーが提供されるコンテナーレジストリーサービスにアクセスするための中央ハブとして機能します。このページには、ユーザーがコンテナーイメージを簡単に安全に保存、構築、デプロイできるようガイドするための重要な情報とリンクが提供されます。
Quay.io のランディングページには、次のリソースへのリンクが含まれています。
ランディングページには、定期メンテナンスに関する情報も含まれています。定期メンテナンス中、Quay.io は読み取り専用モードで動作し、プル機能は通常どおり動作します。スケジュールされたメンテナンス中は、プッシュとビルドは動作しなくなります。Quay.io の Status ページ に移動し、Subscribe To Updates をクリックすると、Quay.io のメンテナンスに関する更新を購読できます。
ランディングページには、次のリソースへのリンクも含まれています。
- Documentation。このページでは、Quay.io の使用に関するドキュメントを提供します。
- Terms。このページでは、Red Hat Online Services に関する法的情報を提供します。
- Privacy。このページには、Red Hat のプライバシーに関する声明に関する情報が記載されています。
- Security。このページでは、SSL/TLS、暗号化、パスワード、アクセス制御、ファイアウォール、データ復元力など、Quay.io のセキュリティーに関する情報を提供します。
- About。このページには、使用されているパッケージとプロジェクトに関する情報、および製品の簡単な歴史が含まれています。
- Contact。このページには、サポートと Red Hat サポートチームへの連絡先に関する情報が含まれています。
- All Systems Operational。このページには、Quay.io のステータスとメンテナンスの簡単な履歴に関する情報が含まれています。
- Cookies。このリンクをクリックすると、ポップアップボックスが表示され、Cookie の設定を行うことができます。
また、オンプレミスで Red Hat Quay を試す または クラウドで Red Hat Quay を試す に関する情報も表示され、Pricing ページにリダイレクトされます。各オプションには無料トライアルが用意されています。
3.1.1. Quay.io アカウントの作成
Quay.io の新規ユーザーは、Red Hat アカウントに登録 し、Quay.io ユーザー名を作成する必要があります。これらのアカウントは相関していますが、次の 2 つの明確な違いがあります。
- Quay.io アカウントを使用して、コンテナーイメージまたは Open Container Initiative イメージを Quay.io にプッシュおよびプルしてイメージを保存できます。
- Red Hat アカウントは、ユーザーに Quay.io ユーザーインターフェイスへのアクセスを提供します。有料サービスをご利用の場合は、このアカウントを使用して Red Hat Ecosystem Catalog のイメージにアクセスすることもでき、Quay.io リポジトリーにプッシュできます。
ユーザーはまず Red Hat アカウントに登録し、次に Quay.io アカウントを作成する必要があります。ユーザーが Quay.io のすべての機能を適切に使用するには、両方のアカウントが必要です。
3.1.1.1. Red Hat アカウントの登録
Quay.io の Red Hat アカウントを登録するには、次の手順を使用します。
手順
- Red Hat カスタマーポータル に移動します。
- ナビゲーションペインで、Log In をクリックします。
- ログインページに移動したら、Register for a Red Hat Account をクリックします。
- Red Hat のログイン ID を入力します。
- パスワードを入力します。
次の個人情報を入力します。
- 名
- 姓
- メールアドレス
- 電話番号
お住まいの国または地域に応じた次の連絡先情報を入力してください。以下に例を示します。
- 国/地域
- 住所
- 郵便番号
- 市区町村
- 国
- Red Hat の利用規約を選択して同意します。
- Create my account をクリックします。
- Quay.io に移動してログインします。
3.1.1.2. Quay.io ユーザーアカウントの作成
Quay.io ユーザーアカウントを作成するには、次の手順を使用します。
前提条件
- Red Hat アカウントが作成されている。
手順
- 必要に応じて、I am not a robot をクリックして確認し、キャプチャーを解決します。Confirm Username ページにリダイレクトされます。
- Confirm Username ページで、ユーザー名を入力します。デフォルトでは、ユーザー名が生成されます。同じユーザー名がすでに存在する場合は、一意になるように最後に番号が追加されます。このユーザー名は、Quay Container Registry の namespace として使用されます。
- ユーザー名を決定したら、Confirm Username をクリックします。Quay.io Repositories ページにリダイレクトされます。このページは、ユーザーがリポジトリーに簡単にアクセスして管理できる専用ハブとして機能します。このページから、ユーザーはコンテナーイメージと関連リソースを効率的に整理、移動、操作できます。
3.1.1.3. Quay.io シングルサインオンのサポート
Red Hat シングルサインオン (SSO) は Quay.io で使用できます。Quay.io で Red Hat SSO をセットアップするには、次の手順を使用します。ほとんどのユーザーにとって、これらのアカウントはすでにリンクされています。ただし、一部の従来の Quay.io ユーザーの場合は、この手順が必要になる場合があります。
前提条件
- Quay.io アカウントが作成されている。
手順
- Quay.io の Recovery ページ に移動します。
- ユーザー名とパスワードを入力し、Sign in to Quay Container Registry をクリックします。
- ナビゲーションペインで、ユーザー名 → Account Settings をクリックします。
- ナビゲーションウィンドウで、External Logins and Applications をクリックします。
- Attach to Red Hat をクリックします。
すでに Red Hat SSO にサインインしている場合、アカウントは自動的にリンクされます。それ以外の場合は、Red Hat ログイン名または電子メールとパスワードを入力して、Red Hat SSO にサインインするように求められます。または、最初に新しいアカウントを作成しないといけない場合があります。
Red Hat SSO にサインインした後、ログインページから Red Hat アカウントを使用して Quay.io に対して認証することを選択できます。
関連情報
- 詳細は、Quay.io Now Supports Red Hat Single Sign On を参照してください。
3.1.2. Quay.io を探索する
Quay.io の Explore ページは、ユーザーが Quay.io コミュニティーによって共有されているコンテナーイメージ、アプリケーション、およびリポジトリーの膨大なコレクションを詳しく調べることができる貴重なハブです。直感的でユーザーフレンドリーなデザインの Explore ページには強力な検索機能があり、ユーザーはコンテナー化されたアプリケーションやリソースを簡単に見つけることができます。
3.1.3. Quay.io を試す (非推奨)
Red Hat Quay チュートリアルは現在非推奨となっており、v2 UI が一般公開 (GA) されると削除される予定です。
Quay.io の Tutorial ページでは、ユーザーと Quay.io コンテナーレジストリーサービスの概要が提供されます。Continue Tutorial をクリックすると、Quay.io で次の機能を実行する方法を学ぶことができます。
- Docker CLI から Quay Container Registry にログインする
- コンテナーを起動する
- コンテナーからイメージを作成する
- リポジトリーを Quay Container Registry にプッシュする
- リポジトリーを表示する
- ビルドトリガーをセットアップする
- リポジトリーの権限を変更する
3.1.4. Quay.io の価格に関する情報
無料利用枠に加えて、Quay.io は特典を強化したいくつかの有料プランも提供しています。
Quay.io の Pricing ページには、Quay.io プランと各プランの関連価格に関する情報が表示されます。各段階のコストは、Pricing ページで確認できます。すべての Quay.io プランには次の利点が含まれます。
- 継続的インテグレーション
- パブリックリポジトリー
- ロボットアカウント
- チーム
- SSL/TLS 暗号化
- ロギングおよび監査
- 請求書履歴
Quay.io サブスクリプションは、Stripe 支払い処理プラットフォームによって処理されます。Quay.io にサインアップするには、有効なクレジットカードが必要です。
Quay.io にサインアップするには、次の手順を実行します。
手順
- Quay.io の Pricing ページ に移動します。
プラン (例: Small) を決定し、Buy Now をクリックします。Create New Organization ページにリダイレクトされます。以下の情報を入力します。
- 組織名
- 組織の電子メール
- オプション: たとえば、Small より大きいプランが必要な場合は、別のプランを選択できます。
- そのキャプチャーを解決し、Create Organization を選択します。
Stripe にリダイレクトされます。以下の情報を入力します。
- MM/YY および CVC を含む カード情報
- カードの名前
- 国または地域
- 郵便番号 (該当する場合)
- 情報を保存したい場合は、チェックボックスをオンにします。
- 電話番号
- すべてのボックスに入力したら、Subscribe をクリックします。
第4章 Red Hat Quay のテナンシーモデル
Quay.io でコンテナーイメージを追加するリポジトリーを作成する前に、そのリポジトリーをどのように構成するかを検討する必要があります。Quay.io では、各リポジトリーに Organization または User のいずれかとの接続が必要です。この関係により、リポジトリーの所有権とアクセス制御が定義されます。
4.1. テナンシーモデル
- 組織 は、単一のユーザーに属さない共通の名前空間のもとでリポジトリーを共有する方法を提供します。このようなリポジトリーは、会社などの共有設定内の複数のユーザーに属します。
- チーム は、組織から権限を委任する方法を提供します。権限は、グローバルレベル (たとえば、すべてのリポジトリー全体) で設定することも、特定のリポジトリーに対して設定することもできます。特定のユーザーのセットまたはグループに対して設定することもできます。
-
ユーザー は、Web UI を介してレジストリーにログインすることも、Podman などのクライアントを使用して、それぞれのログインコマンド
($ podman login
など) を使用してレジストリーにログインすることもできます。各ユーザーには、ユーザー名前空間が自動的に割り当てられます。たとえば、<quay-server.example.com>/<user>/<username>
、Quay.io を使用している場合はquay.io/<username>
です。 - ロボットアカウント は、パイプラインツールなどの人間以外のユーザーにリポジトリーへの自動アクセスを提供します。ロボットアカウントは OpenShift Container Platform の サービスアカウント に似ています。リポジトリー内のロボットアカウントに権限を付与するには、そのアカウントを他のユーザーやチームと同様に追加します。
4.2. キーへのログイン
Quay.io のユーザーアカウントは、プラットフォームの機能への認証アクセス権を持つ個人を表します。このアカウントを通じて、リポジトリーの作成と管理、コンテナーイメージのアップロードと取得、およびこれらのリソースへのアクセス権の制御を行うことができます。このアカウントは、Quay.io 内でのコンテナーイメージの管理を組織化および監視するうえで極めて重要です。
Quay.io のすべての機能でユーザーのログインが必要なわけではありません。たとえば、プルしているイメージがパブリックリポジトリーから取得されている限り、ログインせずに Quay.io から匿名でイメージをプルできます。
ユーザーは次の 2 つの方法で Quay.io にログインできます。
Quay.io を通じてログインします。
この方法では、従来の UI と、PatternFly UI の原則に準拠したベータ UI 環境を使用するかをユーザーが選択できます。
Red Hat Hybrid Cloud Console からログインします。
この方法は、認証に Red Hat SSO を使用するものであり、Red Hat が提供するパブリックマネージドサービスです。この方法では、ユーザーは 常に ログインする必要があります。他のマネージドサービスと同様に、Red Hat Hybrid Cloud Console の Quay は、PatternFly UI 原則に準拠することでユーザーエクスペリエンスを強化します。
Quay.io を直接使用する場合と、Red Hat Hybrid Cloud Console で Quay を使用する場合の違いは、無料枠のユーザーを含め、ごくわずかです。Quay.io を直接使用している場合でも、Hybrid Cloud Console 上で使用している場合でも、リポジトリーへのプッシュなど、ログインが必要な機能には Quay.io ユーザー名の仕様が使用されます。
4.2.1. Quay.io へのログイン
Quay.io にログインするには、次の手順を使用します。
前提条件
- Red Hat アカウントと Quay.io アカウントを作成している。詳細は、「Quay.io アカウントの作成」を参照してください。
手順
- Quay.io に移動します。
- ナビゲーションペインで、Sign In を選択し、Red Hat 認証情報を使用してログインします。
初めてログインする場合は、自動生成されたユーザー名を確認する必要があります。Confirm Username をクリックしてログインします。
Quay.io リポジトリーのランディングページにリダイレクトされます。
4.2.2. Hybrid Cloud Console を介した Quay へのログイン
前提条件
- Red Hat アカウントと Quay.io アカウントを作成している。詳細は、「Quay.io アカウントの作成」を参照してください。
手順
Red Hat Hybrid Cloud Console で Quay に移動し、Red Hat アカウントを使用してログインします。Quay リポジトリーのランディングページにリダイレクトされます。
第5章 Quay.io の組織の概要
Quay.io の組織は、ユーザー、リポジトリー、およびチームのグループです。レジストリー内のアクセス制御と権限を整理および管理する手段として機能します。組織を使用すると、管理者はユーザーとチームにロールと権限を割り当てることができます。組織に関するその他の有用な情報を以下に示します。
- 組織を別の組織内に組み込むことはできません。組織を細分化するには、チームを使用します。
組織にユーザーを直接含めることはできません。まずチームを追加してから、各チームに 1 人以上のユーザーを追加する必要があります。
注記個々のユーザーは、組織内の特定のリポジトリーに追加できます。そのため、これらのユーザーは、Repository Settings ページのどのチームのメンバーでもありません。Teams and Memberships ページの Collaborators View に、特に組織に所属する必要がなく、その組織内の特定のリポジトリーに直接アクセスできるユーザーが表示されます。
- チームは、リポジトリーおよび関連イメージを使用する単なるメンバーとして、または組織を管理するための特別な権限を持つ管理者として、組織内に設定できます。
ユーザーは自分の組織を作り、コンテナーイメージのリポジトリーを共有できます。これは Quay.io の UI から実行できます。
5.1. UI を使用した組織の作成
UI を使用して新しい組織を作成するには、次の手順に従います。
手順
- Red Hat Quay レジストリーにログインします。
- ナビゲーションペインで Organization をクリックします。
- Create Organization をクリックします。
-
Organization Name (
testorg
など) を入力します。 - Organization Email を入力します。
- Create をクリックします。
これで、サンプルの組織が Organizations ページの下に表示されます。
5.2. 組織の設定
Quay.io では、UI を使用していくつかの基本的な組織設定を調整できます。これには、組織に関連付けられたメールアドレスなどの一般設定の調整や、タグが完全に削除された後にガベージコレクションされるタイミングを管理者が調整できる タイムマシン 設定が含まれます。
v2 UI を使用して組織の設定を変更するには、次の手順に従います。
手順
- v2 UI で、Organizations をクリックします。
-
ロボットアカウントを作成する組織の名前をクリックします (例:
test-org
)。 - Settings タブをクリックします。
- オプション: 組織に関連付けられたメールアドレスを入力します。
オプション: Time Machine 機能に割り当てる時間を次のいずれかに設定します。
- A few seconds
- A day
- 7 days
- 14 days
- A month
- Save をクリックします。
第6章 Red Hat Quay リポジトリーの概要
リポジトリーは、関連するコンテナーイメージのセットを一元的に保存するための場所を提供します。これらのイメージを使用して、アプリケーションとその依存関係を標準化された形式で構築できます。
リポジトリーは名前空間を使用して整理します。名前空間には、それぞれ複数のリポジトリーを含めることができます。たとえば、個人プロジェクト用の名前空間、会社用の名前空間、または組織内の特定のチーム用の名前空間を設定できます。
有料プランでは、Quay.io はユーザーにリポジトリーへのアクセス制御を提供します。リポジトリーをパブリックにすると、誰でもリポジトリーからイメージをプルまたはダウンロードできるようになります。リポジトリーをプライベートにすると、許可されたユーザーまたはチームのみにアクセスが制限されます。
Quay.io の無料利用枠では、プライベートリポジトリーは許可されません。プライベートリポジトリーを作成するには、Quay.io の有料層にアップグレードする必要があります。詳細は、「Quay.io の価格に関する情報」を参照してください。
Quay.io でリポジトリーを作成するには 2 つの方法があります。適切な podman
コマンドを使用してイメージをプッシュする方法と、Quay.io の UI を使用する方法です。UI を使用すると、リポジトリーを削除することもできます。
最初に UI でリポジトリーを作成せずにコマンドラインインターフェイス (CLI) を介してイメージをプッシュすると、プランに関係なく、作成されたリポジトリーは Private に設定されます。
イメージをプッシュする前に、Quay.io UI でリポジトリーを作成することを推奨します。Quay.io はプランのステータスをチェックし、プランがアクティブでない場合はプライベートリポジトリーの作成を許可しません。
6.1. UI を使用したリポジトリーの作成
Quay.io UI を使用してリポジトリーを作成するには、次の手順を実行します。
手順
v2 UI を使用してリポジトリーを作成するには、次の手順を実行します。
手順
- ナビゲーションペインで Repositories をクリックします。
- Create Repository をクリックします。
名前空間 (例: quayadmin) を選択し、リポジトリー名 (例:
testrepo
) を入力します。重要リポジトリー名に単語 *
build
*trigger
*tag
*notification
は使用しないでください。これらの単語をリポジトリー名に使用すると、ユーザーがリポジトリーにアクセスできなくなり、リポジトリーを完全に削除できなくなります。このようなリポジトリーを削除しようとすると、
Failed to delete repository <repository_name>, HTTP404 - Not Found.
エラーが返されます。Create をクリックします。
これで、サンプルリポジトリーが Repositories ページの下に表示されるはずです。
- オプション: リポジトリーを非公開に設定するには、Settings → Repository visibility → Make private をクリックします。
6.2. Podman を使用したリポジトリーの作成
適切な認証情報がある場合は、Podman を使用して、Quay.io インスタンスにまだ存在しないリポジトリーにイメージを プッシュ できます。イメージのプッシュとは、コンテナーイメージをローカルシステムまたは開発環境から Quay.io などのコンテナーレジストリーにアップロードするプロセスを指します。イメージをレジストリーにプッシュすると、リポジトリーが作成されます。最初に UI でリポジトリーを作成せずに、コマンドラインインターフェイス (CLI) を介してイメージをプッシュすると、作成されたリポジトリーは Private に設定されます。
最初に UI でリポジトリーを作成せずにコマンドラインインターフェイス (CLI) を介してイメージをプッシュすると、プランに関係なく、作成されたリポジトリーは Private に設定されます。
イメージをプッシュする前に、Quay.io UI でリポジトリーを作成することを推奨します。Quay.io はプランのステータスをチェックし、プランがアクティブでない場合はプライベートリポジトリーの作成を許可しません。
イメージをプッシュしてイメージリポジトリーを作成するには、次の手順を実行します。
前提条件
-
podman
CLI をダウンロードしてインストールした。 - レジストリーにログインしている。
- イメージ (busybox など) をプルした。
手順
サンプルレジストリーからサンプルページを取得します。以下に例を示します。
$ podman pull busybox
出力例
Trying to pull docker.io/library/busybox... Getting image source signatures Copying blob 4c892f00285e done Copying config 22667f5368 done Writing manifest to image destination Storing signatures 22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9
ローカルシステム上のイメージに、新しいリポジトリーとイメージ名をタグ付けします。以下に例を示します。
$ podman tag docker.io/library/busybox quay.io/quayadmin/busybox:test
イメージをレジストリーにプッシュします。この手順の後に、ブラウザーを使用して、リポジトリーでタグ付けされたイメージを確認できます。
$ podman push --tls-verify=false quay.io/quayadmin/busybox:test
出力例
Getting image source signatures Copying blob 6b245f040973 done Copying config 22667f5368 done Writing manifest to image destination Storing signatures
6.3. UI を使用したリポジトリーの削除
UI 上で直接リポジトリーを削除できます。
前提条件
- リポジトリーが作成済みである。
手順
-
v2 UI の Repositories ページで、削除するリポジトリーのボックスをチェックします (例:
quayadmin/busybox
)。 - Actions ドロップダウンメニューをクリックします。
- Delete をクリックします。
ボックスに confirm と入力してから、Delete をクリックします。
削除後、Repositories ページに戻ります。
6.4. ユーザー設定
User Settings ページでは、電子メールアドレス、パスワード、アカウントタイプの設定、デスクトップ通知の設定、アバターの選択、アカウントの削除、タイムマシン 設定の調整、および請求情報の表示を行う方法がユーザーに提供されます。
6.4.2. ユーザー設定の調整
ユーザー設定を調整するには、次の手順を使用します。
手順
- 電子メールアドレスを変更するには、Email Address で現在の電子メールアドレスを選択します。ポップアップウィンドウで新しい電子メールアドレスを入力し、Change Email をクリックします。変更が適用される前に、確認メールが送信されます。
- パスワードを変更するには、Change password をクリックします。両方のボックスに新しいパスワードを入力し、Change Password をクリックします。
- Individual Account をクリックするか、Account Type の横のオプションをクリックして、アカウントの種類を変更します。場合によっては、アカウントの種類を変更する前に組織を離れないといけない場合があります。
- デスクトップ通知の横にあるオプションをクリックして、Desktop Notifications を調整します。ユーザーはこの機能を有効または無効にできます。
Begin deletion をクリックしてアカウントを削除できます。アクティブなプランがある場合、または自分が唯一の管理者である組織のメンバーである場合は、アカウントを削除できません。namespace を入力して削除を確認する必要があります。
重要アカウントを削除すると元に戻すことはできず、リポジトリー、作成されたビルドトリガー、通知を含むアカウントのデータがすべて削除されます。
- Time Machine の横にあるドロップボックスをクリックして、タイムマシン 機能を設定できます。この機能は、タグが削除された後、ガベージコレクションが行われるまでにタイムマシンでタグにアクセスできるようになる時間を指定します。時間を選択したら、Save Expiration Time をクリックします。
6.4.3. 請求情報
User Settings で請求情報を確認できます。このセクションでは、次の情報が提供されます。
- Current Plan。このセクションでは、サインアップしている現在の Quay.io プランを示します。所有しているプライベートリポジトリーの量も表示されます。
- Invoices。有料プランを使用している場合は、View Invoices をクリックして請求書のリストを表示できます。
- Receipts。有料プランを使用している場合は、支払いの領収書を自分または別のユーザーに電子メールで送信するか、領収書を完全にオプトアウトするかを選択できます。
第7章 Red Hat Quay のロボットアカウントの概要
ロボットアカウントは、Quay.io レジストリー内のリポジトリーへの自動アクセスを設定するために使用されます。ロボットアカウントは OpenShift Container Platform のサービスアカウントに似ています。
ロボットアカウントを設定すると、以下が実行されます。
- ロボットアカウントに関連付けられた認証情報が生成されます。
- ロボットアカウントがイメージをプッシュおよびプルできるリポジトリーとイメージが特定されます。
- 生成された認証情報をコピー/ペーストして、Docker、Podman、Kubernetes、Mesos などのさまざまなコンテナークライアントで使用し、定義された各リポジトリーにアクセスできます。
各ロボットアカウントは、1 つのユーザー名前空間または組織に制限されます。たとえば、ロボットアカウントは、ユーザー quayadmin
にすべてのリポジトリーへのアクセスを提供できます。しかし、ユーザーのリポジトリーリストにないリポジトリーへのアクセスは提供できません。
ロボットアカウントは、Red Hat Quay UI を使用して作成することも、Red Hat Quay API を使用して CLI 経由で作成することもできます。作成後、Red Hat Quay 管理者は、キーレス認証などの Robot Accounts のより高度な機能を活用できます。
7.1. UI を使用したロボットアカウントの作成
v2 UI を使用してロボットアカウントを作成するには、次の手順を実行します。
手順
- v2 UI で、Organizations をクリックします。
-
ロボットアカウントを作成する組織の名前をクリックします (例:
test-org
)。 - Robot accounts タブ → Create robot account をクリックします。
-
Provide a name for your robot account ボックスに、
robot1
などの名前を入力します。ロボットアカウントの名前は、ユーザー名とロボットの名前を組み合わせたものになります (例:quayadmin+robot1
)。 オプション: 必要に応じて、以下のオプションを使用できます。
- ロボットアカウントをチームに追加します。
- ロボットアカウントをリポジトリーに追加します。
- ロボットアカウントの権限を調整します。
Review and finish ページで、入力した情報を確認してから、Review and finish をクリックします。Successfully created robot account with robot name: <organization_name> + <robot_name> というアラートが表示されます。
また、別のロボットアカウントと同じ名前でロボットアカウントを作成しようとすると、Error creating robot account というエラーメッセージが表示される場合があります。
- オプション: Expand または Collapse をクリックすると、ロボットアカウントの説明情報を表示できます。
- オプション: 縦の省略記号メニュー → Set repository permissions をクリックして、ロボットアカウントのパーミッションを変更できます。Successfully updated repository permission というメッセージが表示されます。
オプション: ロボットアカウントの名前をクリックすると、次の情報を取得できます。
- Robot Account: ロボットアカウントのトークンを取得するには、これを選択します。Regenerate token now をクリックすると、トークンを再生成できます。
- Kubernetes Secret: Kubernetes プルシークレット YAML ファイルの形式で認証情報をダウンロードするには、これを選択します。
-
Podman: 認証情報を含む完全な
podman login
コマンドラインをコピーするには、これを選択します。 -
Docker Configuration: 認証情報を含む完全な
docker login
コマンドラインをコピーするには、これを選択します。
7.2. ロボットアカウントのリポジトリーアクセスの一括管理
Red Hat Quay v2 UI を使用してロボットアカウントのリポジトリーアクセスを一括管理するには、次の手順を実行します。
前提条件
- ロボットアカウントを作成している。
- 1 つの組織に複数のリポジトリーを作成している。
手順
- Red Hat Quay v2 UI ランディングページで、ナビゲーションペインの Organizations をクリックします。
- Organizations ページで、複数のリポジトリーを持つ組織の名前を選択します。単一組織内のリポジトリーの数は、Repo Count 列で確認できます。
- 組織のページで、Robot accounts をクリックします。
- 複数のリポジトリーにロボットアカウントを追加する場合は、縦の省略記号アイコン → Set repository permissions をクリックします。
Set repository permissions ページで、ロボットアカウントを追加するリポジトリーのチェックボックスをオンにします。以下に例を示します。
- ロボットアカウントの権限を設定します (例: None、Read、Write、Admin)。
- save をクリックします。Success alert: Successfully updated repository permission というアラートが Set repository permissions ページに表示され、変更が確認されます。
- Organizations → Robot accounts ページに戻ります。これで、ロボットアカウントの Repositories 列に、ロボットアカウントが追加されたリポジトリーの数が表示されます。
7.3. UI を使用したロボットアカウントの無効化
Red Hat Quay 管理者は、ユーザーに新しいロボットアカウントの作成を禁止することでロボットアカウントを管理できます。
リポジトリーのミラーリングにはロボットアカウントが必要です。ROBOTS_DISALLOW
設定フィールドを true
に設定すると、ミラーリング設定が破棄されます。リポジトリーをミラーリングするユーザーは、config.yaml
ファイルで ROBOTS_DISALLOW
を true
に設定しないでください。これは既知の問題であり、Red Hat Quay の今後のリリースで修正される予定です。
ロボットアカウントの作成を無効にするには、次の手順を実行します。
前提条件
- 複数のロボットアカウントを作成している。
手順
config.yaml
フィールドを更新してROBOTS_DISALLOW
変数を追加します。次に例を示します。ROBOTS_DISALLOW: true
- Red Hat Quay デプロイメントを再起動します。
検証: 新しいロボットアカウントの作成
- Red Hat Quay リポジトリーに移動します。
- リポジトリーの名前をクリックします。
- ナビゲーションウィンドウで、Robot Accounts をクリックします。
- Create Robot Account をクリックします。
-
ロボットアカウントの名前を入力します (例:
<organization-name/username>+<robot-name>)
。 -
Create robot account をクリックして作成を確定します。次のメッセージが表示されます。
Cannot create robot account.Robot accounts have been disabled.Please contact your administrator.
検証: ロボットアカウントへのログイン
コマンドラインインターフェイス (CLI) で、次のコマンドを入力してロボットアカウントの 1 つとしてログインを試みます。
$ podman login -u="<organization-name/username>+<robot-name>" -p="KETJ6VN0WT8YLLNXUJJ4454ZI6TZJ98NV41OE02PC2IQXVXRFQ1EJ36V12345678" <quay-server.example.com>
次のエラーメッセージが返されます。
Error: logging into "<quay-server.example.com>": invalid username/password
log-level=debug
フラグを渡すと、ロボットアカウントが無効化されたことを確認できます。$ podman login -u="<organization-name/username>+<robot-name>" -p="KETJ6VN0WT8YLLNXUJJ4454ZI6TZJ98NV41OE02PC2IQXVXRFQ1EJ36V12345678" --log-level=debug <quay-server.example.com>
... DEBU[0000] error logging into "quay-server.example.com": unable to retrieve auth token: invalid username/password: unauthorized: Robot accounts have been disabled. Please contact your administrator.
7.4. UI を使用したロボットアカウントの削除
Red Hat Quay UI を使用してロボットアカウントを削除するには、次の手順に従います。
手順
- Red Hat Quay レジストリーにログインします。
- ロボットアカウントがある組織の名前をクリックします。
- Robot accounts をクリックします。
- 削除するロボットアカウントのボックスをチェックします。
- 縦の省略記号メニューをクリックします。
- Delete をクリックします。
-
テキストボックスに
confirm
と入力し、Delete をクリックします。
7.5. ロボットアカウントによるキーレス認証
Red Hat Quay の以前のバージョンでは、ロボットアカウントトークンは、削除または再生成されない限り、トークンの有効期間中有効でした。有効期限のないトークンは、長期的なパスワードの保存や、削除、再生成、新規認証トークンを管理を望まないユーザーにとって、セキュリティー上の問題を引き起こす可能性があります。
Red Hat Quay 3.14 では、Red Hat Quay 管理者は、Red Hat Single Sign-On (Keycloak プロジェクトに基づく) または Microsoft Entra ID を使用して、外部 OIDC トークンを有効期限が短いまたは 一時的 なロボットアカウントトークンと交換できるようになります。これにより、ロボットアカウントは 1 時間有効のトークンを活用できるようになります。このようなトークンは定期的に更新され、個々のトランザクションの認証に使用できます。
この機能により、トークンを 1 時間後に削除することで、ロボットトークンの漏洩の可能性を軽減し、Red Hat Quay レジストリーのセキュリティーが大幅に向上します。
ロボットアカウントを使用したキーレス認証の設定には、ロボットフェデレーションの設定、OIDC プロバイダーからの OAuth2 トークンの生成、および OAuth2 トークンとロボットアカウントアクセストークンの交換を必要とする複数の手順があります。
7.5.1. Red Hat Sign Sign-On による OAuth2 トークンの生成
次の手順では、Red Hat Single Sign-On を使用して OAuth2 トークンを生成する方法を示します。OIDC プロバイダーに応じて、これらの手順は異なります。
手順
Red Hat Single Sign-On UI の場合は、以下を行います。
- Clients をクリックし、ユーザーの認証を要求できるアプリケーションまたはサービスの名前をクリックします。
クライアントの Settings ページで、次のオプションが設定または有効化されていることを確認します。
- クライアント ID
- 有効なリダイレクト URI
- クライアント認証
- 認可
- Standard flow
Direct access grants
注記設定はセットアップによって異なる場合があります。
- Credentials ページで、今後使用する時のために クライアントシークレット を保存します。
-
Users ページで、Add user をクリックし、ユーザー名 (例:
service-account-quaydev
) を入力します。次に、Create をクリックします。 - Users ページで、ユーザーの名前 (例: service-account-quaydev) をクリックします。
- Credentials タブ → Set password をクリックし、ユーザーのパスワードを入力します。必要に応じて、Temporary オプションを選択して、このパスワードを一時的なものにすることができます。
Realm settings タブ → OpenID Endpoint Configuration をクリックします。
/protocol/openid-connect/token
エンドポイントを保存します。以下に例を示します。http://localhost:8080/realms/master/protocol/openid-connect/token
Web ブラウザーで、次の URL に移動します。
http://<keycloak_url>/realms/<realm_name>/protocol/openid-connect/auth?response_type=code&client_id=<client_id>
- プロンプトが表示されたら、service-account-quaydev ユーザーと設定した一時パスワードを使用してログインします。必要な情報を入力し、必要に応じて永続的なパスワードを設定してログインを完了します。
クライアントに提供された URI アドレスにリダイレクトされます。以下に例を示します。
https://localhost:3000/cb?session_state=5c9bce22-6b85-4654-b716-e9bbb3e755bc&iss=http%3A%2F%2Flocalhost%3A8080%2Frealms%2Fmaster&code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43
アドレスに記載されている
code
をメモしてください。以下に例を示します。code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43
注記これは 1 回のみ使用できる一時コードです。必要に応じて、ページを更新するか、URL に再度アクセスして別のコードを取得できます。
ターミナルで、次の
curl -X POST
コマンドを使用して一時的な OAuth2 アクセストークンを生成します。$ curl -X POST "http://localhost:8080/realms/master/protocol/openid-connect/token" 1 -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=quaydev" 2 -d "client_secret=g8gPsBLxVrLo2PjmZkYBdKvcB9C7fmBz" 3 -d "grant_type=authorization_code" -d "code=ea5b76eb-47a5-4e5d-8f71-0892178250db.5c9bce22-6b85-4654-b716-e9bbb3e755bc.cdffafbc-20fb-42b9-b254-866017057f43" 4
出力例
{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJTVmExVHZ6eDd2cHVmc1dkZmc1SHdua1ZDcVlOM01DN1N5T016R0QwVGhVIn0...", "expires_in":60,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJiNTBlZTVkMS05OTc1LTQwMzUtYjNkNy1lMWQ5ZTJmMjg0MTEifQ.oBDx6B3pUkXQO8m-M3hYE7v-w25ak6y70CQd5J8f5EuldhvTwpWrC1K7yOglvs09dQxtq8ont12rKIoCIi4WXw","token_type":"Bearer","not-before-policy":0,"session_state":"5c9bce22-6b85-4654-b716-e9bbb3e755bc","scope":"profile email"}
-
前の手順の
access_token
を保存します。これは次の手順で Red Hat Quay ロボットアカウントトークンと交換されます。
7.5.2. Red Hat Quay v2 UI を使用してロボットアカウントフェデレーションを設定する
次の手順では、Red Hat Quay v2 UI を使用してロボットアカウントフェデレーションをセットアップする方法を示します。この手順では、Keycloak プロジェクトに基づく Red Hat Single Sign-On を使用します。これらの手順と、ロボットアカウントフェデレーションのセットアップに使用される情報は、OIDC プロバイダーによって異なります。
前提条件
-
組織を作成している。次の例では
fed_test
を使用します。 -
ロボットアカウントを作成している。次の例では、
fest_test+robot1
を使用します。 - Red Hat Quay デプロイメント用に OIDC を設定している。次の例では、Red Hat Single Sign-On を使用します。
手順
Red Hat Single Sign-On のメインページで、以下を行います。
-
Red Hat Quay で使用するために認証された適切なレルムを選択します。issuer URL を保存します (例:
https://keycloak-auth-realm.quayadmin.org/realms/quayrealm
)。 - Users →「認証のためにロボットアカウントにリンクするユーザーの名前」をクリックします。OAuth2 アクセストークンを生成するときに使用したのと同じユーザーアカウントを使用する必要があります。
Details ページで、ユーザーの ID (例:
449e14f8-9eb5-4d59-a63e-b7a77c75f770
) を保存します。注記このステップで収集される情報は、OIDC プロバイダーによって異なります。たとえば、Red Hat Single Sign-On では、ユーザーの ID が Subject として使用され、後続のステップでロボットアカウントフェデレーションがセットアップされます。Microsoft Entra ID などの別の OIDC プロバイダーの場合、この情報は Subject として保存されます。
-
Red Hat Quay で使用するために認証された適切なレルムを選択します。issuer URL を保存します (例:
Red Hat Quay レジストリーの場合、以下を行います。
- Organizations に移動し、組織の名前 (例: fed_test) をクリックします。
- Robot Accounts をクリックします。
- 縦の省略記号メニュー → Set robot federation をクリックします。
- + 記号をクリックします。
ポップアップウィンドウに次の情報を入力します。
-
Issuer URL:
https://keycloak-auth-realm.quayadmin.org/realms/quayrealm
。Red Hat Single Sign-On の場合、これは Red Hat Single Sign-On レルムの URL になります。これは、OIDC プロバイダーによって異なる場合があります。 -
Subject:
449e14f8-9eb5-4d59-a63e-b7a77c75f770
。Red Hat Single Sign-On の場合、Subject は Red Hat Single Sign-On ユーザーの ID になります。これは OIDC プロバイダーによって異なります。たとえば、Microsoft Entra ID を使用している場合、Subject は Subject または Entra ID ユーザーになります。
-
Issuer URL:
- Save をクリックします。
7.5.3. OAuth2 アクセストークンを Red Hat Quay ロボットアカウントトークンと交換する
次の手順では、前の手順で生成された access token
を利用して、新しい Red Hat Quay ロボットアカウントトークンを作成します。新しい Red Hat Quay ロボットアカウントトークンは、OIDC プロバイダーと Red Hat Quay 間の認証に使用されます。
次の例では、Python スクリプトを使用して、OAuth2 アクセストークンを Red Hat Quay ロボットアカウントトークンと交換します。
前提条件
-
python3
CLI ツールがインストールされている。
手順
次の Python スクリプトを
.py
ファイル (例:robot_fed_token_auth.py
) に保存します。import requests import os TOKEN=os.environ.get('TOKEN') robot_user = "fed-test+robot1" def get_quay_robot_token(fed_token): URL = "https://<quay-server.example.com>/oauth2/federation/robot/token" response = requests.get(URL, auth=(robot_user,fed_token)) 1 print(response) print(response.text) if __name__ == "__main__": get_quay_robot_token(TOKEN)
- 1
- Red Hat Quay デプロイメントでカスタム SSL/TLS 証明書を使用している場合、応答は
response = requests.get(URL,auth=(robot_user,fed_token),verify=False)
ある必要があり、これにはverify=False
フラグが含まれます。
OAuth2 アクセストークンを
TOKEN
としてエクスポートします。以下に例を示します。$ export TOKEN = eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJTVmExVHZ6eDd2cHVmc1dkZmc1SHdua1ZDcVlOM01DN1N5T016R0QwVGhVIn0...
次のコマンドを入力して
robot_fed_token_auth.py
スクリプトを実行します。$ python3 robot_fed_token_auth.py
出力例
<Response [200]> {"token": "291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJlbWFpbF92ZXJpZ..."}
重要このトークンは 1 時間が経過すると期限切れになります。1 時間後、新しいトークンを生成する必要があります。
ロボットアカウントアクセストークンを
QUAY_TOKEN
としてエクスポートします。以下に例を示します。$ export QUAY_TOKEN=291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJlbWFpbF92ZXJpZ
7.5.4. イメージのプッシュとプル
新しいロボットアカウントアクセストークンを生成してエクスポートしたら、アクセストークンを使用してロボットアカウントにログインし、イメージをプッシュおよびプルできます。
前提条件
- OAuth2 アクセストークンを新しいロボットアカウントアクセストークンにエクスポートしている。
手順
fest_test+robot1
ロボットアカウントとQUAY_TOKEN
アクセストークンを使用して、Red Hat Quay レジストリーにログインします。以下に例を示します。$ podman login <quay-server.example.com> -u fed_test+robot1 -p $QUAY_TOKEN
ロボットアカウントに適切な権限がある Red Hat Quay リポジトリーからイメージをプルします。以下に例を示します。
$ podman pull <quay-server.example.com/<repository_name>/<image_name>>
出力例
Getting image source signatures Copying blob 900e6061671b done Copying config 8135583d97 done Writing manifest to image destination Storing signatures 8135583d97feb82398909c9c97607159e6db2c4ca2c885c0b8f590ee0f9fe90d 0.57user 0.11system 0:00.99elapsed 68%CPU (0avgtext+0avgdata 78716maxresident)k 800inputs+15424outputs (18major+6528minor)pagefaults 0swaps
ロボットアカウントに適切な権限が ない Red Hat Quay リポジトリーからイメージをプルしようとしました。以下に例を示します。
$ podman pull <quay-server.example.com/<different_repository_name>/<image_name>>
出力例
Error: initializing source docker://quay-server.example.com/example_repository/busybox:latest: reading manifest in quay-server.example.com/example_repository/busybox: unauthorized: access to the requested resource is not authorized
このロボットアカウントの認証情報は、1 時間後に期限切れになるよう設定されています。その後、このロボットアカウントの新しいアクセストークンを生成する必要があります。
第8章 Red Hat Quay のアクセス管理
Quay.io ユーザーは、独自のリポジトリーを作成し、インスタンスに含まれる他のユーザーにそのリポジトリーへのアクセスを許可できます。または、組織を作成し、その組織にリポジトリーのセット (これは 組織リポジトリー と呼ばれます) を直接関連付けることもできます。
組織リポジトリーは、組織がユーザーのグループを通じて共有リポジトリーをセットアップすることを目的としているという点で、基本的なリポジトリーとは異なります。Quay.io では、ユーザーのグループは、チーム、同じ権限を持つユーザーのセット、または 個々のユーザー のいずれかです。また、ロボットアカウントに関連付けられた認証情報を作成することで、ユーザーリポジトリーと組織リポジトリーへのアクセスを許可することもできます。ロボットアカウントを使用すると、Quay.io ユーザーアカウントを持っていないさまざまなコンテナークライアント (Docker や Podman など) がリポジトリーに簡単にアクセスできるようになります。
8.1. Red Hat Quay のチームの概要
Red Hat Quay の チーム は、権限を共有するユーザーのグループであり、プロジェクトの効率的な管理とコラボレーションを可能にするものです。チームは、組織およびリポジトリー内のアクセス制御とプロジェクト管理を効率化するのに役立ちます。指定の権限をチームに割り当てることで、メンバーの役割と責任に基づいて、リポジトリーへの適切なレベルのアクセス権を付与できます。
8.1.1. UI を使用したチームの作成
組織のためにチームを作成する際に、チーム名を選択し、チームが利用できるリポジトリーを選択し、チームのアクセスレベルを決定できます。
組織リポジトリー用のチームを作成するには、次の手順に従います。
前提条件
- 組織を作成している。
手順
- Red Hat Quay v2 UI で、組織の名前をクリックします。
- 組織のページで、Teams and membership をクリックします。
- Create new team ボックスをクリックします。
- Create team ポップアップウィンドウで、新しいチームの名前を入力します。
- オプション: 新しいチームの説明を入力します。
- Proceed をクリックします。新しいポップアップウィンドウが表示されます。
オプション: このチームをリポジトリーに追加し、権限を次のいずれかに設定します。
- None。チームメンバーにリポジトリーに対する権限は付与されません。
- Read。チームメンバーがリポジトリーの表示とリポジトリーからのプルを行えるようになります。
- Write。チームメンバーがリポジトリーの読み取り (プル) とリポジトリーへの書き込み (プッシュ) を行えるようになります。
- Admin。プルおよびプッシュを行うためのリポジトリーへのフルアクセスに加えて、リポジトリーに関連する管理作業を行う権限を付与します。
- オプション: チームメンバーまたはロボットアカウントを追加します。チームメンバーを追加するには、Red Hat Quay アカウントの名前を入力します。
- 情報を確認し、Review and Finish をクリックします。新しいチームが Teams and membership ページに表示されます。
8.1.2. UI を使用したチームの管理
チームを作成したら、UI を使用してチームメンバーを管理したり、リポジトリー権限を設定したり、チームを削除したり、チームに関するより一般的な情報を表示したりできます。
8.1.2.1. UI を使用したチームへのユーザーの追加
組織に対する管理者権限を持っていれば、ユーザーとロボットアカウントをチームに追加できます。ユーザーを追加すると、Quay.io はそのユーザーに電子メールを送信します。そのユーザーが招待を受け入れるまで、ユーザーは保留状態のままになります。
ユーザーまたはロボットアカウントをチームに追加するには、次の手順を実行します。
手順
- Red Hat Quay のランディングページで、組織の名前をクリックします。
- ナビゲーションウィンドウで、Teams and Membership をクリックします。
- ユーザーまたはロボットアカウントを追加するチームの縦の省略記号メニューを選択します。Manage team members をクリックします。
- Add new member をクリックします。
テキストボックスに、次のいずれかの情報を入力します。
- レジストリー上のアカウントからのユーザー名。
- レジストリー上のユーザーアカウントのメールアドレス。
ロボットアカウントの名前。名前は、<組織名>+<ロボット名> の形式である必要があります。
注記ロボットアカウントはすぐにチームに追加されます。ユーザーアカウントの場合、参加の招待がユーザーにメールで送信されます。ユーザーがその招待を受け入れるまで、ユーザーは INVITED TO JOIN 状態のままになります。ユーザーがチームへの参加招待メールを受け入れると、INVITED TO JOIN リストから組織の MEMBERS リストに移動します。
- Add member をクリックします。
8.1.2.2. UI を使用したチームのロールの設定
チームを作成したら、そのチームの組織内でのロールを設定できます。
前提条件
- チームを作成している。
手順
- Red Hat Quay のランディングページで、組織の名前をクリックします。
- ナビゲーションウィンドウで、Teams and Membership をクリックします。
次の図に示すように、TEAM ROLE ドロップダウンメニューを選択します。
選択したチームに、以下のロールのいずれかを選択します。
- Admin。チームの作成、メンバーの追加、権限の設定など、組織への完全な管理アクセス権を付与します。
- Member。チームに設定されているすべての権限を継承します。
- Creator。メンバーのすべての権限に加えて、新しいリポジトリーを作成する権限を付与します。
8.1.2.2.1. チームメンバーとリポジトリー権限の管理
チームメンバーを管理し、リポジトリー権限を設定するには、次の手順に従います。
組織の Teams and membership ページでは、チームメンバーを管理したり、リポジトリー権限を設定したりすることもできます。
- 縦の省略記号メニューをクリックし、次のいずれかのオプションを選択します。
- Manage Team Members。このページでは、すべてのメンバー、チームメンバー、ロボットアカウント、または招待したユーザーを表示できます。Add new member をクリックして、新しいチームメンバーを追加することもできます。
Set repository permissions。このページでは、リポジトリー権限を次のいずれかに設定できます。
- None。チームメンバーにリポジトリーに対する権限は付与されません。
- Read。チームメンバーがリポジトリーの表示とリポジトリーからのプルを行えるようになります。
- Write。チームメンバーがリポジトリーの読み取り (プル) とリポジトリーへの書き込み (プッシュ) を行えるようになります。
- Admin。プルおよびプッシュを行うためのリポジトリーへのフルアクセスに加えて、リポジトリーに関連する管理作業を行う権限を付与します。
- Delete。このポップアップウィンドウでは、Delete をクリックしてチームを削除できます。
8.1.2.2.2. チームに関する追加情報の表示
チームに関する一般情報を表示するには、次の手順に従います。
手順
組織の Teams and membership ページで、次のいずれかのオプションをクリックすると、チーム、メンバー、コラボレーターに関する詳細情報を表示できます。
- Team View。このメニューには、すべてのチーム名、メンバーの数、リポジトリーの数、および各チームのロールが表示されます。
- Members View。このメニューには、チームメンバーのすべてのユーザー名、メンバーが属しているチーム、ユーザーのリポジトリー権限が表示されます。
- Collaborators View。このメニューにはリポジトリーのコラボレーターが表示されます。コラボレーターは、組織内のどのチームにも属さないが、組織に属する 1 つ以上のリポジトリーに対する直接権限を持つユーザーです。
8.1.3. Red Hat Quay API を使用したチームの管理
チームを作成したら、API を使用して、チームの権限やチームメンバーに関する情報を取得したり、チームメンバーを追加、更新、削除したり (メールによる削除を含む)、組織のチームを削除したりできます。
次の手順では、Red Hat Quay API を使用してチームを管理する方法を説明します。
8.1.3.1. API を使用して組織内のチームのロールを設定する
API を使用して組織内のチームのロールを表示および設定するには、次の手順に従います。
前提条件
- OAuth アクセストークンを作成 した。
-
config.yaml
ファイルでBROWSER_API_CALLS_XHR_ONLY: false
を設定している。
手順
組織のチームのリポジトリー権限のリストを返すには、次の
GET/api/v1/organization/{orgname}/team/{teamname}/permissions
コマンドを入力します。このコマンドで情報を取得するには、チームがリポジトリーに追加されている必要があることに注意してください。$ curl -X GET \ -H "Authorization: Bearer <your_access_token>" \ "<quay-server.example.com>/api/v1/organization/<organization_name>/team/<team_name>/permissions"
出力例
{"permissions": [{"repository": {"name": "api-repo", "is_public": true}, "role": "admin"}]}
PUT/api/v1/organization/{orgname}/team/{teamname}
コマンドを使用して、組織内のチームを作成または更新し、指定されたロールを admin、member、または creator にすることができます。以下に例を示します。$ curl -X PUT \ -H "Authorization: Bearer <your_access_token>" \ -H "Content-Type: application/json" \ -d '{ "role": "<role>" }' \ "<quay-server.example.com>/api/v1/organization/<organization_name>/team/<team_name>"
出力例
{"name": "testteam", "description": "", "can_view": true, "role": "creator", "avatar": {"name": "testteam", "hash": "827f8c5762148d7e85402495b126e0a18b9b168170416ed04b49aae551099dc8", "color": "#ff7f0e", "kind": "team"}, "new_team": false}
8.2. UI を使用したデフォルトの権限の作成および管理
デフォルトの権限は、リポジトリーの作成者のデフォルトに加えて、リポジトリーの作成時にリポジトリーに自動的に付与される権限を定義します。権限は、リポジトリーを作成したユーザーに基づいて割り当てられます。
Red Hat Quay v2 UI を使用してデフォルトの権限を作成するには、次の手順を実行します。
手順
- 組織名をクリックします。
- Default permissions をクリックします。
- Create default permissions をクリックします。切り替え式のドロワーが表示されます。
リポジトリーの作成時にデフォルトの権限を作成するには、Anyone または Specific user を選択します。
Anyone を選択する場合は、次の情報を入力する必要があります。
- Applied to。ユーザー/ロボット/チームを検索、招待、または追加します。
- Permission。権限を Read、Write、または Admin のいずれかに設定します。
Specific user を選択する場合は、次の情報を指定する必要があります。
- Repository creator。ユーザーまたはロボットアカウントを指定します。
- Applied to。ユーザー名、ロボットアカウント、またはチーム名を入力します。
- Permission。権限を Read、Write、または Admin のいずれかに設定します。
- Create default permission をクリックします。確認ボックスが表示され、Successfully created default permission for creator というアラートが返されます。
8.3. UI を使用したリポジトリーのアクセス設定の調整
v2 UI を使用してリポジトリーのユーザーまたはロボットアカウントのアクセス設定を調整するには、次の手順に従います。
前提条件
- ユーザーアカウントまたはロボットアカウントを作成した。
手順
- Quay.io にログインします。
- v2 UI で、Repositories をクリックします。
-
リポジトリーの名前をクリックします (例:
quayadmin/busybox
)。 - Settings タブをクリックします。
オプション: User and robot permissions をクリックします。Permissions のドロップダウンメニューオプションをクリックすると、ユーザーまたはロボットアカウントの設定を調整できます。設定を Read、Write、または Admin に変更できます。
- Read。ユーザーまたはロボットアカウントが、リポジトリーを表示し、リポジトリーからプルできます。
- Write。ユーザーまたはロボットアカウントが、リポジトリーからの読み取り (プル) とリポジトリーへの書き込み (プッシュ) を実行できます。
- Admin。ユーザーアカウントまたはロボットアカウントに、リポジトリーからのプルとリポジトリーへのプッシュのアクセス権に加え、リポジトリーに関連する管理タスクを実行する権限を付与します。
第9章 イメージタグの概要
イメージタグ は、コンテナーイメージの特定のバージョンまたはバリアントに割り当てられたラベルまたは識別子を指します。コンテナーイメージは通常、イメージのさまざまな部分を表す複数のレイヤーで構成されます。イメージタグは、異なるバージョンのイメージを区別したり、イメージに関する追加情報を提供したりするために使用します。
イメージタグには次の利点があります。
- バージョン管理とリリース: イメージタグを使用すると、アプリケーションまたはソフトウェアのさまざまなバージョンまたはリリースを示すことができます。たとえば、初期リリースを表すために v1.0 とイメージにタグ付けしたり、更新されたバージョンを表すために v1.1 とタグ付けしたりできます。これは、イメージのバージョンの明確な履歴を維持するのに役立ちます。
- ロールバックとテスト: 新しいイメージのバージョンで問題が発生した場合は、タグを指定することで以前のバージョンに簡単に戻すことができます。これは、デバッグ段階とテスト段階で役立ちます。
- 開発環境: イメージタグは、さまざまな環境で作業する場合に役立ちます。たとえば、開発バージョンには dev タグ、品質保証テストには qa、本番環境には prod タグを使用して、それぞれ機能と設定を異なるものにすることができます。
- 継続的インテグレーション/継続的デプロイメント (CI/CD): CI/CD パイプラインでは、イメージタグを使用してデプロイメントプロセスを自動化することがよくあります。新しいコードの変更により、特定のタグを持つ新しいイメージの作成をトリガーすることで、シームレスな更新が可能になります。
- 機能ブランチ: 複数の開発者が異なる機能やバグ修正に取り組んでいる場合は、変更ごとに個別のイメージタグを作成できます。これは、個々の機能を分離してテストするのに役立ちます。
- カスタマイズ: イメージタグを使用すると、各バリアントを追跡しながら、さまざまな設定、依存関係、または最適化を使用してイメージをカスタマイズできます。
- セキュリティーとパッチ適用: セキュリティーの脆弱性が発見された場合は、更新されたタグを使用して、パッチが適用されたバージョンのイメージを作成し、セキュアな最新バージョンをシステムで確実に使用できます。
- Dockerfile の変更: Dockerfile またはビルドプロセスを変更する場合は、イメージタグを使用して、以前の Dockerfile と更新された Dockerfile からビルドしたイメージを区別できます。
全体として、イメージタグはコンテナーイメージを管理および整理するための構造化された方法を提供し、開発、デプロイ、および保守の効率的なワークフローを可能にします。
9.1. UI を使用してイメージタグ情報を表示する
v2 UI を使用してイメージタグ情報を表示するには、次の手順を実行します。
前提条件
- イメージタグをリポジトリーにプッシュした。
手順
- v2 UI で、Repositories をクリックします。
- リポジトリーの名前をクリックします。
タグの名前をクリックします。そのタグの Details ページに移動します。このページには、次の情報が表示されます。
- 名前
- リポジトリー
- Digest
- 脆弱性
- 作成
- 修正済み
- Size
- ラベル
- イメージタグの取得方法
- Security Report をクリックして、タグの脆弱性を表示します。アドバイザリーの列を拡張して、CVE データを開くことができます。
- Packages をクリックして、タグのパッケージを表示します。
- リポジトリーの名前をクリックし、Tags ページに戻ります。
9.2. UI を使用してイメージに新しいイメージタグを追加する
Quay.io のイメージに新しいタグを追加できます。
手順
- Red Hat Quay v2 UI ダッシュボードのナビゲーションペインで Repositories をクリックします。
- イメージタグのあるリポジトリーの名前をクリックします。
- 縦の省略記号メニューをクリックし、Add new tag をクリックします。
タグの名前を入力し、Create tag をクリックします。
新しいタグが Repository Tags ページにリストされます。
9.3. UI を使用してラベルを追加および管理する
管理者は、次の手順を使用してタグのラベルを追加および管理できます。
手順
- v2 UI ダッシュボードのナビゲーションペインで Repositories をクリックします。
- イメージタグのあるリポジトリーの名前をクリックします。
- イメージの縦の省略記号メニューをクリックし、Edit labels を選択します。
- Edit labels ウィンドウで、Add new label をクリックします。
key=value
形式を使用してイメージタグのラベルを入力します (例:com.example.release-date=2023-11-14
)。注記key=value
形式の使用に失敗すると、Invalid label format, must be key value separated by =
というエラーが返されます。- 空白のボックスをクリックしてラベルを追加します。
- オプション: 2 番目のラベルを追加します。
-
Save labels をクリックして、ラベルをイメージタグに保存します。
Created labels successfully
という通知が返されます。 - オプション: 同じイメージタグの縦の省略記号メニュー→ Edit labels → ラベルの X をクリックして削除します。または、テキストを編集することもできます。Save labels をクリックします。これでラベルが削除または編集されました。
9.4. タグの有効期限を設定する
タグの有効期限 機能を使用すると、選択した日時に Quay.io リポジトリーのイメージタグが期限切れになるように設定できます。この機能には次の特徴があります。
- イメージタグの有効期限が切れると、そのタグがリポジトリーから削除されます。特定のイメージに対する最後のタグであれば、そのイメージも削除するように設定されます。
- 有効期限はタグごとに設定されます。リポジトリー全体に対して設定されるものではありません。
- タグは期限切れになったり、削除されたりしても、レジストリーからすぐには削除されません。これは、タイムマシン 機能で設計された割り当て時間によって決まります。この時間により、タグを完全に削除するタイミング、またはガベージコレクションを行うタイミングが定義されます。デフォルトでは、この値は 14 日 に設定されていますが、管理者は複数のオプションから 1 つ選択することで、この時間を調整できます。ガベージコレクションが発生するまでは、タグの変更を元に戻すことができます。
タグの有効期限は、次の 2 つの方法のいずれかで設定できます。
-
イメージの作成時に Dockerfile に
quay.expires-after=
ラベルを設定します。これは、イメージをビルドした時点からの有効期間を設定するものです。 Quay.io UI で有効期限を選択する方法。以下に例を示します。
タグの有効期限を設定すると、古いタグや未使用のタグのクリーンアップを自動化できるため、ストレージ容量を削減できます。
9.4.1. リポジトリーからタグの有効期限を設定する
手順
- Red Hat Quay v2 UI ダッシュボードのナビゲーションペインで Repositories をクリックします。
- イメージタグのあるリポジトリーの名前をクリックします。
- イメージの縦の省略記号メニューをクリックし、Change expiration を選択します。
- オプション: または、複数のタグのボックスをクリックし、Actions → Set expiration を選択して有効期限を一括追加することもできます。
-
Change Tags Expiration ウィンドウで、曜日、月、日、年を指定して有効期限を設定します。たとえば、
Wednesday, November 15, 2023
に設定します。または、カレンダーボタンをクリックして日付を手動で選択することもできます。 -
時刻を
2:30 PM
などに設定します。 -
Change Expiration をクリックして日付と時刻を確認します。
Successfully set expiration for tag test to Nov 15, 2023, 2:26 PM
という通知が返されます。 Red Hat Quay v2 UI の Tags ページで、タグの有効期限の設定を確認できます。以下に例を示します。
9.4.2. Dockerfile からタグの有効期限を設定する
docker label
コマンドを使用してイメージタグにラベル (例: quay.expires-after=20h
) を追加すると、指定時間の経過後にタグが自動的に期限切れになります。以下に示す時間、日、または週の値を指定できます。
-
1h
-
2d
-
3w
有効期限は、イメージがレジストリーにプッシュされた時点から始まります。
手順
次の
docker label
コマンドを入力し、目的のイメージタグにラベルを追加します。タグが 20 時間後に期限切れになるよう指定するには、ラベルをquay.expires-after=20h
という形式にします。20h は希望の有効期限に置き換えます。以下に例を示します。$ docker label quay.expires-after=20h quay-server.example.com/quayadmin/<image>:<tag>
9.5. タグやダイジェストによるイメージの取得
Quay.io では、Docker クライアントと Podman クライアントを使用して、複数の方法でイメージをプルできます。
手順
- リポジトリーの Tags ページに移動します。
- Manifest で、Fetch Tag アイコンをクリックします。
ポップアップボックスが表示され、次のオプションが表示されます。
- Podman Pull (by tag)
- Docker Pull (by tag)
- Podman Pull (by digest)
Docker Pull (by digest)
4 つのオプションのいずれかを選択すると、イメージのプルに使用できる各クライアント用のコマンドが返されます。
Copy Command をクリックしてコマンドをコピーします。このコマンドはコマンドラインインターフェイス (CLI) で使用できます。以下に例を示します。
$ podman pull quay.io/quayadmin/busybox:test2
9.6. UI を使用して Red Hat Quay のタグ履歴を表示する
Quay.io では、イメージとそれぞれのイメージタグの包括的な履歴を確認できます。
手順
- Red Hat Quay v2 UI ダッシュボードのナビゲーションペインで Repositories をクリックします。
- イメージタグのあるリポジトリーの名前をクリックします。
Tag History をクリックします。このページでは、次の操作を実行できます。
- タグ名での検索
- 日付範囲の選択
- タグの変更の表示
- タグの変更日と変更時刻の表示
9.7. イメージタグを削除する
イメージタグを削除すると、その特定のバージョンのイメージがレジストリーから削除されます。
イメージタグを削除するには、次の手順を実行します。
手順
-
v2 UI の Repositories ページで、削除するイメージの名前 (
quay/admin/busybox
など) をクリックします。 - More Actions ドロップダウンメニューをクリックします。
Delete をクリックします。
注記必要に応じて、Make Public または Make Private をクリックできます。
- ボックスに confirm と入力してから、Delete をクリックします。
削除後、Repositories ページに戻ります。
注記イメージタグの削除は、タイムマシン 機能に割り当てられている時間に基づいて元に戻すことができます。詳細は、「タグの変更を元に戻す」を参照してください。
9.8. UI を使用してタグの変更を元に戻す
Quay.io は、古いイメージタグを一定期間リポジトリーに保持できる包括的な タイムマシン 機能を備えており、タグに加えられた変更を元に戻すことができます。この機能を使用すると、タグの削除などのタグの変更を元に戻すことができます。
手順
- v2 UI の Repositories ページで、元に戻すイメージの名前をクリックします。
- Tag History タブをクリックします。
- タイムライン内でイメージタグが変更または削除された時点を見つけます。次に、Revert の下のオプションをクリックして、タグをイメージに戻します。
第10章 ログの表示とエクスポート
アクティビティーログは、Quay.io のすべてのリポジトリーと namespace に対して収集されます。
Quay.io の使用状況ログを表示すると、運用とセキュリティーの両方の目的で貴重な洞察と利点を得ることができます。使用状況ログから次の情報が明らかになる可能性があります。
- リソースプランニング: 使用状況ログは、イメージのプル、プッシュの数、レジストリーへの全体的なトラフィックに関するデータを提供します。
- ユーザーアクティビティー: ログを使用すると、ユーザーアクティビティーを追跡し、どのユーザーがレジストリー内のイメージにアクセスして操作しているかを把握できます。これは、監査、ユーザー行動の理解、アクセス制御の管理に役立ちます。
- 使用パターン: 使用パターンを調査することで、よく使用されるイメージ、頻繁に使用されるバージョン、ほとんどアクセスされないイメージに関する詳細な情報を得ることができます。この情報は、イメージのメンテナンスとクリーンアップの作業に優先順位を付けるのに役立ちます。
- セキュリティー監査: 使用状況ログにより、誰がいつイメージにアクセスしたかを追跡できます。これは、セキュリティー監査、コンプライアンス、および不正または不審なアクティビティーの調査にとって非常に重要です。
- イメージのライフサイクル管理: ログにより、どのイメージがプル、プッシュ、削除されているかが明らかになります。この情報は、古いイメージを廃止し、許可されたイメージだけを確実に使用させるなど、イメージのライフサイクル管理に不可欠です。
- コンプライアンスと規制要件: 多くの業界には、機密リソースへのアクセスの追跡と監査を義務付けるコンプライアンス要件があります。使用状況ログは、そのような規制への準拠を証明するのに役立ちます。
- 異常な動作の特定: 使用状況ログ内の正常でないパターンや異常なパターンは、潜在的なセキュリティー違反または悪意のあるアクティビティーを示している可能性があります。このログを監視すると、セキュリティーインシデントをより効果的に検出して対応することができます。
- 傾向分析: 使用状況ログは、レジストリーがどのように使用されているかに関する経時的な傾向と詳細情報を提供します。これは、リソースの割り当て、アクセス制御、イメージ管理戦略について、情報に基づいた意思決定を行うのに役立ちます。
ログファイルにアクセスする方法は、以下のように複数あります。
- Web UI によりログを閲覧する
- 外部に保存できるようにログをエクスポートする
- API を使用してログエントリーへのアクセスする
ログにアクセスするには、選択したリポジトリーまたは名前空間の管理者権限が必要です。
API を介して一度に利用できるログ結果は最大 100 件です。それ以上の結果を集めるには、この章で紹介するログエクスポーター機能を使う必要があります。
10.1. 使用ログの表示
ログは、レジストリーの使用方法に関する有用な情報を提供します。ログは、以下の手順を使用して v2 UI の組織、リポジトリー、または名前空間で表示できます。
手順
- Red Hat Quay レジストリーにログインします。
- 自分が管理者である組織、リポジトリーまたは名前空間に移動します。
Logs をクリックします。
- オプション: From ボックスと To ボックスに日付を追加して、ログエントリーを表示する日付範囲を設定します。
-
オプション: Export をクリックして、ログをエクスポートします。
http://
またはhttps://
で始まるメールアドレスまたは有効なコールバック URL を入力する必要があります。このプロセスは、ログの数に応じて 1 時間かかる場合があります。
10.2. UI を使用したリポジトリーログのエクスポート
ログのエクスポート 機能を使用すると、より多くのログファイルを取得し、Quay.io の外部に保存できます。この機能には次の利点と制約があります。
- リポジトリーから収集するログの日付の範囲を選択できます。
- ログをメールの添付ファイルで送信するか、コールバック URL に移動することを要求できます。
- ログをエクスポートするには、リポジトリーまたは名前空間の管理者である必要があります。
- すべてのユーザーのログが 30 日分保持されます。
- Export logs 機能は、過去に生成されたログデータのみを収集します。ログ取得中のデータのストリーミングは行いません。
- ログが収集されて利用可能になったら、そのデータを保存する場合は、すぐにコピーする必要があります。デフォルトでは、データは 1 時間後に期限切れになります。
ログをエクスポートするには、次の手順を実行します。
手順
- 管理者権限のあるリポジトリーを選択します。
- Logs タブをクリックします。
- オプション: 特定の日付を指定する場合は、From ボックスと to ボックスに範囲を入力します。
Export Logs ボタンをクリックします。以下のような Export Usage Logs のポップアップが表示されます。
- エクスポートされたログを受信するメールアドレスまたはコールバック URL を入力します。コールバック URL には、指定ドメインへの URL (例: <webhook.site>) を使用できます。
- Confirm を選択して、選択したログエントリーを収集するプロセスを開始します。収集されるログデータの量に応じて、これが完了するまでに数分から数時間かかる場合があります。
ログのエクスポートが完了すると、次の 2 つのイベントのいずれかが発生します。
- 要求したエクスポート済みログエントリーが利用可能であることを通知するメールが受信されます。
- Webhook URL からのログエクスポート要求の成功ステータスが返されます。さらに、エクスポートされたデータへのリンクを使用して、ログをダウンロードできるようになります。
第11章 Clair セキュリティースキャナー
Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Quay.io にパッケージ化されており、自動的に有効になり、Red Hat Quay 開発チームによって管理されます。
Quay.io ユーザーの場合、イメージはリポジトリーにプッシュされた後、自動的にインデックスが作成されます。次に、Clair からレポートが取得され、Clair はイメージを CVE のデータベースと照合してセキュリティー情報を報告します。このプロセスは Quay.io で自動的に行われるため、手動での再スキャンは必要ありません。
11.1. Clair について
Clair は、National Vulnerability Database (NVD) の Common Vulnerability Scoring System (CVSS) データを使用して脆弱性データを補完します。NVD は、さまざまなソフトウェアコンポーネントやシステムの既知の脆弱性やセキュリティー問題など、セキュリティー関連情報を提供する米国政府のリポジトリーです。NVD のスコアを使用することは、Clair にとって次の利点があります。
- データの同期。Clair は、脆弱性データベースを NVD と定期的に同期できます。これにより、最新の脆弱性データが確実に保持されます。
- 照合と補完。Clair は、コンテナーイメージ内で発見した脆弱性のメタデータと識別子を NVD のデータと比較します。このプロセスでは、Common Vulnerabilities and Exposures (CVE) ID などの一意の識別子と NVD 内のエントリーの照合を実行します。一致するものが見つかった場合、Clair は重大度スコア、説明、リファレンスなど、NVD から詳細情報を追加して、脆弱性情報を補完することができます。
- 重大度スコア。NVD は、Common Vulnerability Scoring System (CVSS) スコアなどの重大度スコアを脆弱性に割り当て、各脆弱性に関連する潜在的な影響とリスクを示します。NVD の重大度スコアを組み込むことにより、Clair は検出した脆弱性の重大さに関するコンテキストをより多く提供できます。
Clair が NVD に基づいて脆弱性を発見した場合は、コンテナーイメージ内で検出された脆弱性の重大度と潜在的な影響について、標準化された詳細な評価が、UI を通じてユーザーに報告されます。CVSS の補完データは、Clair に次の利点を提供します。
- 脆弱性の優先順位付け。CVSS スコアを利用することで、ユーザーは重大度に基づいて脆弱性に優先順位を付け、最も重要な問題に最初に対処できるようになります。
- リスクの評価。CVSS スコアは、コンテナー化されたアプリケーションに対する脆弱性の潜在的なリスクを Clair ユーザーが理解するのに役立ちます。
- 重大度の伝達。CVSS スコアを使用すると、Clair ユーザーはチームおよび組織全体に脆弱性の重大度を標準化された方法で伝達できます。
- 修復戦略の通知。CVSS の補完データは、Quay.io のユーザーが適切な修復戦略を策定する際に役立ちます。
- コンプライアンスとレポート。Clair によって生成されるレポートに CVSS データを統合すると、セキュリティーの脆弱性に対処し、業界の標準と規制に準拠するという組織的な取り組みを示すのに役立ちます。
11.1.1. Clair 脆弱性データベース
Clair は、次の脆弱性データベースを使用して、イメージの問題を報告します。
- Ubuntu Oval データベース
- Debian Security Tracker
- Red Hat Enterprise Linux (RHEL) Oval データベース
- SUSE Oval データベース
- Oracle Oval データベース
- アルパイン SecDB データベース
- VMware Photon OS データベース
- Amazon Web Services (AWS) UpdateInfo
- Open Source Vulnerability (OSV) Database
11.1.2. Clair がサポートする依存関係
Clair は、次の依存関係の特定と管理をサポートしています。
- Java
- golang
- Python
- Ruby
そのため、Clair はこれらの言語のプロジェクトが正しく動作するために依存しているサードパーティーのライブラリーとパッケージを分析して報告できます。
Clair でサポートされていない言語のパッケージを含むイメージがリポジトリーにプッシュされると、そのパッケージに対して脆弱性スキャンを実行することができません。ユーザーには、サポートされていない依存関係やパッケージに関する分析レポートやセキュリティーレポートは表示されません。そのため、次のような影響を考慮する必要があります。
- セキュリティーリスク。脆弱性がスキャンされていない依存関係またはパッケージがあると、組織にセキュリティーリスクが発生する可能性があります。
コンプライアンスの問題。組織に特定のセキュリティー要件またはコンプライアンス要件がある場合は、スキャンされていない、または一部しかスキャンされていないコンテナーイメージにより、特定の規制への違反が発生する可能性があります。
注記スキャンされたイメージにはインデックスが付けられ、脆弱性レポートが作成されますが、サポートされていない特定の言語のデータがレポートから省略されている場合があります。たとえば、コンテナーイメージに Lua アプリケーションが含まれている場合、Clair はそれを検出しないため、Clair からフィードバックは提供されません。Clair はコンテナーイメージで使用されている他の言語を検出し、それらの言語に対して検出された CVE を表示します。そのため、Clair イメージは、Clair がサポートする言語に基づいて 完全にスキャン されます。
11.2. UI を使用した Clair セキュリティースキャンの表示
Clair セキュリティースキャンは UI で表示できます。
手順
- リポジトリーに移動し、ナビゲーションペインで Tags をクリックします。このページに、セキュリティースキャンの結果が表示されます。
- マルチアーキテクチャーイメージに関する詳細情報を表示するには、See Child Manifests をクリックして、展開されたビューでマニフェストのリストを確認します。
- See Child Manifests の下の関連リンクをクリックします。たとえば、1 Unknown をクリックすると、Security Scanner ページにリダイレクトされます。
- Security Scanner ページには、イメージがどの CVE の影響を受けるか、利用可能な修復オプションなど、タグに関する情報が表示されます。
イメージスキャンでは、Clair セキュリティースキャナーによって検出された脆弱性がリストされるだけです。発見された脆弱性への対処は、当該ユーザーに委ねられています。
11.3. Clair の重大度のマッピング
Clair は包括的なアプローチにより脆弱性を評価および管理します。その重要な機能の 1 つは、セキュリティーデータベースの重大度文字列の正規化です。これは、脆弱性の重大度を事前定義された値のセットにマッピングすることで、重大度の評価を効率化するプロセスです。このマッピングにより、クライアントは、各セキュリティーデータベースの固有の複雑な重大度文字列を解読することなく、脆弱性の重大度に効率よく対応できます。これらのマッピングされた重大度文字列は、それぞれのセキュリティーデータベース内にあるものと整合しているため、脆弱性評価の一貫性と正確性が確保されます。
11.3.1. Clair の重大度文字列
Clair は、次の重大度文字列をユーザーに通知します。
- Unknown
- Negligible
- Low
- Medium
- High
- Critical
これらの重大度文字列は、関連するセキュリティーデータベース内にある文字列と似ています。
Alpine のマッピング
Alpine SecDB データベースは重大度情報を提供しません。すべての脆弱性の重大度が Unknown になります。
Alpine の重大度 | Clair の重大度 |
---|---|
* | Unknown |
AWS のマッピング
AWS UpdateInfo データベースが重大度情報を提供します。
AWS の重大度 | Clair の重大度 |
---|---|
low | Low |
medium | Medium |
important | High |
critical | Critical |
Debian のマッピング
Debian Oval データベースが重大度情報を提供します。
Debian の重大度 | Clair の重大度 |
---|---|
* | Unknown |
Unimportant | Low |
Low | Medium |
Medium | High |
High | Critical |
Oracle のマッピング
Oracle Oval データベースは重大度情報を提供します。
Oracle の重大度 | Clair の重大度 |
---|---|
該当なし | Unknown |
LOW | Low |
MODERATE | Medium |
IMPORTANT | High |
CRITICAL | Critical |
RHEL のマッピング
RHEL Oval データベースは重大度情報を提供します。
RHEL の重大度 | Clair の重大度 |
---|---|
なし | Unknown |
Low | Low |
Moderate | Medium |
Important | High |
Critical | Critical |
SUSE のマッピング
SUSE Oval データベースは重大度情報を提供します。
Severity | Clair の重大度 |
---|---|
なし | Unknown |
Low | Low |
Moderate | Medium |
Important | High |
Critical | Critical |
Ubuntu のマッピング
Ubuntu Oval データベースは重大度情報を提供します。
Severity | Clair の重大度 |
---|---|
Untriaged | Unknown |
Negligible | Negligible |
Low | Low |
Medium | Medium |
High | High |
Critical | Critical |
OSV のマッピング
ベーススコア | Clair の重大度 |
---|---|
0.0 | Negligible |
0.1-3.9 | Low |
4.0-6.9 | Medium |
7.0-8.9 | High |
9.0-10.0 | Critical |
ベーススコア | Clair の重大度 |
---|---|
0.0-3.9 | Low |
4.0-6.9 | Medium |
7.0-10 | High |
第12章 コンテナーイメージのビルド
コンテナーイメージをビルドするには、コンテナー化されたアプリケーションのブループリントを作成する必要があります。ブループリントは、アプリケーションのインストール方法と設定方法を定義する他のパブリックリポジトリーのベースイメージに依存します。
ブループリントは他のパブリックリポジトリーのイメージに依存しているため、レート制限の対象となる可能性があります。その結果、ビルドが失敗する 可能性があります。
Quay.io は、Docker および Podman コンテナーイメージを構築する機能をサポートしています。この機能は、コンテナーとコンテナーオーケストレーションを利用する開発者や組織に役立ちます。
Quay.io では、この機能は無料と有料の両方の階層プランで同じように機能します。
Quay.io は、1 人のユーザーが一度に送信できる同時ビルドの数を制限します。
12.1. ビルドコンテキスト
Docker または Podman でイメージをビルドする際には、ビルドコンテキスト となるディレクトリーを指定します。これは手動ビルドとビルドトリガーの両方に当てはまります。Quay.io によって作成されるビルドは、ローカルマシン上で docker build
または podman build
を実行することと変わらないためです。
Quay.io のビルドコンテキストは、常にビルドセットアップから指定された サブディレクトリー であり、ディレクトリーが指定されていない場合はビルドソースのルートにフォールバックします。
ビルドがトリガーされると、Quay.io のビルドワーカーは Git リポジトリーをワーカーマシンにクローンし、ビルドを行う前にビルドコンテキストに入ります。
.tar
アーカイブをベースにしたビルドでは、ビルドワーカーがアーカイブを抽出し、ビルドコンテキストに入ります。以下に例を示します。
展開されたビルドアーカイブ
example ├── .git ├── Dockerfile ├── file └── subdir └── Dockerfile
上記の 展開されたビルドアーカイブ は、example という Github リポジトリーのディレクトリー構造を持っていると考えてみてください。ビルドトリガーの設定でサブディレクトリーが指定されていない場合、またはビルドを手動で開始する場合、ビルドは example ディレクトリーで行われます。
ビルドトリガーの設定でサブディレクトリー (subdir
など) を指定した場合は、その中の Dockerfile のみがビルドの対象になります。つまり、Dockerfile の ADD
コマンドを使用して file
を追加することは、ビルドコンテキストの外にあるためできません。
Docker Hub とは異なり、Dockerfile は Quay.io のビルドコンテキストの一部です。そのため、Dockerfile を .dockerignore
ファイル内に含めることはできません。
12.2. ビルドトリガーのタグ命名
カスタムタグは Quay.io で使用できます。
1 つの方法として、ビルドした各イメージにタグとして割り当てる文字列を含める方法があります。または、ビルドトリガーの Configure Tagging セクションで次のタグテンプレートを使用して、各コミットからの情報でイメージにタグ付けすることもできます。
- ${commit}: 発行されたコミットの完全な SHA
- ${parsed_ref.branch}: ブランチ情報 (利用可能な場合)
- ${parsed_ref.tag}: タグ情報 (利用可能な場合)
- ${parsed_ref.remote}: リモート名
- ${commit_info.date}: コミットが発行された日付
- ${commit_info.author.username}: コミットの作成者のユーザー名
- ${commit_info.short_sha}: コミット SHA の最初の 7 文字
- ${committer.properties.username}: コミッターのユーザー名
以上がすべてではありませんが、これらはタグ付けに最も役立つタグテンプレートです。完全なタグテンプレートスキーマは、こちらのページ を参照してください。
詳細は、Set up custom tag templates in build triggers for Red Hat Quay and Quay.io を参照してください。
12.3. ソースコントロールをトリガーとしたビルドのスキップ
Quay.io ビルドシステムがコミットを無視するように指定するには、コミットメッセージの任意の場所に [skip build]
または [build skip]
というテキストを追加します。
12.4. 新しいビルドの開始
デフォルトでは、Quay.io ユーザーはすぐに新しい ビルド を開始できます。
Dockerfile をアップロードして新しい ビルド を開始するには、次の手順に従います。ビルドトリガー の作成は、「ビルドトリガー」を参照してください。
前提条件
- リポジトリーの Builds ページに移動している。
手順
- Builds ページで、Start New Build をクリックします。
- プロンプトが表示されたら、Upload Dockerfile をクリックして、ルートディレクトリーに Dockerfile または Dockerfile を含むアーカイブをアップロードします。
Start Build をクリックします。
注記- 現在、ユーザーは手動でビルドを開始するときに Docker ビルドコンテキストを指定できません。
- 現在、BitBucket は Red Hat Quay v2 UI ではサポートされていません。
- ビルド にリダイレクトされます。ビルドはリアルタイムで確認できます。Dockerfile ビルド が完了してプッシュされるまで待ちます。
- オプション: Download Logs をクリックしてログをダウンロードしたり、Copy Logs をクリックしてログをコピーしたりできます。
戻るボタンをクリックして Repository Builds ページに戻ると、ビルド履歴 を表示できます。
12.5. ビルドトリガー
ビルドトリガー は、ソースコードの変更、依存関係の更新、Webhook 呼び出しの作成 など、特定の条件が満たされたときにコンテナーイメージのビルドを開始する自動化されたメカニズムです。これらのトリガーは、イメージビルドプロセスの自動化に役立ち、手動介入なしにコンテナーイメージを常に最新の状態にします。
次のセクションでは、ビルドトリガーの作成、タグの命名規則、ソースコントロールがトリガーするビルドのスキップ方法、ビルド の開始、または ビルド の手動トリガーに関連するコンテンツを説明します。
12.5.1. ビルドトリガーの作成
次の手順では、カスタム Git トリガー をセットアップします。カスタム Git トリガーは、任意の Git サーバーが ビルドトリガー として機能するための一般的な方法です。カスタム Git トリガーは SSH 鍵と Webhook エンドポイントのみに依存します。カスタム Git トリガーの作成は、他のトリガーの作成と似ていますが、次の点が違います。
- Quay.io は、トリガーで使用する適切なロボットアカウントを自動的に検出することはできません。これは、作成時に手動で行う必要があります。
これらの手順をレプリケートして、Github、Gitlab、または Bitbucket を使用して ビルドトリガー を作成できますが、config.yaml
ファイルでこれらのサービスの認証情報を設定する必要があります。
- Github を使用して ビルドトリガー を作成する場合は、OAuth アプリケーションを作成し、Red Hat Quay で使用する Github を設定する必要があります。詳細は、「OAuth アプリケーション Github の作成」を参照してください。
手順
- Red Hat Quay レジストリーにログインします。
- ナビゲーションペインで、Repositories をクリックします。
- Create Repository をクリックします。
- Builds タブをクリックします。
- Builds ページで、Create Build Trigger をクリックします。
- Github、Bitbucket、Gitlab などの目的のプラットフォームを選択するか、カスタム Git リポジトリーを使用します。この例では、Custom Git Repository Push をクリックします。
-
カスタム Git リポジトリー名を入力します (例:
git@github.com:<username>/<repo>.git
)。Next をクリックします。 プロンプトが表示されたら、次のオプションのいずれかまたは両方を選択して、タグ付けオプションを設定します。
- Tag manifest with the branch or tag name。このオプションを選択すると、ビルドされたマニフェストにブランチの名前または git コミットのタグがタグ付けされます。
Add
latest
tag if on default branch。このオプションを選択すると、リポジトリーのデフォルトブランチでビルドが行われた場合に、ビルドされたマニフェストに latest がタグ付けされます。オプションで、カスタムのタグ付けテンプレートを追加できます。ここに入力できるタグテンプレートは複数あります。短い SHA ID、タイムスタンプ、作成者名、コミッター、コミットからのブランチ名をタグとして使用することもできます。詳細は、「ビルドトリガーのタグ命名」を参照してください。
タグ付けを設定したら、Next をクリックします。
- プロンプトが表示されたら、トリガーの呼び出し時にビルドする Dockerfile の場所を選択します。Dockerfile が git リポジトリーのルートにあり、Dockerfile という名前が付けられている場合は、Dockerfile パスとして /Dockerfile を入力します。Next をクリックします。
-
プロンプトが表示されたら、Docker ビルドのコンテキストを選択します。Dockerfile が Git リポジトリーのルートにある場合は、ビルドコンテキストディレクトリーとして
/
を入力します。Next をクリックします。 - オプション: 任意のロボットアカウントを選択します。これにより、ビルドプロセス中にプライベートのベースイメージをプルできます。プライベートベースイメージが使用されていないことを把握している場合は、この手順を省略できます。
- Next をクリックします。検証の警告がないか確認します。必要に応じて、Finish をクリックする前に問題を修正します。
トリガーが正常にアクティベートされたという警告が表示されます。このトリガーを使用するには、以下のアクションが必要になることに注意してください。
- 以下の公開鍵に git リポジトリーへの読み取りアクセス権を与える必要があります。
ビルドをトリガーするには、リポジトリーを
POST
に設定する必要があります。SSH 公開鍵を保存し、Return to <organization_name>/<repository_name> をクリックします。リポジトリーの Builds ページにリダイレクトされます。
Builds ページに、ビルドトリガー が表示されます。以下に例を示します。
カスタム Git トリガーを作成した後、追加の手順が必要になります。「カスタム Git トリガーのセットアップ」に進みます。
Github、Gitlab、または Bitbucket の ビルドトリガー をセットアップする場合は、「ビルドの手動トリガー」に進んでください。
12.5.2. ビルドの手動トリガー
次の手順を使用して、ビルド を手動でトリガーできます。
手順
- Builds ページで、Start new build をクリックします。
- プロンプトが表示されたら、Invoke Build Trigger を選択します。
- Run Trigger Now をクリックして、プロセスを手動で開始します。
ビルドを開始するコミット ID を入力します (例:
1c002dd
)。ビルドが開始したら、Repository Builds ページで ビルド ID を確認できます。
12.6. カスタム Git トリガーのセットアップ
カスタム Git トリガー を作成した後、次の 2 つの追加手順が必要です。
- トリガーの作成時に生成された SSH 公開鍵への読み取りアクセスを付与する必要があります。
- ビルドをトリガーするには、Quay.io エンドポイントに POST する Webhook をセットアップする必要があります。
これらの手順は、カスタム Git トリガー を使用している場合にのみ必要です。
12.6.1. ビルドトリガーの認証情報を取得する
SSH 公開鍵と Webhook エンドポイント URL は、Red Hat Quay UI で利用できます。
前提条件
- カスタム Git トリガー を作成している。
手順
- リポジトリーの Builds ページで、カスタム Git トリガー のメニューケバブをクリックします。
- View Credentials をクリックします。
- SSH 公開鍵と Webhook エンドポイント URL を保存します。
鍵と URL は、Settings または 歯車 アイコンから View Credentials を選択することで利用できます。
リポジトリーからのタグの表示および変更
12.6.1.1. SSH 公開鍵へのアクセス
Git サーバーの設定に応じて、Quay.io がカスタム Git トリガー用に生成する SSH 公開鍵をインストールする方法はさまざまです。
たとえば、Getting Git on a Server のドキュメントでは、リポジトリーの管理と SSH 経由のアクセス制御に重点を置いて、Linux ベースのマシンに Git サーバーをセットアップする方法を説明しています。この手順では、$HOME/.ssh/authorize_keys
フォルダーにキーを追加するための小さなサーバーがセットアップされ、ビルダー がリポジトリーのクローンを作成するためのアクセスが提供されます。
公式にサポートされていない Git リポジトリー管理ソフトウェアの場合、通常、Deploy Keys というラベルが付いたキーを入力する場所があります。
12.6.1.2. Webhook
ビルドを自動的にトリガーするには、次の形式を使用して .json
ペイロードを Webhook URL に POST
する必要があります。
このリクエストが有効であるためには、application/json
を含む Content-Type
ヘッダーが必要です。
Webhook の例
{ "commit": "1c002dd", // required "ref": "refs/heads/master", // required "default_branch": "master", // required "commit_info": { // optional "url": "gitsoftware.com/repository/commits/1234567", // required "message": "initial commit", // required "date": "timestamp", // required "author": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required }, "committer": { // optional "username": "user", // required "avatar_url": "gravatar.com/user.png", // required "url": "gitsoftware.com/users/user" // required } } }
これは通常、post-receive
Git フック を使用して実現できますが、サーバーのセットアップによって異なります。
第13章 通知の概要
Quay.io は、リポジトリーのライフサイクルで発生するさまざまなイベントに対して、リポジトリーへの 通知 の追加をサポートしています。
13.1. 通知アクション
通知は Events and Notifications ページの Repository Settings セクションに追加されます。通知は Notifications ウィンドウにも追加されます。このウィンドウは Quay.io のナビゲーションペインにある ベル アイコンをクリックすると表示されます。
Quay.io 通知は、ユーザー、チーム、または 組織 全体に送信されるように設定できます。
通知は、以下のいずれかの方法で配信できます。
メール通知
指定のイベントを説明するメールが、指定のアドレスに送信されます。メールアドレスは リポジトリーごとに 認証する必要があります。
Webhook POST 通知
HTTP POST
呼び出しは、イベントのデータを使用して、指定の URL に対して行われます。イベントデータの詳細は、「リポジトリーイベントの説明」を参照してください。
URL が HTTPS の場合、呼び出しには Quay.io の SSL クライアント証明書が設定されます。この証明書を検証することで、Quay.io からの呼び出しが証明されます。ステータスコードが 2xx
の範囲の応答は成功とみなされます。それ以外のステータスコードを持つ応答は失敗とみなされ、webhook 通知が再試行されます。
Flowdock 通知
Flowdock にメッセージを投稿します。
Hipchat 通知
HipChat にメッセージを投稿します。
Slack 通知
Slack にメッセージを投稿します。
13.2. UI を使用した通知の作成
通知を追加するには、次の手順を実行します。
前提条件
- リポジトリーが作成済みである。
- リポジトリーの管理者権限がある。
手順
- Quay.io のリポジトリーに移動します。
- ナビゲーションペインで、Settings をクリックします。
- Events and Notifications カテゴリーで、Create Notification をクリックして、リポジトリーイベントの新しい通知を追加します。Create notification ポップアップボックスが表示されます。
Create repository ポップアップボックスで、When this event occurs ボックスをクリックしてイベントを選択します。次のタイプのイベントの通知を選択できます。
- リポジトリーへのプッシュ
- イメージビルドの失敗
- イメージビルドのキューへの追加
- イメージビルドの開始
- イメージビルドの成功
- イメージビルドのキャンセル
- イメージの有効期限トリガー
イベントの種類を選択したら、通知方法を選択します。次の方法を使用できます。
- Quay 通知
- メール通知
- Webhook POST
- Flowdock チーム通知
- HipChat ルーム通知
Slack 通知
選択した方法に応じて、追加情報を入力する必要があります。たとえば、E-mail を選択した場合は、メールアドレスと通知タイトル (省略可能) を入力する必要があります。
- イベントと通知方法を選択したら、Create Notification をクリックします。
13.2.1. イメージ有効期限の通知の作成
イメージ有効期限イベントのトリガーは、メール、Slack、Webhook などを通じてユーザーに通知するように設定でき、リポジトリーレベルで設定できます。トリガーは、任意の日数経過後に有効期限が切れるイメージに対して設定でき、自動プルーニング機能と連携して動作できます。
イメージの有効期限通知は、Red Hat Quay v2 UI か、createRepoNotification
API エンドポイントを使用して設定できます。
前提条件
-
FEATURE_GARBAGE_COLLECTION: true
がconfig.yaml
ファイルで設定されている。 -
オプション:
FEATURE_AUTO_PRUNE: true
がconfig.yaml
ファイルで設定されている。
手順
- Red Hat Quay v2 UI で、Repositories をクリックします。
- リポジトリーの名前を選択します。
- Settings → Events and notifications をクリックします。
- Create notification をクリックします。Create notification ポップアップボックスが表示されます。
- Select event… ボックスをクリックし、Image expiry trigger をクリックします。
-
When the image is due to expiry in days ボックスに、イメージの有効期限の何日前にアラートを受け取るかを入力します。たとえば、1 日の場合は
1
を使用します。 Select method… ボックスで、次のいずれかをクリックします。
- メール
- Webhook POST
- Flowdock チーム通知
- HipChat ルーム通知
- Slack 通知
-
選択した方法に応じて、必要なデータを入力します。たとえば、Webhook POST を選択した場合は、
Webhook URL
を入力します。 - オプション: POST JSON body template を指定します。
- オプション: 通知の Title を入力します。
- Submit をクリックします。Events and notifications ページに戻ると、通知が表示されます。
オプション: config.yaml ファイルで
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES
変数を設定できます。このフィールドを設定すると、有効期限が切れるイメージがある場合に通知が自動的に送信されます。デフォルトでは300
(5 時間) に設定されていますが、必要に応じて調整できます。NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300 1
- 1
- デフォルトでは、このフィールドは
300
、つまり 5 時間に設定されています。
検証
縦の省略記号メニュー→ Test Notification をクリックします。次のメッセージが返されます。
Test Notification Queued A test version of this notification has been queued and should appear shortly
選択した方法に応じて、メール、Webhook アドレス、Slack チャネルなどを確認します。送信される情報は次の例のようになります。
{ "repository": "sample_org/busybox", "namespace": "sample_org", "name": "busybox", "docker_url": "quay-server.example.com/sample_org/busybox", "homepage": "http://quay-server.example.com/repository/sample_org/busybox", "tags": [ "latest", "v1" ], "expiring_in": "1 days" }
13.3. API を使用した通知の作成
通知を追加するには、次の手順を実行します。
前提条件
- リポジトリーが作成済みである。
- リポジトリーの管理者権限がある。
- OAuth アクセストークンを作成 した。
-
config.yaml
ファイルでBROWSER_API_CALLS_XHR_ONLY: false
を設定している。
手順
次の
POST /api/v1/repository/{repository}/notification
コマンドを入力し、リポジトリーに関する通知を作成します。$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ -H "Content-Type: application/json" \ --data '{ "event": "<event>", "method": "<method>", "config": { "<config_key>": "<config_value>" }, "eventConfig": { "<eventConfig_key>": "<eventConfig_value>" } }' \ https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/
このコマンドは CLI に出力を返しません。次の
GET /api/v1/repository/{repository}/notification/{uuid}
コマンドを入力すると、リポジトリー通知に関する情報を取得できます。{"uuid": "240662ea-597b-499d-98bb-2b57e73408d6", "title": null, "event": "repo_push", "method": "quay_notification", "config": {"target": {"name": "quayadmin", "kind": "user", "is_robot": false, "avatar": {"name": "quayadmin", "hash": "b28d563a6dc76b4431fc7b0524bbff6b810387dac86d9303874871839859c7cc", "color": "#17becf", "kind": "user"}}}, "event_config": {}, "number_of_failures": 0}
次の
POST /api/v1/repository/{repository}/notification/{uuid}/test
コマンドを入力すると、リポジトリー通知をテストできます。$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>/test
出力例
{}
次の
POST /api/v1/repository/{repository}/notification/{uuid}
コマンドを入力すると、リポジトリー通知の失敗を 0 にリセットできます。$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>
リポジトリー通知を削除するには、次の
DELETE /api/v1/repository/{repository}/notification/{uuid}
コマンドを入力します。$ curl -X DELETE \ -H "Authorization: Bearer <bearer_token>" \ https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/<uuid>
このコマンドは CLI に出力を返しません。次の
GET /api/v1/repository/{repository}/notification/
コマンドを入力すると、すべての通知のリストを取得できます。$ curl -X GET -H "Authorization: Bearer <bearer_token>" -H "Accept: application/json" https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification
出力例
{"notifications": []}
13.4. リポジトリーイベントの説明
次のセクションでは、リポジトリーイベントを詳しく説明します。
リポジトリープッシュ
1 つまたは複数のイメージのリポジトリーへのプッシュが成功しました。
{ "name": "repository", "repository": "dgangaia/test", "namespace": "dgangaia", "docker_url": "quay.io/dgangaia/test", "homepage": "https://quay.io/repository/dgangaia/repository", "updated_tags": [ "latest" ] }
Dockerfile ビルドのキューへの追加
次の例は、ビルドシステムのキューに追加された Dockerfile ビルドからの応答です。
応答は、オプションの属性の使用によって異なる場合があります。
{ "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2", "trigger_kind": "github", //Optional "name": "test", "repository": "dgangaia/test", "namespace": "dgangaia", "docker_url": "quay.io/dgangaia/test", "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional "docker_tags": [ "master", "latest" ], "repo": "test", "trigger_metadata": { "default_branch": "master", "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735", "ref": "refs/heads/master", "git_url": "git@github.com:dgangaia/test.git", "commit_info": { //Optional "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735", "date": "2019-03-06T12:48:24+11:00", "message": "adding 5", "author": { //Optional "username": "dgangaia", "url": "https://github.com/dgangaia", //Optional "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional }, "committer": { "username": "web-flow", "url": "https://github.com/web-flow", "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" } } }, "is_manual": false, "manual_user": null, "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2" }
Dockerfile ビルドの開始
次の例は、ビルドシステムのキューに追加された Dockerfile ビルドからの応答です。
応答は、オプションの属性の使用によって異なる場合があります。
{ "build_id": "a8cc247a-a662-4fee-8dcb-7d7e822b71ba", "trigger_kind": "github", //Optional "name": "test", "repository": "dgangaia/test", "namespace": "dgangaia", "docker_url": "quay.io/dgangaia/test", "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional "docker_tags": [ "master", "latest" ], "build_name": "50bc599", "trigger_metadata": { //Optional "commit": "50bc5996d4587fd4b2d8edc4af652d4cec293c42", "ref": "refs/heads/master", "default_branch": "master", "git_url": "git@github.com:dgangaia/test.git", "commit_info": { //Optional "url": "https://github.com/dgangaia/test/commit/50bc5996d4587fd4b2d8edc4af652d4cec293c42", "date": "2019-03-06T14:10:14+11:00", "message": "test build", "committer": { //Optional "username": "web-flow", "url": "https://github.com/web-flow", //Optional "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional }, "author": { //Optional "username": "dgangaia", "url": "https://github.com/dgangaia", //Optional "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional } } }, "homepage": "https://quay.io/repository/dgangaia/test/build/a8cc247a-a662-4fee-8dcb-7d7e822b71ba" }
Dockerfile ビルドの正常な完了
次の例は、ビルドシステムによって正常に完了した Dockerfile ビルドからの応答です。
このイベントは、ビルドされたイメージの リポジトリープッシュ イベントと同時に発生します。
{ "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2", "trigger_kind": "github", //Optional "name": "test", "repository": "dgangaia/test", "namespace": "dgangaia", "docker_url": "quay.io/dgangaia/test", "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional "docker_tags": [ "master", "latest" ], "build_name": "b7f7d2b", "image_id": "sha256:0339f178f26ae24930e9ad32751d6839015109eabdf1c25b3b0f2abf8934f6cb", "trigger_metadata": { "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735", "ref": "refs/heads/master", "default_branch": "master", "git_url": "git@github.com:dgangaia/test.git", "commit_info": { //Optional "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735", "date": "2019-03-06T12:48:24+11:00", "message": "adding 5", "committer": { //Optional "username": "web-flow", "url": "https://github.com/web-flow", //Optional "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional }, "author": { //Optional "username": "dgangaia", "url": "https://github.com/dgangaia", //Optional "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional } } }, "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2", "manifest_digests": [ "quay.io/dgangaia/test@sha256:2a7af5265344cc3704d5d47c4604b1efcbd227a7a6a6ff73d6e4e08a27fd7d99", "quay.io/dgangaia/test@sha256:569e7db1a867069835e8e97d50c96eccafde65f08ea3e0d5debaf16e2545d9d1" ] }
Dockerfile ビルドの失敗
次の例は、失敗した Dockerfile ビルドからの応答です。
{ "build_id": "5346a21d-3434-4764-85be-5be1296f293c", "trigger_kind": "github", //Optional "name": "test", "repository": "dgangaia/test", "docker_url": "quay.io/dgangaia/test", "error_message": "Could not find or parse Dockerfile: unknown instruction: GIT", "namespace": "dgangaia", "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional "docker_tags": [ "master", "latest" ], "build_name": "6ae9a86", "trigger_metadata": { //Optional "commit": "6ae9a86930fc73dd07b02e4c5bf63ee60be180ad", "ref": "refs/heads/master", "default_branch": "master", "git_url": "git@github.com:dgangaia/test.git", "commit_info": { //Optional "url": "https://github.com/dgangaia/test/commit/6ae9a86930fc73dd07b02e4c5bf63ee60be180ad", "date": "2019-03-06T14:18:16+11:00", "message": "failed build test", "committer": { //Optional "username": "web-flow", "url": "https://github.com/web-flow", //Optional "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional }, "author": { //Optional "username": "dgangaia", "url": "https://github.com/dgangaia", //Optional "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional } } }, "homepage": "https://quay.io/repository/dgangaia/test/build/5346a21d-3434-4764-85be-5be1296f293c" }
Dockerfile ビルドのキャンセル
次の例は、キャンセルされた Dockerfile ビルドからの応答です。
{ "build_id": "cbd534c5-f1c0-4816-b4e3-55446b851e70", "trigger_kind": "github", "name": "test", "repository": "dgangaia/test", "namespace": "dgangaia", "docker_url": "quay.io/dgangaia/test", "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", "docker_tags": [ "master", "latest" ], "build_name": "cbce83c", "trigger_metadata": { "commit": "cbce83c04bfb59734fc42a83aab738704ba7ec41", "ref": "refs/heads/master", "default_branch": "master", "git_url": "git@github.com:dgangaia/test.git", "commit_info": { "url": "https://github.com/dgangaia/test/commit/cbce83c04bfb59734fc42a83aab738704ba7ec41", "date": "2019-03-06T14:27:53+11:00", "message": "testing cancel build", "committer": { "username": "web-flow", "url": "https://github.com/web-flow", "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" }, "author": { "username": "dgangaia", "url": "https://github.com/dgangaia", "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" } } }, "homepage": "https://quay.io/repository/dgangaia/test/build/cbd534c5-f1c0-4816-b4e3-55446b851e70" }
第14章 Open Container Initiative のサポート
コンテナーレジストリーは、当初 Docker イメージ形式のコンテナーイメージをサポートするように設計されていました。Docker 以外で追加のランタイムの使用をプロモートするために、コンテナーランタイムとイメージ形式に関連する標準化を提供するために Open Container Initiative (OCI) が作成されました。ほとんどのコンテナーレジストリーは、Docker イメージマニフェスト V2、Schema 2 形式をベースとして OCI 標準化をサポートします。
コンテナーイメージのほかにも、個別のアプリケーションだけでなく、Kubernetes プラットフォームを全体としてサポートする各種のアーティファクトが新たに出現しました。これは、アプリケーションのデプロイメントを支援するセキュリティーおよびガバナンスの Open Policy Agent (OPA) ポリシーから Helm チャートおよび Operator に及びます。
Quay.io は、コンテナーイメージを格納するだけでなく、コンテナーの管理を支援するツールのエコシステム全体もサポートするプライベートコンテナーレジストリーです。Quay.io は、OCI 1.1 Image and Distribution specifications と可能な限り互換性を保つよう努めており、Helm チャート (OCI をサポートする Helm のバージョンを使用してプッシュされている場合に限る) などの一般的なメディアタイプや、コンテナーイメージのマニフェストまたはレイヤーコンポーネント内部のさまざまな任意のメディアタイプをサポートしています。OCI メディアタイプのサポートが、以前の Quay.io のバージョンと異なる点です。以前のバージョンでは、受け入れるメディアタイプについてより厳しい制限がレジストリーに設けられていました。Quay.io は、以前はサポート範囲外だったメディアタイプも含め、より幅広いメディアタイプに対応できるようになりました。そのため、標準のコンテナーイメージ形式だけでなく、新しいタイプや従来とは異なるタイプにも対応できるようになり、より多用途になりました。
新しいメディアタイプへのサポート拡張に加えて、Quay.io は、V2_2 および V2_1 形式を含む Docker イメージとの互換性を確保しています。このような Docker V2_2 および V2_1 イメージとの互換性は、Docker ユーザーにシームレスなエクスペリエンスを提供するという Quay.io の取り組みを表すものです。さらに、Quay.io は、引き続き Docker V1 プルのサポートを拡張し、このような以前のバージョンの Docker イメージを現在も利用している可能性のあるユーザーに対応します。
OCI アーティファクトのサポートはデフォルトで有効になっています。次の例は、メディアタイプの使用方法を示しています。これは、他の OCI メディアタイプを使用する際の例として使用できます。
14.1. Helm および OCI の前提条件
Helm は、アプリケーションのパッケージ化とデプロイの方法を簡素化します。Helm は、アプリケーションを表す Kubernetes リソースが含まれる チャート というパッケージ形式を使用します。Quay.io は、OCI でサポートされているバージョンである限り、Helm チャートをサポートします。
次の手順に従って、Helm およびその他の OCI メディアタイプを使用するようにシステムを事前設定します。
Helm の最新バージョンは、Helm リリース ページからダウンロードできます。
14.2. Helm チャートの使用
以下の例を使用して、Red Hat Community of Practice (CoP) リポジトリーから etherpad チャートをダウンロードしてプッシュします。
前提条件
- Quay.io にログインしている。
手順
次のコマンドを入力して、チャートリポジトリーを追加します。
$ helm repo add redhat-cop https://redhat-cop.github.io/helm-charts
次のコマンドを入力して、チャートリポジトリーから、ローカルで使用可能なチャートの情報を更新します。
$ helm repo update
次のコマンドを入力して、リポジトリーからチャートを取得します。
$ helm pull redhat-cop/etherpad --version=0.0.4 --untar
次のコマンドを入力して、チャートをチャートアーカイブにパッケージ化します。
$ helm package ./etherpad
出力例
Successfully packaged chart and saved it to: /home/user/linux-amd64/etherpad-0.0.4.tgz
helm registry login
を使用して Quay.io にログインします。$ helm registry login quay.io
helm push
コマンドを使用して、チャートをリポジトリーにプッシュします。helm push etherpad-0.0.4.tgz oci://quay.io/<organization_name>/helm
出力例:
Pushed: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4 Digest: sha256:a6667ff2a0e2bd7aa4813db9ac854b5124ff1c458d170b70c2d2375325f2451b
ローカルコピーを削除してから、リポジトリーからチャートをプルして、プッシュが機能したことを確認します。
$ rm -rf etherpad-0.0.4.tgz
$ helm pull oci://quay.io/<organization_name>/helm/etherpad --version 0.0.4
出力例:
Pulled: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4 Digest: sha256:4f627399685880daf30cf77b6026dc129034d68c7676c7e07020b70cf7130902
14.3. Cosign OCI のサポート
Cosign は、コンテナーイメージの署名および検証に使用できるツールです。ECDSA-P256
署名アルゴリズムおよび Red Hat の Simple Signing ペイロード形式を使用して、PKIX ファイルに保存される公開鍵を作成します。秘密鍵は暗号化された PEM ファイルとして保存されます。
Cosign は現在、以下をサポートしています。
- ハードウェアおよび KMS の署名
- 自身の PKI を使用
- OIDC PKI
- 組み込みのバイナリー透過性およびタイムスタンプサービス
Cosign を直接インストールするには、次の手順を実行します。
前提条件
- Go バージョン 1.16 以降がインストールされている。
手順
次の
go
コマンドを入力して、Cosign を直接インストールします。$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0
出力例
go: downloading github.com/sigstore/cosign v1.0.0 go: downloading github.com/peterbourgon/ff/v3 v3.1.0
次のコマンドを入力して、Cosign 用のキーと値のペアを生成します。
$ cosign generate-key-pair
出力例
Enter password for private key: Enter again: Private key written to cosign.key Public key written to cosign.pub
次のコマンドを入力して、キーと値のペアに署名します。
$ cosign sign -key cosign.key quay.io/user1/busybox:test
出力例
Enter password for private key: Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig
認証に
~./docker/config.json
に依存していることが原因で起こるerror: signing quay-server.example.com/user1/busybox:test: getting remote image: GET https://quay-server.example.com/v2/user1/busybox/manifests/test: UNAUTHORIZED: access to the requested resource is not authorized; map[]
エラーが発生した場合は、次のコマンドを実行する必要がある場合があります。$ podman login --authfile ~/.docker/config.json quay.io
出力例
Username: Password: Login Succeeded!
次のコマンドを入力して、更新された認可設定を確認します。
$ cat ~/.docker/config.json { "auths": { "quay-server.example.com": { "auth": "cXVheWFkbWluOnBhc3N3b3Jk" } }
14.4. Cosign のインストールと使用
Cosign を直接インストールするには、次の手順を実行します。
前提条件
- Go バージョン 1.16 以降がインストールされている。
-
config.yaml
ファイルでFEATURE_GENERAL_OCI_SUPPORT
をtrue
に設定している。
手順
次の
go
コマンドを入力して、Cosign を直接インストールします。$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0
出力例
go: downloading github.com/sigstore/cosign v1.0.0 go: downloading github.com/peterbourgon/ff/v3 v3.1.0
次のコマンドを入力して、Cosign 用のキーと値のペアを生成します。
$ cosign generate-key-pair
出力例
Enter password for private key: Enter again: Private key written to cosign.key Public key written to cosign.pub
次のコマンドを入力して、キーと値のペアに署名します。
$ cosign sign -key cosign.key quay.io/user1/busybox:test
出力例
Enter password for private key: Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig
認証に
~./docker/config.json
に依存していることが原因で起こるerror: signing quay-server.example.com/user1/busybox:test: getting remote image: GET https://quay-server.example.com/v2/user1/busybox/manifests/test: UNAUTHORIZED: access to the requested resource is not authorized; map[]
エラーが発生した場合は、次のコマンドを実行する必要がある場合があります。$ podman login --authfile ~/.docker/config.json quay.io
出力例
Username: Password: Login Succeeded!
次のコマンドを入力して、更新された認可設定を確認します。
$ cat ~/.docker/config.json { "auths": { "quay-server.example.com": { "auth": "cXVheWFkbWluOnBhc3N3b3Jk" } }