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

7.3. OLM 1.0 (テクノロジープレビュー) のカタログから Operator をインストールする

クラスター管理者は、カタログ、つまり Operator と Kubernetes 拡張機能の厳選されたコレクションをクラスターに追加できます。Operator の作成者は、自社の製品をこれらのカタログに公開します。クラスターにカタログを追加すると、カタログに公開されている Operator と拡張機能のバージョン、パッチ、無線更新にアクセスできるようになります。

Operator Lifecycle Manager (OLM) 1.0 の現在のテクノロジープレビューリリースでは、カスタムリソース (CR) を使用して CLI からカタログと Operators を宣言的に管理します。

重要

OLM 1.0 は、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

7.3.1. 前提条件
リンクのコピー

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

    注記

    OpenShift Container Platform 4.15 では、OLM 1.0 に関する手順書が CLI ベースのものに限られています。別の方法として、管理者は、Import YAML ページや Search ページなどの通常の方法を使用して、Web コンソールで関連オブジェクトを作成および表示することもできます。ただし、既存の OperatorHub および Installed Operators ページに OLM 1.0 コンポーネントはまだ表示されません。

  • クラスターで有効になっている TechPreviewNoUpgrade 機能セット。

    警告

    TechPreviewNoUpgrade 機能セットを有効にすると元に戻すことができなくなり、マイナーバージョンの更新ができなくなります。これらの機能セットは、実稼働クラスターでは推奨されません。

  • OpenShift CLI (oc) がワークステーションにインストールされている。

7.3.2. OLM 1.0 のカタログについて
リンクのコピー

catalogd コンポーネントを使用して、Operator やコントローラーなどの Kubernetes 拡張機能のカタログをクエリーすることで、インストール可能なコンテンツを検出できます。Catalogd は、クラスター上のクライアント用にカタログコンテンツを展開する Kubernetes 機能拡張であり、マイクロサービスの Operator Lifecycle Manager (OLM) 1.0 スイートの一部です。現在、catalogd は、コンテナーイメージとしてパッケージ化および配布されているカタログコンテンツを解凍します。

重要

一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。

  • 複数のカタログがクラスターにインストールされている場合、OLM 1.0 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムが含まれていません。
  • Operator Lifecycle Manager (OLM) 1.0 で依存関係を解決するためには、クラスターにインストールできるすべての Operator と拡張機能がバンドルとパッケージに一意の名前を使用する必要があります。

7.3.3. OLM 1.0 で Red Hat が提供する Operator カタログ
リンクのコピー

Operator Lifecycle Manager (OLM) 1.0 には、デフォルトでは Red Hat が提供する Operator カタログが含まれていません。Red Hat が提供するカタログをクラスターに追加する場合は、カタログのカスタムリソース (CR) を作成し、クラスターに適用します。次のカスタムリソース (CR) の例は、OLM 1.0 のカタログリソースを作成する方法を示しています。

重要

Red Hat が提供する registry.redhat.io の Operator カタログなど、セキュアなレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace をスコープとするプルシークレットが必要です。詳細は、「セキュアなレジストリーでホストされるカタログのプルシークレットを作成する」を参照してください。

Red Hat Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: <poll_interval_duration>
1

1
新しいイメージダイジェストを確認するためにリモートレジストリーをポーリングする間隔を指定します。デフォルト値は、24h です。有効な単位は、秒 (s)、分 (m)、および時間 (h) です。ポーリングを無効にするには、0s などのゼロ値を設定します。

認定 Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

コミュニティー Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

次のコマンドは、クラスターにカタログを追加します。

コマンド構文

$ oc apply -f <catalog_name>.yaml
1

1
redhat-operators.yaml などのカタログ CR を指定します。

7.3.4. セキュアなレジストリーでホストされるカタログのプルシークレットを作成する
リンクのコピー

Red Hat が提供する registry.redhat.io の Operator カタログなど、セキュアなレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace をスコープとするプルシークレットが必要です。

注記

現在、catalogd は OpenShift Container Platform クラスターからグローバルプルシークレットを読み取ることができません。Catalogd は、それがデプロイされている namespace でのみシークレットへの参照を読み取ることができます。

前提条件

  • セキュアなレジストリーのログイン認証情報
  • Docker または Podman がワークステーションにインストールされている。

手順

  • セキュアなレジストリーのログイン認証情報を含む .dockercfg ファイルがすでにある場合は、次のコマンドを実行してプルシークレットを作成します。 

    $ oc create secret generic <pull_secret_name> \
    --from-file=.dockercfg=<file_path>/.dockercfg \
    --type=kubernetes.io/dockercfg \
    --namespace=openshift-catalogd

    例7.1 コマンドの例

    $ oc create secret generic redhat-cred \
    --from-file=.dockercfg=/home/<username>/.dockercfg \
    --type=kubernetes.io/dockercfg \
    --namespace=openshift-catalogd

  • 保護されたレジストリーのログイン認証情報を含む $HOME/.docker/config.json ファイルがすでにある場合は、次のコマンドを実行してプルシークレットを作成します。 

    $ oc create secret generic <pull_secret_name> \
    --from-file=.dockerconfigjson=<file_path>/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson \
    --namespace=openshift-catalogd

    例7.2 コマンドの例

    $ oc create secret generic redhat-cred \
    --from-file=.dockerconfigjson=/home/<username>/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson \
    --namespace=openshift-catalogd

  • セキュアなレジストリーのログイン認証情報を含む Docker 設定ファイルがない場合は、次のコマンドを実行してプルシークレットを作成します。 

    $ oc create secret docker-registry <pull_secret_name> \
    --docker-server=<registry_server> \
    --docker-username=<username> \
    --docker-password=<password> \
    --docker-email=<email> \
    --namespace=openshift-catalogd

    例7.3 コマンドの例

    $ oc create secret docker-registry redhat-cred \
    --docker-server=registry.redhat.io \
    --docker-username=username \
    --docker-password=password \
    --docker-email=user@example.com \
    --namespace=openshift-catalogd

7.3.5. クラスターへのカタログの追加
リンクのコピー

カタログをクラスターに追加するには、カタログカスタムリソース (CR) を作成し、それをクラスターに適用します。

前提条件

  • Red Hat が提供する registry.redhat.io の Operator カタログなど、セキュアなレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace をスコープとするプルシークレットが必要です。詳細は、「セキュアなレジストリーでホストされるカタログのプルシークレットを作成する」を参照してください。

手順

  1. 次の例のようなカタログカスタムリソース (CR) を作成します。

    redhat-operators.yaml の例

    apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15
    1 
    
      pullSecret: <pull_secret_name>
    2 
    
      pollInterval: <poll_interval_duration>
    3

    1
    spec.source.image フィールドにカタログのイメージを指定します。
    2
    カタログが registry.redhat.io などのセキュアなレジストリーでホストされている場合は、スコープを openshift-catalog namespace に設定したプルシークレットを作成する必要があります。
    3
    新しいイメージダイジェストを確認するためにリモートレジストリーをポーリングする間隔を指定します。デフォルト値は、24h です。有効な単位は、秒 (s)、分 (m)、および時間 (h) です。ポーリングを無効にするには、0s などのゼロ値を設定します。

  2. 次のコマンドを実行して、カタログをクラスターに追加します。 

    $ oc apply -f redhat-operators.yaml

    出力例

    catalog.catalogd.operatorframework.io/redhat-operators created

検証

  • 次のコマンドを実行して、カタログのステータスを確認します。

    1. 次のコマンドを実行して、カタログが利用可能かどうかを確認します。 

      $ oc get catalog

      出力例

      NAME                  AGE
redhat-operators      20s

    2. 次のコマンドを実行して、カタログのステータスを確認します。 

      $ oc describe catalog

      出力例

      Name:         redhat-operators
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  catalogd.operatorframework.io/v1alpha1
Kind:         Catalog
Metadata:
  Creation Timestamp:  2024-01-10T16:18:38Z
  Finalizers:
    catalogd.operatorframework.io/delete-server-cache
  Generation:        1
  Resource Version:  57057
  UID:               128db204-49b3-45ee-bfea-a2e6fc8e34ea
Spec:
  Source:
    Image:
      Pull Secret:  redhat-cred
      Ref:          registry.redhat.io/redhat/redhat-operator-index:v4.15
    Type:           image
Status:
      1 
      
  Conditions:
    Last Transition Time:  2024-01-10T16:18:55Z
    Message:
    Reason:                UnpackSuccessful
      2 
      
    Status:                True
    Type:                  Unpacked
  Content URL:             http://catalogd-catalogserver.openshift-catalogd.svc/catalogs/redhat-operators/all.json
  Observed Generation:     1
  Phase:                   Unpacked
      3 
      
  Resolved Source:
    Image:
      Last Poll Attempt:  2024-01-10T16:18:51Z
      Ref:                registry.redhat.io/redhat/redhat-operator-index:v4.15
      Resolved Ref:       registry.redhat.io/redhat/redhat-operator-index@sha256:7b536ae19b8e9f74bb521c4a61e5818e036ac1865a932f2157c6c9a766b2eea5
      4 
      
    Type:                 image
Events:                   <none>

      1
      カタログのステータスを記述します。
      2
      カタログが現在の状態になっている理由を表示します。
      3
      インストールプロセスのフェーズを表示します。
      4
      カタログのイメージ参照を表示します。

7.3.6. カタログからインストールする Operator を見つける
リンクのコピー

クラスターにカタログを追加した後、カタログにクエリーを実行して、インストールする Operator と拡張機能を見つけることができます。カタログをクエリーする前に、カタログサーバーサービスをポート転送する必要があります。

前提条件

  • クラスターにカタログを追加している。
  • jq CLI ツールがインストールされている。

手順

  1. 次のコマンドを実行して、openshift-catalogd namespace のカタログサーバーサービスのポート転送を行います。 

    $ oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:80

  2. 次のコマンドを実行して、カタログの JSON ファイルをローカルにダウンロードします。 

    $ curl -L http://localhost:8080/catalogs/<catalog_name>/all.json \
  -C - -o /<path>/<catalog_name>.json

    例7.4 コマンドの例

    $ curl -L http://localhost:8080/catalogs/redhat-operators/all.json \
  -C - -o /home/username/catalogs/rhoc.json

  3. 次のコマンドのいずれかを実行して、カタログ内のオペレータと拡張機能のリストを返します。

    重要

    現在、Operator Lifecycle Manager (OLM) 1.0 は、Webhook を使用せず、AllNamespaces インストールモードを使用するように設定された拡張機能をサポートしています。Webhook を使用する拡張機能、または単一の namespace または指定された一連の namespace をターゲットとする拡張機能はインストールできません。

    • 次のコマンドを実行して、ローカルカタログファイルからすべての Operator と拡張機能のリストを取得します。 

      $ jq -s '.[] | select(.schema == "olm.package") | .name' \
  /<path>/<filename>.json

      例7.5 コマンドの例

      $ jq -s '.[] | select(.schema == "olm.package") | .name' \
  /home/username/catalogs/rhoc.json

      例7.6 出力例

      NAME                                                        AGE
"3scale-operator"
"advanced-cluster-management"
"amq-broker-rhel8"
"amq-online"
"amq-streams"
"amq7-interconnect-operator"
"ansible-automation-platform-operator"
"ansible-cloud-addons-operator"
"apicast-operator"
"aws-efs-csi-driver-operator"
"aws-load-balancer-operator"
"bamoe-businessautomation-operator"
"bamoe-kogito-operator"
"bare-metal-event-relay"
"businessautomation-operator"
...

    • 次のコマンドを実行して、AllNamespaces インストールモードをサポートし、Webhook を使用しないパッケージのリストを、ローカルカタログファイルから取得します。 

      $ jq -c 'select(.schema == "olm.bundle") | \
  {"package":.package, "version":.properties[] | \
  select(.type == "olm.bundle.object").value.data | @base64d | fromjson | \
  select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
  select(.type == "AllNamespaces" and .supported == true) != null) \
  and .spec.webhookdefinitions == null).spec.version}' \
  /<path>/<catalog_name>.json

      例7.7 出力例

      {"package":"3scale-operator","version":"0.10.0-mas"}
{"package":"3scale-operator","version":"0.10.5"}
{"package":"3scale-operator","version":"0.11.0-mas"}
{"package":"3scale-operator","version":"0.11.1-mas"}
{"package":"3scale-operator","version":"0.11.2-mas"}
{"package":"3scale-operator","version":"0.11.3-mas"}
{"package":"3scale-operator","version":"0.11.5-mas"}
{"package":"3scale-operator","version":"0.11.6-mas"}
{"package":"3scale-operator","version":"0.11.7-mas"}
{"package":"3scale-operator","version":"0.11.8-mas"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-2"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-3"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-4"}
{"package":"amq-broker-rhel8","version":"7.10.1-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.1-opr-2"}
{"package":"amq-broker-rhel8","version":"7.10.2-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.2-opr-2"}
...

  4. 次のコマンドを実行して、Operator または拡張機能のメタデータの内容を検査します。 

    $ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "<package_name>")' /<path>/<catalog_name>.json

    例7.8 コマンドの例

    $ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "openshift-pipelines-operator-rh")' \
  /home/username/rhoc.json

    例7.9 出力例

    {
  "defaultChannel": "stable",
  "icon": {
    "base64data": "PHN2ZyB4bWxu..."
    "mediatype": "image/png"
  },
  "name": "openshift-pipelines-operator-rh",
  "schema": "olm.package"
}

7.3.6.1. 一般的なカタログクエリー
リンクのコピー

jq CLI ツールを使用して、カタログをクエリーできます。

Expand
表7.1 一般的なパッケージクエリー
クエリーRequest

カタログで利用可能なパッケージ 

$ jq -s '.[] | select( .schema == "olm.package") | \
  .name' <catalog_name>.json

AllNamespaces インストールモードをサポートし、Webhook を使用しないパッケージ 

$ jq -c 'select(.schema == "olm.bundle") | \
  {"package":.package, "version":.properties[] | \
  select(.type == "olm.bundle.object").value.data | \
  @base64d | fromjson | \
  select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
  select(.type == "AllNamespaces" and .supported == true) != null) \
  and .spec.webhookdefinitions == null).spec.version}' \
  <catalog_name>.json

パッケージのメタデータ 

$ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "<package_name>")' <catalog_name>.json

パッケージ内のカタログブロブ 

$ jq -s '.[] | select( .package == "<package_name>")' \
  <catalog_name>.json
Expand
表7.2 一般的なチャネルクエリー
クエリーRequest

パッケージのチャネル 

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json

チャネル内のバージョン 

$ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | \
  .entries | .[] | .name' <catalog_name>.json
  • チャネルの最新バージョン
  • アップグレードパス 
$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select ( .name == "<channel>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json
Expand
表7.3 一般的なバンドルクエリー
クエリーRequest

パッケージ内のバンドル 

$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json
  • 依存関係をバンドルする
  • 利用可能な API 
$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select ( .name == "<bundle_name>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json

7.3.7. カタログからの Operator をインストールする
リンクのコピー

Operator Lifecycle Manager (OLM) 1.0 は、クラスターをスコープ指定した Operator と拡張機能のインストールをサポートします。カスタムリソース (CR) を作成し、それをクラスターに適用することで、カタログから Operator または拡張機能をインストールできます。

重要

現在、OLM 1.0 では、次の基準を満たす Operator とエクステンションのインストールがサポートされています。

  • Operator または拡張機能は、AllNamespaces インストールモードを使用する必要があります。
  • Operator または拡張機能は Webhook を使用してはなりません。

Webhook を使用する Operator やエクステンション、または単一あるいは指定された namespace のセットを対象とする Operator やエクステンションはインストールできません。

前提条件

  • クラスターにカタログを追加している。
  • カタログファイルのローカルコピーをダウンロードしている。
  • jq CLI ツールがインストールされている。

手順

  1. 次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。

    1. 次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。 

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | \
  .name' /<path>/<catalog_name>.json

      例7.10 コマンドの例

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "openshift-pipelines-operator-rh") | \
  .name' /home/username/rhoc.json

      例7.11 出力例

      "latest"
"pipelines-1.11"
"pipelines-1.12"
"pipelines-1.13"

    2. 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。 

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | .entries | \
  .[] | .name' /<path>/<catalog_name>.json

      例7.12 コマンドの例

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
.entries | .[] | .name' /home/username/rhoc.json

      例7.13 出力例

      "openshift-pipelines-operator-rh.v1.11.1"
"openshift-pipelines-operator-rh.v1.12.0"
"openshift-pipelines-operator-rh.v1.12.1"
"openshift-pipelines-operator-rh.v1.12.2"
"openshift-pipelines-operator-rh.v1.13.0"
"openshift-pipelines-operator-rh.v1.13.1"

  2. 次の例のような CR を作成します。

    pipelines-operator.yaml CR の例

    apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: <channel>
  version: "<version>"

    ここでは、以下のようになります。

    <channel>
    オプション: インストールまたは更新するパッケージのチャネル (pipelines-1.11、latest など) を指定します。
    <version>

    オプション: インストールまたは更新するパッケージのバージョンまたはバージョン範囲 (1.11.1、1.12.x、>=1.12.1 など) を指定します。詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」および「バージョン範囲のサポート」を参照してください。

    重要

    一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。

    • 複数のカタログがクラスターにインストールされている場合、OLM 1.0 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムが含まれていません。
    • Operator Lifecycle Manager (OLM) 1.0 で依存関係を解決するためには、クラスターにインストールできるすべての Operator と拡張機能がバンドルとパッケージに一意の名前を使用する必要があります。

  3. 次のコマンドを実行して、CR をクラスターに適用します。 

    $ oc apply -f pipeline-operator.yaml

    出力例

    operator.operators.operatorframework.io/pipelines-operator created

検証

  1. 次のコマンドを実行して、Operator または拡張機能の CR を YAML 形式で表示します。 

    $ oc get operator.operators.operatorframework.io pipelines-operator -o yaml
    注記

    OLM 1.0 では、Operator または拡張機能の CR でチャネルを指定するかバージョン範囲を定義すると、クラスターにインストールされている解決済みバージョンは表示されません。CR で指定されたバージョンとチャネル情報のみが表示されます。

    インストールされている特定のバージョンを見つける必要がある場合は、spec.source.image.ref フィールドのイメージの SHA をカタログ内のイメージ参照と比較する必要があります。

    例7.14 出力例

    apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.11.x"}}
  creationTimestamp: "2024-01-30T20:06:09Z"
  generation: 1
  name: pipelines-operator
  resourceVersion: "44362"
  uid: 4272d228-22e1-419e-b9a7-986f982ee588
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.11.x
status:
  conditions:
  - lastTransitionTime: "2024-01-30T20:06:15Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2024-01-30T20:06:31Z"
    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280

  2. 次のコマンドを実行して、バンドルのデプロイメントに関する情報を取得します。 

    $ oc get bundleDeployment pipelines-operator -o yaml

    例7.15 出力例

    apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  creationTimestamp: "2024-01-30T20:06:15Z"
  generation: 2
  name: pipelines-operator
  ownerReferences:
  - apiVersion: operators.operatorframework.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Operator
    name: pipelines-operator
    uid: 4272d228-22e1-419e-b9a7-986f982ee588
  resourceVersion: "44464"
  uid: 0a0c3525-27e2-4c93-bf57-55920a7707c0
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata: {}
    spec:
      provisionerClassName: core-rukpak-io-registry
      source:
        image:
          ref: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280
        type: image
status:
  activeBundle: pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
  conditions:
  - lastTransitionTime: "2024-01-30T20:06:15Z"
    message: Successfully unpacked the pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
      Bundle
    reason: UnpackSuccessful
    status: "True"
    type: HasValidBundle
  - lastTransitionTime: "2024-01-30T20:06:28Z"
    message: Instantiated bundle pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
      successfully
    reason: InstallationSucceeded
    status: "True"
    type: Installed
  - lastTransitionTime: "2024-01-30T20:06:40Z"
    message: BundleDeployment is healthy
    reason: Healthy
    status: "True"
    type: Healthy
  observedGeneration: 2

7.3.8. Operator の更新
リンクのコピー

カスタムリソース (CR) を手動で編集し、変更を適用することで、Operator または拡張機能を更新できます。

前提条件

  • カタログがインストールされています。
  • カタログファイルのローカルコピーをダウンロードしている。
  • Operator または拡張機能がインストールされている。
  • jq CLI ツールがインストールされている。

手順

  1. 次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。

    1. 次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。 

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | \
  .name' /<path>/<catalog_name>.json

      例7.16 コマンドの例

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "openshift-pipelines-operator-rh") | \
  .name' /home/username/rhoc.json

      例7.17 出力例

      "latest"
"pipelines-1.11"
"pipelines-1.12"
"pipelines-1.13"

    2. 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。 

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | .entries | \
  .[] | .name' /<path>/<catalog_name>.json

      例7.18 コマンドの例

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
.entries | .[] | .name' /home/username/rhoc.json

      例7.19 出力例

      "openshift-pipelines-operator-rh.v1.11.1"
"openshift-pipelines-operator-rh.v1.12.0"
"openshift-pipelines-operator-rh.v1.12.1"
"openshift-pipelines-operator-rh.v1.12.2"
"openshift-pipelines-operator-rh.v1.13.0"
"openshift-pipelines-operator-rh.v1.13.1"

  2. 次のコマンドを実行して、Operator または拡張機能の CR で指定されているバージョンまたはチャネルを確認します。 

    $ oc get operator.operators.operatorframework.io <operator_name> -o yaml

    コマンドの例

    $ oc get operator.operators.operatorframework.io pipelines-operator -o yaml

    例7.20 出力例

    apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |  {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.11.1"}}
  creationTimestamp: "2024-02-06T17:47:15Z"
  generation: 2
  name: pipelines-operator
  resourceVersion: "84528"
  uid: dffe2c89-b9c4-427e-b694-ada0b37fc0a9
spec:
  channel: latest
    1 
    
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.11.1
    2 
    
status:
  conditions:
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: bundledeployment status is unknown
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2024-02-06T17:50:58Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280
    1
    Operator または拡張機能のチャネルを指定します。
    2
    Operator または拡張機能のバージョンまたはバージョン範囲を指定します。
    注記

    OLM 1.0 では、Operator または拡張機能の CR でチャネルを指定するかバージョン範囲を定義すると、クラスターにインストールされている解決済みバージョンは表示されません。CR で指定されたバージョンとチャネル情報のみが表示されます。

    インストールされている特定のバージョンを見つける必要がある場合は、spec.source.image.ref フィールドのイメージの SHA をカタログ内のイメージ参照と比較する必要があります。

  3. 次のいずれかの方法を使用して CR を編集します。

    • Operator または拡張機能を特定のバージョン (1.12.1 など) に固定する場合は、次の例のように CR を編集します。

      pipelines-operator.yaml CR の例

      apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.12.1
      1

      1
      バージョンを 1.11.1 から 1.12.1 に更新します。

    • 許容可能な更新バージョンの範囲を定義する場合は、次の例のように CR を編集します。

      バージョン範囲を指定した CR の例

      apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: ">1.11.1, <1.13"
      1

      1
      必要なバージョン範囲が、バージョン 1.11.1 より大きく、1.13 より小さいことを指定します。詳細は、「バージョン範囲のサポート」および「バージョン比較文字列」を参照してください。

    • チャネルから解決できる最新バージョンに更新する場合は、次の例のように CR を編集します。

      チャネルを指定した CR の例

      apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: pipelines-1.13
      1

      1
      指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。

    • チャネルとバージョンまたはバージョン範囲を指定する場合は、次の例のように CR を編集します。

      チャネルとバージョン範囲を指定した CR の例

      apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest
  version: "<1.13"

      詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」を参照してください。

  4. 次のコマンドを実行して、クラスターに更新を適用します。 

    $ oc apply -f pipelines-operator.yaml

    出力例

    operator.operators.operatorframework.io/pipelines-operator configured

    ヒント

    次のコマンドを実行すると、CLI から CR にパッチを適用して変更を適用できます。 

    $ oc patch operator.operators.operatorframework.io/pipelines-operator -p \
  '{"spec":{"version":"1.12.1"}}' \
  --type=merge

    出力例

    operator.operators.operatorframework.io/pipelines-operator patched

検証

  • 次のコマンドを実行して、チャネルとバージョンの更新が適用されていることを確認します。 

    $ oc get operator.operators.operatorframework.io pipelines-operator -o yaml

    例7.21 出力例

    apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.12.1"}}
  creationTimestamp: "2024-02-06T19:16:12Z"
  generation: 4
  name: pipelines-operator
  resourceVersion: "58122"
  uid: 886bbf73-604f-4484-9f87-af6ce0f86914
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.12.1
    1 
    
status:
  conditions:
  - lastTransitionTime: "2024-02-06T19:30:57Z"
    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a"
    observedGeneration: 3
    reason: Success
    status: "True"
    type: Installed
  - lastTransitionTime: "2024-02-06T19:30:57Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a"
    observedGeneration: 3
    reason: Success
    status: "True"
    type: Resolved
  installedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a
    1
    バージョンが 1.12.1 に更新されていることを確認します。

トラブルシューティング

  • 存在しないターゲットバージョンまたはチャネルを指定した場合は、次のコマンドを実行して Operator または拡張機能のステータスを確認できます。 

    $ oc get operator.operators.operatorframework.io <operator_name> -o yaml

    例7.22 出力例

    oc get operator.operators.operatorframework.io pipelines-operator -o yaml
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"2.0.0"}}
  creationTimestamp: "2024-02-06T17:47:15Z"
  generation: 1
  name: pipelines-operator
  resourceVersion: "82667"
  uid: dffe2c89-b9c4-427e-b694-ada0b37fc0a9
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 2.0.0
status:
  conditions:
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: installation has not been attempted due to failure to gather data for
      resolution
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: no package "openshift-pipelines-operator-rh" matching version "2.0.0"
      found in channel "latest"
    observedGeneration: 1
    reason: ResolutionFailed
    status: "False"
    type: Resolved

7.3.8.1. セマンティックバージョニングのサポート
リンクのコピー

OLM 1.0 では、semantic versioning (semver) のサポートがデフォルトで有効になっています。Operator と拡張機能の作成者は、semver 標準を使用して互換性のある更新を定義できます。

Operator Lifecycle Manager (OLM) 1.0 は、Operator または拡張機能のバージョン番号を使用して、更新が正常に解決できるか判断できます。

クラスター管理者は、インストールして自動的に更新する受け入れ可能なバージョンの範囲を定義できます。semver 標準に準拠した Operator および拡張機能の場合、比較文字列を使用して目的のバージョン範囲を指定できます。

注記

OLM 1.0 は、次のメジャーバージョンへの自動更新をサポートしていません。メジャーバージョンの更新を実行する場合は、手動で更新を確認し、適用する必要があります。詳細は、「更新またはロールバックの強制」を参照してください。

7.3.8.1.1. メジャーバージョン 0 リリース
リンクのコピー

semver 標準では、メジャーバージョン 0 リリース (Oyz) を初期開発用に予約することが指定されています。開発の初期段階では、API は安定していないため、公開済みのバージョンに重大な変更が導入される可能性があります。その結果、メジャーバージョン 0 リリースでは、特別な一連の更新条件が適用されます。

メジャーバージョン 0 リリースの更新条件

  • メジャーバージョンとマイナーバージョンが両方とも 0 の場合 (例: 0.0.*)、自動更新は適用できません。たとえば、バージョン範囲 >=0.0.1 <0.1.0 の自動更新は許可されません。
  • メジャーバージョン 0 リリース内で、あるマイナーバージョンから別のマイナーバージョンへの自動更新は適用できません。たとえば、OLM 1.0 は 0.1.0 から 0.2.0 への更新を自動的に適用しません。
  • >=0.1.0 <0.2.0 または >=0.2.0 <0.3.0 などのパッチバージョンからの自動更新は適用できます。

自動更新が OLM 1.0 によってブロックされている場合は、Operator または拡張機能のカスタムリソース (CR) を編集し、手動で更新を確認して強制する必要があります。

7.3.8.2. バージョン範囲のサポート
リンクのコピー

Operator Lifecycle Manager (OLM) 1.0 では、Operator または拡張機能のカスタムリソース (CR) で比較文字列を使用してバージョン範囲を指定できます。CR でバージョン範囲を指定すると、OLM 1.0 は、そのバージョン範囲内で解決できる Operator の最新バージョンをインストールまたは更新します。

解決済みバージョンのワークフロー

  • 解決済みバージョンは、Operator と環境の依存関係と制約を満たす Operator の最新バージョンです。
  • 正常に解決された場合、指定された範囲内の Operator 更新は自動的にインストールされます。
  • 指定された範囲外にある場合、または正常に解決できない場合、その更新はインストールされません。

OLM 1.0 での依存関係と制約の解決について、詳細は「OLM 1.0 での依存関係の解決」を参照してください。

7.3.8.3. バージョン比較文字列
リンクのコピー

Operator または拡張機能のカスタムリソース (CR) の spec.version フィールドに比較文字列を追加することで、バージョン範囲を定義できます。比較文字列は、スペースまたはコンマで区切られた値と、二重引用符 (") で囲まれた 1 つ以上の比較演算子のリストです。文字列の間に比較演算子の OR または二重縦棒 (||) を含めることで、別の比較文字列を追加できます。

Expand
表7.4 基本的な比較
比較演算子定義

=

等しい

!=

等しくない

>

より大きい

<

より小さい

>=

より大か等しい

<=

より小か等しい

次の例のような範囲比較を使用して、Operator または拡張機能の CR でバージョン範囲を指定できます。

バージョン範囲の比較例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: ">=1.11, <1.13"

すべてのタイプの比較文字列でワイルドカード文字を使用できます。OLM 1.0 では、x、X、およびアスタリスク (*) をワイルドカード文字として使用できます。ワイルドカード文字と比較演算子の等号 (=) を使用する場合は、パッチまたはマイナーバージョンレベルでの比較を定義します。

Expand
表7.5 比較文字列内のワイルドカード文字の例
ワイルドカード比較一致する文字列

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

比較演算子のチルダ (~) を使用して、パッチリリースを比較できます。パッチリリースの比較では、次のメジャーバージョンまでのマイナーバージョンを指定します。

Expand
表7.6 パッチリリースの比較例
パッチリリースの比較一致する文字列

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

比較演算子のキャレット (^) を使用して、メジャーリリースを比較できます。最初の stable リリースが公開される前にメジャーリリース比較を使用する場合、マイナーバージョンにより API の安定レベルが定義されます。セマンティックバージョニング (SemVer) 仕様では、最初のリリ stable ースは 1.0.0 バージョンとして公開されます。

Expand
表7.7 メジャーリリースの比較例
メジャーリリースの比較一致する文字列

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

7.3.8.4. ターゲットバージョンを指定するカスタムリソース (CR) の例
リンクのコピー

Operator Lifecycle Manager (OLM) 1.0 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。

次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。

  • チャネル
  • バージョン番号
  • バージョン範囲

CR でチャネルを指定すると、OLM 1.0 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM 1.0 はそのチャネルから解決できる最新リリースに自動的に更新します。

チャネルを指定した CR の例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest
1

1
指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。

CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM 1.0 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM 1.0 はターゲットバージョンを変更しません。

クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。

ターゲットバージョンを指定した CR の例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.11.1
1

1
ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。

Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM 1.0 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。

バージョン範囲を指定した CR の例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: >1.11.1
1

1
必要なバージョン範囲が、バージョン 1.11.1 より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。

CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。

コマンド構文

$ oc apply -f <extension_name>.yaml

7.3.8.5. 更新またはロールバックの強制
リンクのコピー

OLM 1.0 は、次のメジャーバージョンへの自動更新や以前のバージョンへのロールバックをサポートしていません。メジャーバージョンの更新またはロールバックを実行する場合は、手動で更新を確認して強制する必要があります。

警告

手動更新またはロールバックを強制した場合の影響を確認する必要があります。更新またはロールバックの強制を検証しないと、データ損失などの致命的な結果が生じる可能性があります。

前提条件

  • カタログがインストールされています。
  • Operator または拡張機能がインストールされている。

手順

  1. 次の例に示すように、Operator または拡張機能のカスタムリソース (CR) を編集します。

    CR の例:

    apiVersion: olm.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: <operator_name>
    1 
    
spec:
  packageName: <package_name>
    2 
    
  version: <version>
    3 
    
  upgradeConstraintPolicy: Ignore
    4

    1
    Operator または拡張機能の名前を指定します (pipelines-operator など)。
    2
    openshift-pipelines-operator-rh などのパッケージ名を指定します。
    3
    ブロックされた更新またはロールバックのバージョンを指定します。
    4
    オプション: アップグレード制約ポリシーを指定します。更新またはロールバックを強制するには、このフィールドを Ignore に設定します。指定しない場合、デフォルト設定は Enforce になります。

  2. 次のコマンドを実行して、Operator または拡張機能 CR に変更を適用します。 

    $ oc apply -f <extension_name>.yaml

7.3.9. Operator の削除
リンクのコピー

Operator のカスタムリソース (CR) を削除することで、Operator とそのカスタムリソース定義 (CRD) を削除できます。

前提条件

  • カタログがインストールされています。
  • Operator がインストールされています。

手順

  • 次のコマンドを実行して、Operator とその CRD を削除します。 

    $ oc delete operator.operators.operatorframework.io <operator_name>

    出力例

    operator.operators.operatorframework.io "<operator_name>" deleted

検証

  • 次のコマンドを実行して、Operator とそのリソースが削除されたことを確認します。

    • 次のコマンドを実行して、Operator が削除されたことを確認します。 

      $ oc get operator.operators.operatorframework.io

      出力例

      No resources found

    • 次のコマンドを実行して、Operator のシステム namespace が削除されたことを確認します。 

      $ oc get ns <operator_name>-system

      出力例

      Error from server (NotFound): namespaces "<operator_name>-system" not found

7.3.10. カタログの削除
リンクのコピー

カタログを削除するには、そのカスタムリソース (CR) を削除します。

前提条件

  • カタログがインストールされています。

手順

  • 次のコマンドを実行してカタログを削除します。 

    $ oc delete catalog <catalog_name>

    出力例

    catalog.catalogd.operatorframework.io "my-catalog" deleted

検証

  • 次のコマンドを実行して、カタログが削除されたことを確認します。 

    $ oc get catalog
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る