Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

17.4. Red Hat Quay 3.8 の既知の問題と制限事項

17.4.1. 既知の問題:
リンクのコピー

  • MySQL デプロイメントの logentry3 テーブルの metadata_json 列のサイズは TEXT に制限されています。現在、TEXT に設定されている列のデフォルトサイズは 65535 バイトです。65535 バイトでは、デバッグが オフ になっている場合、いくつかのミラーログには十分な大きさではありません。65535 バイトを超える TEXT を含むステートメントが MySQL に送信されると、送信されたデータは 65535 境界に収まるように切り捨てられます。その結果、これにより、metadata_json オブジェクトがデコードされるときに問題が発生し、文字列が適切に終了されないためにデコードが失敗します。その結果、Red Hat Quay は 500 エラーを返します。

    現在、この問題の回避策はなく、Red Hat Quay の今後のバージョンで対処される予定です。詳細は、PROJQUAY-4305 を参照してください。

  • Podman v4.yz 以降の一部のバージョンで --sign-by-sigstore-private-key フラグを使用する場合は既知の問題があります。このフラグを使用すると、Error: writing signatures: writing sigstore attachments is disabled by configuration エラーが返されます。このフラグを Podman v4 で使用するには、バージョンが v4.2.1 である必要があります。4.2.1 より前のバージョンでは、前述のエラーが返されます。現在、この問題の回避策はなく、Podman の今後のバージョンで対処される予定です。

  • 現在、Podman 4 で Cosign 秘密鍵 sigstore を使用してイメージをプッシュすると、Error: received unexpected HTTP status: 500 Internal Server Error エラーが返されます。これは既知の問題であり、Podman の今後のバージョンで修正される予定です。

    詳細は、PROJQUAY-4588 を参照してください。

  • Red Hat Quay UI v2 で FEATURE_SUPERUSERS_FULL_ACCESS 設定フィールドを使用する場合は、既知の問題があります。このフィールドが設定されている場合は、テナントコンテンツに対するすべてのスーパーユーザーアクションを監査する必要があります。現在、通常のユーザーが所有する既存の組織をスーパーユーザーが削除する場合は、その操作を監査する方法がありません。これは、Red Hat Quay の将来のバージョンで修正される予定です。
  • Red Hat Quay UI v2 で FEATURE_SUPERUSERS_FULL_ACCESS 設定フィールドを使用する場合は、既知の問題があります。config.yaml ファイルでこのフィールドを true に設定すると、Red Hat Quay スーパーユーザーは通常のユーザーが作成した組織を表示できますが、イメージリポジトリーは表示できません。一時的な回避策として、スーパーユーザーは 組織 ページから移動して、そのリポジトリーを表示できます。これは、Red Hat Quay の将来のバージョンで修正される予定です。
  • FEATURE_SUPERUSERS_FULL_ACCESS 設定フィールドを true に設定すると、スーパーユーザーには、通常のユーザーの組織の下に新しいイメージリポジトリーを作成する権限がありません。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。
  • 古い UI で Red Hat Quay を実行している場合は、セッションがタイムアウトになると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、スーパーユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
  • FEATURE_RESTRICTED_USERS が true に設定されている場合、スーパーユーザーは新しい組織を作成できません。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。
  • FEATURE_RESTRICTED_USERS または LDAP_RESTRICTED_USER_FILTER が user1 などのユーザーで設定され、同じユーザーがスーパーユーザーでもある場合、新しい組織を作成することはできません。これは既知の問題です。スーパーユーザー設定フィールドは、制限されたユーザー設定よりも優先される必要がありますが、これも無効な設定です。Red Hat Quay 管理者は、同じユーザーを制限付きユーザーとスーパーユーザーの両方に設定しないでください。これは、Red Hat Quay の今後のバージョンで修正され、スーパーユーザー設定フィールドが制限付きユーザーフィールドよりも優先されるようになります。

  • Red Hat Quay 設定エディターで Enable Storage Replication を選択し、Red Hat Quay デプロイメントを再設定した後、新しい Quay および Mirror Pod の起動に失敗します。このエラーは、Quay および Mirror Pod が、Red Hat Quay 3.8 でサポートされなくなった QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数に依存しているために発生します。

    一時的な回避策として、以下のように QuayRegistry config.yaml ファイルを手動で更新して、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を含める必要があります。 

     spec:
  components:
    - kind: clair
      managed: true
    - kind: postgres
      managed: true
    - kind: objectstorage
      managed: false
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
      overrides:
        env:
          - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
            value: local_us
    - kind: monitoring
      managed: false
    - kind: tls
      managed: true
    - kind: quay
      managed: true
      overrides:
        env:
          - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
            value: local_us
    - kind: clairpostgres
      managed: true
    Copy to Clipboard Toggle word wrap

    これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。

  • Red Hat Quay AWS S3 Cloudfront を設定する場合、新しいパラメーター s3_region が必要です。現在、Red Hat Quay 設定エディターにはこのフィールドが含まれていません。一時的な回避策として、以下のように config.yaml ファイルに s3_region パラメーターを手動で挿入する必要があります。 

    DISTRIBUTED_STORAGE_CONFIG:
    default:
      - CloudFrontedS3Storage
      - cloudfront_distribution_domain: <domain_name>
        cloudfront_distribution_org_overrides: {}
        cloudfront_key_id: <cloudfront_key_id
        cloudfront_privatekey_filename: default_cloudfront_signing_key.pem
        host: s3.us-east-2.amazonaws.com
        s3_access_key: ***
        s3_bucket: ***
        s3_secret_key: ***
        storage_path: /cloudfronts3/quayregistry
        s3_region: us-east-2
    Copy to Clipboard Toggle word wrap

17.4.2. IPv6 とデュアルスタックの制限事項と既知の問題:
リンクのコピー

  • 現在、一般的な Azure Blob Storage 設定を使用して Red Hat Quay デプロイメントを設定しようとしても、IPv6 シングルスタック環境では機能しません。Azure Blob Storage のエンドポイントは IPv6 をサポートしていないため、この問題に対する回避策はありません。

    詳細は、PROJQUAY-4433 を参照してください。

  • 現在、Amazon S3 CloudFront を使用して Red Hat Quay デプロイメントを設定しようとしても、IPv6 シングルスタック環境では機能しません。Amazon S3 CloudFront のエンドポイントは IPv6 をサポートしていないため、この問題に対する回避策はありません。

    詳細は、PROJQUAY-4470 を参照してください。

  • 現在、デュアルスタック (IPv4 および IPv6) のサポートは、Red Hat Quay OpenShift Container Platform デプロイメントでは機能しません。Red Hat Quay 3.8 が OpenShift Container Platform にデプロイされ、IPv6 とデュアルスタックサポートが有効になっている場合、Red Hat Quay Operator によって生成される Quay Route は IPv4 アドレスのみを生成し、IPv6 アドレスは生成しません。その結果、IPv6 アドレスを持つクライアントは、OpenShift Container Platform 上の Red Hat Quay アプリケーションにアクセスできません。この制限は、OpenShift Container Platform 4.12 のリリースで解除されます。
  • 現在、Github と api.github.com は IPv6 をサポートしていません。IPv6 が有効な OpenShift Container Platform に Red Hat Quay がデプロイされている場合、Github 認証を使用するように設定エディターを設定することはできません。
  • 現在、Gitlab は IPv6 をサポートしていません。
  • FEATURE_LISTEN_IP_VERSION が IPv6 に設定され、設定エディターで Red Hat Quay handles TLS を選択し、自己署名証明書をアップロードした場合に既知の問題があります。これらの条件が満たされている場合に、設定エディターでいずれかの設定を更新して (たとえば、新しいスーパーユーザーを追加するなど)、Red Hat Quay を再設定すると、ミラー Pod がクラッシュし、Init:CrashLoopBackOff のエラーが返されます。デプロイで Red Hat Quay handles TLS が選択されている場合には、FEATURE_LISTEN_IP_VERSION を IPv4 に設定する必要があります。これは、Red Hat Quay の将来のバージョンで修正される予定です。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat