手順

1. Home → Projects に移動します。
2. Create Project をクリックします。
3. プロジェクトの詳細を入力します。
4. Create をクリックします。

手順

1. 以下を実行します。

手順

1. Home → Projects に移動します。

2. 表示するプロジェクトを選択します。

   このページで、Resources ボタンをクリックしてプロジェクトのワークロードを確認し、Dashboard ボタンをクリックしてプロジェクトについてのメトリクスおよび詳細情報を確認します。

手順

1. プロジェクトの一覧を表示するには、以下を実行します。

   $ oc get projects

2. CLI 操作について現在のプロジェクトから別のプロジェクトに切り換えることができます。その後の操作についてはすべて指定のプロジェクトが使用され、プロジェクトスコープのコンテンツの操作が実行されます。

   $ oc project <project_name>

手順

1. Home → Projects に移動します。
2. プロジェクトを選択します。
3. Project Status メニューの右上にある Add をクリックし、指定のオプションから選択します。

手順

1. Home → Projects に移動します。
2. ステータスを確認するプロジェクトを選択します。

手順

1. 以下を実行します。

   $ oc status

   このコマンドは、コンポーネントとそれらの各種の関係を含む現在のプロジェクトの概要を示します。

手順

1. Home → Projects に移動します。
2. プロジェクトの一覧から削除するプロジェクトを見つけます。
3. プロジェクト一覧の右端にあるメニューから Delete Project を選択します。プロジェクトを削除するパーミッションがない場合は、Delete Project オプションがグレーアウトするため、オプションをクリックすることができません。

手順

1. 以下を実行します。

   $ oc delete project <project_name>

手順

1. cluster-admin 権限を持つユーザーとしてのログイン。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. cluster-admin 権限を持つユーザーとしてのログイン。

2. 以下のコマンドを実行して、self-provisioners クラスターロールバインディングの使用を確認します。

   $ oc describe clusterrolebinding.rbac self-provisioners
   
   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   self-provisionersセクションのサブジェクトを確認します。

3. self-provisioner クラスターロールをグループ system:authenticated:oauth から削除します。

   • self-provisioners クラスターロールバインディングが self-provisioner ロールのみを system:authenticated:oauth グループにバインドする場合、以下のコマンドを実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • self-provisioners クラスターロールバインディングが self-provisioner ロールを system:authenticated:oauth グループ以外のユーザー、グループまたはサービスアカウントにバインドする場合、以下のコマンドを実行します。

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. ロールへの自動更新を防ぐには、self-provisioners クラスターロールバインディングを編集します。自動更新により、クラスターロールがデフォルトの状態にリセットされます。

   • CLI を使用してロールバインディングを更新するには、以下を実行します。

     1. 以下のコマンドを実行します。

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 表示されるロールバインディングで、以下の例のように rbac.authorization.kubernetes.io/autoupdate パラメーター値を false に設定します。

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • 単一コマンドを使用してロールバインディングを更新するには、以下を実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 認証されたユーザーとしてログインし、プロジェクトのセルフプロビジョニングを実行できないことを確認します。

   $ oc new-project test
   
   Error from server (Forbidden): You may not request a new project via this API.

   組織に固有のより有用な説明を提供できるようこのプロジェクト要求メッセージをカスタマイズすることを検討します。

手順

1. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. cluster-admin 権限を持つユーザーとしてのログイン。

     2. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

2. spec セクションを、projectRequestMessage パラメーターを含むように更新し、値をカスタムメッセージに設定します。

   カスタムプロジェクト要求メッセージを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   例:

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. 変更を保存した後に、プロジェクトをセルフプロビジョニングできない開発者またはサービスアカウントとして新規プロジェクトの作成を試行し、変更が正常に適用されていることを確認します。

手順

1. 削除する Operator を選択します。これを実行するために使用できる 2 つのパスがあります。

   • Catalog → OperatorHub ページの使用:

     1. スクロールするか、またはキーワードを Filter by keyword box に入力し (この場合は jaeger)、必要な Operator を見つけてこれをクリックします。
     2. Uninstall をクリックします。

   • Catalog → Operator Management ページから:

     1. Project 一覧から Operator がインストールされている namespace を選択します。クラスター全体の Operator の場合、デフォルトは openshift-operators です。

     2. Operator Subscriptions タブから、削除する必要のある Operator を見つけ (この例では jaeger)、 Options メニュー

        
     3. Remove Subscription をクリックします。
2. Remove Subscription 画面でプロンプトが出されたら、インストールに関連するすべてのコンポーネントを削除する必要がある場合には、Also completely remove the jaeger Operator from the selected namespace チェックボックスをオプションで選択します。これにより CSV が削除され、次に Operator に関連付けられた Pod、Deployment、CRD および CR が削除されます。
3. Remove を選択します。この Operator は実行を停止し、更新を受信しなくなります。

1. サブスクライブされた Operator (例: jaeger) の現行バージョンを currentCSV フィールドで確認します。

   $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV
     currentCSV: jaeger-operator.v1.8.2

2. Operator の Subscription (例: jaeger) を削除します。

   $ oc delete subscription jaeger -n openshift-operators
   subscription.operators.coreos.com "jaeger" deleted

3. 直前の手順で currentCSV 値を使用し、ターゲット namespace の Operator の CSV を削除します。

   $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators
   clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

4. CatalogSourceConfig リソースの内容を表示し、spec セクションでパッケージの一覧を確認します。

   $ oc get catalogsourceconfig -n openshift-marketplace \
       installed-community-openshift-operators -o yaml

   たとえば、spec セクションは以下のように表示されるかもしれません。

   CatalogSourceConfig のサンプル

   spec:
     csDisplayName: Community Operators
     csPublisher: Community
     packages: jaeger,descheduler
     targetNamespace: openshift-operators

5. 以下の 2 つの方法のいずれかで Operator を CatalogSourceConfig から削除します。

   • 複数の Operator がある場合、CatalogSourceConfig リソースを編集し、Operator のパッケージを削除します。

     $ oc edit catalogsourceconfig -n openshift-marketplace \
         installed-community-openshift-operators

     以下のようにパッケージを packages 行から削除します。

     CatalogSourceConfig で変更されたパッケージの例

       packages: descheduler

     変更を保存すると、marketplace-operator が CatalogSourceConfig を調整します。

   • CatalogSourceConfig に 1 つの Operator のみがある場合、以下のように CatalogSourceConfig 全体を削除してこれを削除することができます。

     $ oc delete catalogsourceconfig -n openshift-marketplace \
         installed-community-openshift-operators

手順

1. この手順を実行するために OpenShift Container Platform Web コンソールで新規プロジェクトを作成します。この例では、my-etcd というプロジェクトを使用します。

2. Catalogs → Installed Operators ページに移動します。クラスター管理者によってクラスターにインストールされ、使用可能にされた Operator が ClusterServiceVersion (CSV) の一覧としてここに表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。

   ヒント

   以下を使用して、CLI でこの一覧を取得できます。

   $ oc get csv

3. Installed Operators ページで、Copied をクリックしてから、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。

   図2.6 etcd Operator の概要

   

   Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (EtcdCluster リソース) のタイプが含まれます。これらのオブジェクトは、 Deployments または ReplicaSets などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。

4. 新規 etcd クラスターを作成します。

   1. etcd Cluster API ボックスで、Create New をクリックします。
   2. 次の画面では、クラスターのサイズなど EtcdCluster オブジェクトのテンプレートを起動する最小条件への変更を加えることができます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。

5. Resources タブをクリックして、プロジェクトに Operator によって自動的に作成され、設定された数多くのリソースが含まれることを確認します。

   図2.7 etcd Operator リソース

   

   Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。

6. 所定プロジェクトで edit ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。

   $ oc policy add-role-to-user edit <user> -n <target_project>

手順

1. CR の YAML ファイルを作成します。以下の定義例では、cronSpec と image のカスタムフィールドがKind: CronTab のCR に設定されます。この Kind は、CRD オブジェクトの spec.kind フィールドから取得します。

   CR の YAML ファイルサンプル

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

   2

   CRD にタイプを指定します。

   3

   オブジェクトの名前を指定します。

   4

   オブジェクトのファイナライザーを指定します (ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

   5

   オブジェクトのタイプに固有の条件を指定します。

2. ファイルの作成後に、オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の特定の Kind についての情報を取得するには、以下を実行します。

   $ oc get <kind>

   例:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。例:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. CR の未加工の YAML データを確認することもできます。

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。

手順

1. サービスカタログ API サーバーを有効にします。

   1. 以下のコマンドを使用して、サービスカタログ API サーバーリソースを編集します。

      $ oc edit servicecatalogapiservers

   2. spec の下で、managementState フィールドを Managed に設定します。

      spec:
        logLevel: Normal
        managementState: Managed

   3. 変更を適用するためにファイルを保存します。

      Operator はサービスカタログ API サーバーコンポーネントをインストールします。OpenShift Container Platform 4 の時点では、このコンポーネントは openshift-service-catalog-apiserver namespace にインストールされます。

2. サービスカタログコントローラーマネージャーを有効にします。

   1. 以下のコマンドを使用して、サービスカタログコントローラーマネージャーのリソースを編集します。

      $ oc edit servicecatalogcontrollermanagers

   2. spec の下で、managementState フィールドを Managed に設定します。

      spec:
        logLevel: Normal
        managementState: Managed

   3. 変更を適用するためにファイルを保存します。

      Operator はサービスカタログコントローラーマネージャーをインストールします。OpenShift Container Platform 4 の時点で、このコンポーネントは openshift-service-catalog-controller-manager namespace にインストールされます。

手順

1. サービスカタログ API サーバーを無効にします。

   1. 以下のコマンドを使用して、サービスカタログ API サーバーリソースを編集します。

      $ oc edit servicecatalogapiservers

   2. spec の下で、managementState フィールドを Removed に設定します。

      spec:
        logLevel: Normal
        managementState: Removed

   3. 変更を適用するためにファイルを保存します。

2. サービスカタログコントローラーマネージャーを無効にします。

   1. 以下のコマンドを使用して、サービスカタログコントローラーマネージャーのリソースを編集します。

      $ oc edit servicecatalogcontrollermanagers

   2. spec の下で、managementState フィールドを Removed に設定します。

      spec:
        logLevel: Normal
        managementState: Removed

   3. 変更を適用するためにファイルを保存します。

1. namespace を作成します。

   1. Web コンソールで Administration → Namespaces に移動し、Create Namespace をクリックします。

   2. Name フィールドに openshift-template-service-broker を入力し、Create をクリックします。

      注記

      namespace は openshift- で開始する必要があります。

2. Catalog → OperatorHub ページに移動します。openshift-template-service-broker プロジェクトが選択されていることを確認します。
3. Template Service Broker Operator を選択します。
4. Operator についての情報を確認してから、Install をクリックします。
5. デフォルトの選択を確認し、Subscribe をクリックします。

手順

1. Web コンソールで Catalog → Installed Operators に移動し、openshift-template-service-broker プロジェクトを選択します。
2. Template Service Broker Operator を選択します。
3. Provided APIs で、Template Service Broker について Create New をクリックします。
4. デフォルトの YAML を確認し、Create をクリックします。

5. テンプレートサービスブローカーが起動していることを確認します。

   テンプレートサービスブローカーの起動後に、Catalog → Developer Catalog に移動し、Service Class チェックボックスを選択して利用可能なテンプレートアプリケーションを表示できます。テンプレートサービスブローカーが起動し、テンプレートアプリケーションが利用可能になるまで数分の時間がかかる場合があります。

   これらのサービスクラスが表示されない場合は、以下の項目のステータスを確認できます。

   • テンプレートサービスブローカー Pod のステータス

     • openshift-template-service-broker プロジェクトの Workloads → Pods ページから、apiserver- で起動する Pod のステータスが Running であり、Ready の準備状態であることを確認します。

   • クラスターサービスブローカーのステータス

     • Catalog → Broker Management → Service Brokers ページから、template-service-broker サービスブローカーのステータスが Ready であることを確認します。

   • サービスカタログコントローラーマネージャー Pod のログ

     • openshift-service-catalog-controller-manager プロジェクトの Workloads → Pods ページから、それぞれの Pod のログを確認し、Successfully fetched catalog entries from broker のメッセージと共にログエントリーが表示されていることを確認します。

手順

1. プロジェクトを作成します。

   1. Web コンソールで、Home → Projects に移動し、Create Project をクリックします。
   2. test-postgresql を Name フィールドに入力し、Create をクリックします。

2. サービスインスタンスを作成します。

   1. Catalog → Developer Catalog ページに移動します。
   2. PostgreSQL (Ephemeral) テンプレートアプリケーションを選択し、Create Service Instance をクリックします。
   3. デフォルトの選択を確認し、それ以外の必要なフィールドを設定してから Create をクリックします。

   4. Catalog → Provisioned Services に移動し、postgresql-ephemeral サービスインスタンスが作成され、ステータスが Ready であることを確認します。

      Home → Events ページで進捗を確認できます。しばらくすると、postgresql-ephemeral のイベントが「The instance was provisioned successfully」というメッセージと共に表示されるはずです。

3. サービスバインディングを作成します。

   1. Provisioned Services ページから、postgresql-ephemeral をクリックし、Create Service Binding をクリックします。

   2. デフォルトのサービスバインディング名を確認し、Create をクリックします。

      これにより、指定された名前を使用してバインディングの新規シークレットが作成されます。

4. 作成されたシークレットを確認します。

   1. Workloads → Secrets に移動し、postgresql-ephemeral という名前のシークレットが作成されていることを確認します。
   2. postgresql-ephemeral をクリックし、他のアプリへのバインディングに使用されるキーと値のペアを Data セクションで確認します。

1. テンプレートサービスブローカーのアンインストール

   1. Catalog → Installed Operators に移動し、ドロップダウンメニューから openshift-template-service-broker プロジェクトを選択します。
   2. Template Service Broker Operator をクリックします。
   3. Template Service Broker タブを選択します。
   4. template-service-broker をクリックします。
   5. Actions ドロップダウンメニューから、Delete Template Service Broker を選択します。

   6. 確認ポップアップ画面から Delete をクリックします。

      テンプレートサービスブローカーのアンインストールが終了し、テンプレートアプリケーションは Developer Catalog からすぐに削除されます。

2. テンプレートサービスブローカー Operator のアンインストール

   1. Catalog → Operator Management に移動し、ドロップダウンメニューから openshift-template-service-broker プロジェクトを選択します。
   2. Template Service Broker Operator の View subscription をクリックします。
   3. templateservicebroker を選択します。
   4. Actions ドロップダウンメニューから、Remove Subscription を選択します。

   5. Also completely remove the templateservicebroker Operator from the selected namespace の横にあるチェックボックスにチェックが付けられていることを確認し、Remove をクリックします。

      テンプレートサービスブローカー Operator がクラスターにインストールされていない状態になります。

1. ユーザーは、OpenShift Container Platform Web コンソールを使用してサービスカタログから利用可能なアプリケーションの一覧を要求します。
2. サービスカタログは、OpenShift Ansible Broker から利用可能なアプリケーションの一覧を要求します。
3. OpenShift Ansible Broker は定義されたコンテナーイメージレジストリーと通信し、利用可能な APB の情報を得ます。
4. ユーザーは特定の APB をプロビジョニングする要求を実行します。
5. OpenShift Ansible Broker は、APB でプロビジョニングメソッドを呼び出して、ユーザーのプロビジョニング要求に対応します。

1. namespace を作成します。

   1. Web コンソールで Administration → Namespaces に移動し、Create Namespace をクリックします。

   2. openshift-ansible-service-broker を Name フィールドに、openshift.io/cluster-monitoring=true を Labels フィールドに入力し、Create をクリックします。

      注記

      namespace は openshift- で開始する必要があります。

2. クラスターのロールバインディングを作成します。

   1. Administration → Role Bindings に移動し、Create Binding をクリックします。
   2. Binding Type については、Cluster-wide Role Binding (ClusterRoleBinding) を選択します。
   3. Role Binding については、ansible-service-broker を Name フィールドに入力します。
   4. Role については、admin を選択します。
   5. Subject については、Service Account オプションを選択し、openshift-ansible-service-broker namespace を選択して openshift-ansible-service-broker-operator を Subject Name フィールドに入力します。
   6. Create をクリックします。

3. Red Hat Container Catalog に接続するためにシークレットを作成します。

   1. Workloads → Secrets に移動します。openshift-ansible-service-broker プロジェクトが選択されていることを確認します。
   2. Create → Key/Value Secret をクリックします。
   3. asb-registry-auth を シークレット名 として入力します。
   4. usernameの Key および Red Hat Container Catalog ユーザー名の Value を追加します。
   5. Add Key/Value をクリックし、password の Key および Red Hat Container Catalog パスワードの Value を追加します。
   6. Create をクリックします。
4. Catalog → OperatorHub ページに移動します。openshift-ansible-service-broker プロジェクトが選択されていることを確認します。
5. OpenShift Ansible Service Broker Operator を選択します。
6. Operator についての情報を確認してから、Install をクリックします。
7. デフォルトの選択を確認し、Subscribe をクリックします。

手順

1. Web コンソールで Catalog → Installed Operators に移動し、openshift-ansible-service-broker プロジェクトを選択します。
2. OpenShift Ansible Service Broker Operator を選択します。
3. Provided APIs で、Automation Broker について Create New をクリックします。

4. 以下を、提供されているデフォルトの YAML の spec フィールドに追加します。

   registry:
     - name: rhcc
       type: rhcc
       url: https://registry.redhat.io
       auth_type: secret
       auth_name: asb-registry-auth

   これは、OpenShift Ansible Service Broker Operator のインストール時に作成されたシークレットを参照します。これにより、Red Hat Container Catalog に接続できます。

5. 追加の OpenShift Ansible Broker 設定オプションを設定し、Create をクリックします。

6. OpenShift Ansible Broker が起動したことを確認します。

   OpenShift Ansible Broker の起動後に、Catalog → Developer Catalog に移動し、Service Class チェックボックスを選択して利用可能なサービスバンドルを表示できます。OpenShift Ansible Broker が起動し、サービスバンドルが利用可能になるまで数分の時間がかかる場合があります。

   これらのサービスクラスが表示されない場合は、以下の項目のステータスを確認できます。

   • OpenShift Ansible Broker Pod のステータス

     • openshift-ansible-service-broker プロジェクトの Workloads → Pods ページから、asb- で起動する Pod のステータスが Running であり、Ready の準備状態であることを確認します。

   • クラスターサービスブローカーのステータス

     • Catalog → Broker Management → Service Brokers ページから、ansible-service-broker サービスブローカーのステータスが Ready であることを確認します。

   • サービスカタログコントローラーマネージャー Pod のログ

     • openshift-service-catalog-controller-manager プロジェクトの Workloads → Pods ページから、それぞれの Pod のログを確認し、Successfully fetched catalog entries from broker のメッセージと共にログエントリーが表示されていることを確認します。

1. Web コンソールで Catalog → Installed Operators に移動し、ansible-service-broker プロジェクトを選択します。
2. OpenShift Ansible Service Broker Operator を選択します。
3. Automation Broker タブで、ansible-service-broker を選択します。

4. YAML タブの spec フィールドの下で OpenShift Ansible Broker 設定オプションを追加するか、または更新します。

   以下は例になります。

   spec:
     keepNamespace: true
     sandboxRole: edit

5. Save をクリックして変更を適用します。

手順

1. ロールを作成します。

   1. Administration → Roles に移動し、Create Role をクリックします。

   2. エディターで YAML を以下に置き換えます。

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: prometheus-k8s
        namespace: openshift-ansible-service-broker
      rules:
      - apiGroups:
        - ""
        resources:
        - services
        - endpoints
        - pods
        verbs:
        - get
        - list
        - watch

   3. Create をクリックします。

2. ロールバインディングを作成します。

   1. Administration → Role Bindings に移動し、Create Binding をクリックします。
   2. Binding Type について、Namespace Role Binding (RoleBinding) を選択します。
   3. Role Binding について、prometheus-k8s を Name フィールドに、openshift-ansible-service-broker を Namespace フィールドに入力します。
   4. Role について、prometheus-k8s を選択します。
   5. Subject について、Service Account オプションを選択し、openshift-monitoring namespace を選択してから prometheus-k8s を Subject Name フィールドに入力します。
   6. Create をクリックします。

手順

1. プロジェクトを作成します。

   1. Web コンソールで、Home → Projects に移動し、Create Project をクリックします。
   2. test-postgresql-apb を Name フィールドに入力し、Create をクリックします。

2. サービスインスタンスを作成します。

   1. Catalog → Developer Catalog ページに移動します。
   2. PostgreSQL (APB) サービスバンドルを選択し、Create Service Instance をクリックします。
   3. デフォルトの選択を確認し、それ以外の必要なフィールドを設定してから Create をクリックします。

   4. Catalog → Provisioned Services に移動し、dh-postgresql-apb サービスインスタンスが作成され、ステータスが Ready であることを確認します。

      Home → Events ページで進捗を確認できます。しばらくすると、dh-postgresql-apb のイベントが「The instance was provisioned successfully」というメッセージと共に表示されるはずです。

3. サービスバインディングを作成します。

   1. Provisioned Services ページから、dh-postgresql-apb をクリックし、Create Service Binding をクリックします。

   2. デフォルトのサービスバインディング名を確認し、Create をクリックします。

      これにより、指定された名前を使用してバインディングの新規シークレットが作成されます。

4. 作成されたシークレットを確認します。

   1. Workloads → Secrets に移動し、dh-postgresql-apb という名前のシークレットが作成されていることを確認します。
   2. dh-postgresql-apb をクリックし、他のアプリへのバインディングに使用されるキーと値のペアを Data セクションで確認します。

1. OpenShift Ansible Broker をアンインストールします。

   1. Catalog → Installed Operators に移動し、ドロップダウンメニューから openshift-ansible-service-broker プロジェクトを選択します。
   2. OpenShift Ansible Service Broker Operator をクリックします。
   3. Automation Broker タブを選択します。
   4. ansible-service-broker をクリックします。
   5. Actions ドロップダウンメニューから、Delete Automation Broker を選択します。

   6. 確認ポップアップ画面から Delete をクリックします。

      OpenShift Ansible Broker のアンインストールが終了し、サービスバンドルは Developer Catalog からすぐに削除されます。

2. OpenShift Ansible Service Broker Operator のアンインストール

   1. Catalog → Operator Management に移動し、ドロップダウンメニューから openshift-ansible-service-broker プロジェクトを選択します。
   2. OpenShift Ansible Broker Operator の View subscription をクリックします。
   3. automationbroker を選択します。
   4. Actions ドロップダウンメニューから、Remove Subscription を選択します。

   5. Also completely remove the automationbroker Operator from the selected namespace の横にあるチェックボックスにチェックが付けられていることを確認し、Remove をクリックします。

      OpenShift Ansible Service Broker Operator がクラスターにインストールされていない状態になります。

1. ReplicationController 定義の要素。
2. 新規デプロイメントの自動作成のトリガー。
3. デプロイメント間の移行ストラテジー。
4. ライフサイクルフック。

1. pre ライフサイクルフックを実行します。
2. サージ数に基づいて新しい ReplicationController をスケールアップします。
3. 最大利用不可数に基づいて以前の ReplicationController をスケールダウンします。
4. 新しい ReplicationController が希望のレプリカ数に到達して、以前の ReplicationController の数がゼロになるまで、このスケーリングを繰り返します。
5. post ライフサイクルフックを実行します。

1. pre ライフサイクルフックを実行します。
2. 以前のデプロイメントをゼロにスケールダウンします。
3. 任意の mid ライフサイクルフックを実行します。
4. 新規デプロイメントをスケールアップします。
5. post ライフサイクルフックを実行します。

1. 以下の例のようなフィールドタイプを含む YAML ファイルを作成します。

   CRD の YAML ファイルサンプル

   apiVersion: apiextensions.k8s.io/v1beta1 1
   kind: CustomResourceDefinition
   metadata:
     name: crontabs.stable.example.com 2
   spec:
     group: stable.example.com 3
     version: v1 4
     scope: Namespaced 5
     names:
       plural: crontabs 6
       singular: crontab 7
       kind: CronTab 8
       shortNames:
       - ct 9

   1

   apiextensions.k8s.io/v1beta1 API を使用します。

   2

   定義の名前を指定します。これは group および plural フィールドの値を使用する <plural-name>.<group> 形式である必要があります。

   3

   API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、Job または ScheduledJob などのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.com など) である可能性があります。組織の完全修飾ドメイン名を使用することが奨励されます。

   4

   URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンで存在させることができます。たとえば、v1alpha、v1beta、v1 などが使用されます。

   5

   カスタムオブジェクトがクラスター (Cluster) の 1 つのプロジェクト (Namespaced) またはすべてのプロジェクトで利用可能であるかどうかを指定します。

   6

   URL で使用される複数形の名前を指定します。plural フィールドは API URL のリソースと同じになります。

   7

   CLI および表示用にエイリアスとして使用される単数形の名前を指定します。

   8

   作成できるオブジェクトの種類を指定します。タイプは CamelCase にすることができます。

   9

   CLI でリソースに一致する短い文字列を指定します。

   注記

   デフォルトで、CRD のスコープはクラスターで設定され、すべてのプロジェクトで利用可能です。

2. CRD オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

   新規の RESTful API エンドポイントは以下のように作成されます。

   /apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

   たとえば、サンプルファイルを使用すると、以下のエンドポイントが作成されます。

   /apis/stable.example.com/v1/namespaces/*/crontabs/...

   このエンドポイント URL を使用して CR を作成し、管理できます。オブジェクトの Kind は、作成した CRD オブジェクトの spec.kind フィールドに基づいています。

手順

1. CRD のクラスターロール定義ファイルを作成します。クラスターロール定義は、各クラスターロールに適用されるルールが含まれる YAML ファイルです。OpenShift Container Platform Controller はデフォルトクラスターロールに指定するルールを追加します。

   カスタムロール定義の YAML ファイルサンプル

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1 1
   metadata:
     name: aggregate-cron-tabs-admin-edit 2
     labels:
       rbac.authorization.k8s.io/aggregate-to-admin: "true" 3
       rbac.authorization.k8s.io/aggregate-to-edit: "true" 4
   rules:
   - apiGroups: ["stable.example.com"] 5
     resources: ["crontabs"] 6
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7
   ---
   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: aggregate-cron-tabs-view 8
     labels:
       # Add these permissions to the "view" default role.
       rbac.authorization.k8s.io/aggregate-to-view: "true" 9
       rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10
   rules:
   - apiGroups: ["stable.example.com"] 11
     resources: ["crontabs"] 12
     verbs: ["get", "list", "watch"] 13

   1

   rbac.authorization.k8s.io/v1 API を使用します。

   2 8

   定義の名前を指定します。

   3

   パーミッションを管理のデフォルトロールに付与するためにこのラベルを指定します。

   4

   パーミッションを編集のデフォルトロールに付与するためにこのラベルを指定します。

   5 11

   CRD のグループ名を指定します

   6 12

   これらのルールが適用される CRD の複数形の名前を指定します。

   7 13

   ロールに付与されるパーミッションを表す動詞を指定します。たとえば、読み取りおよび書き込みパーミッションを admin および edit ロールに適用し、読み取り専用パーミッションを view ロールに適用します。

   9

   このラベルを指定して、パーミッションを view デフォルトロールに付与します。

   10

   このラベルを指定して、パーミッションを cluster-reader デフォルトロールに付与します。

2. クラスターロールを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の YAML ファイルを作成します。以下の定義例では、cronSpec と image のカスタムフィールドがKind: CronTab のCR に設定されます。この Kind は、CRD オブジェクトの spec.kind フィールドから取得します。

   CR の YAML ファイルサンプル

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

   2

   CRD にタイプを指定します。

   3

   オブジェクトの名前を指定します。

   4

   オブジェクトのファイナライザーを指定します (ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

   5

   オブジェクトのタイプに固有の条件を指定します。

2. ファイルの作成後に、オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の特定の Kind についての情報を取得するには、以下を実行します。

   $ oc get <kind>

   例:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。例:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. CR の未加工の YAML データを確認することもできます。

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。

手順

1. CR の YAML ファイルを作成します。以下の定義例では、cronSpec と image のカスタムフィールドがKind: CronTab のCR に設定されます。この Kind は、CRD オブジェクトの spec.kind フィールドから取得します。

   CR の YAML ファイルサンプル

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

   2

   CRD にタイプを指定します。

   3

   オブジェクトの名前を指定します。

   4

   オブジェクトのファイナライザーを指定します (ある場合)。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

   5

   オブジェクトのタイプに固有の条件を指定します。

2. ファイルの作成後に、オブジェクトを作成します。

   $ oc create -f <file_name>.yaml

手順

1. CR の特定の Kind についての情報を取得するには、以下を実行します。

   $ oc get <kind>

   例:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。例:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. CR の未加工の YAML データを確認することもできます。

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。

手順

1. ファイルにクォータを定義します。

2. クォータを作成し、これをプロジェクトに適用するためにファイルを使用します。

   $ oc create -f <file> [-n <project_name>]

   例:

   $ oc create -f core-object-counts.yaml -n demoproject

手順

1. プロジェクトで定義されるクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

   $ oc get quota -n demoproject
   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. 関連するクォータについて記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

   $ oc describe quota core-object-counts -n demoproject
   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

1. Kubernetes コントローラーマネージャーを編集します。

   $ oc edit kubecontrollermanager cluster

2. unsupportedconfigOverrides フィールドを、以下の設定で、resource-quota-sync-period フィールドに時間 (秒単位) を指定するように変更します。

     unsupportedConfigOverrides:
       extendedArguments:
         resource-quota-sync-period:
         - 60s

手順

1. アノテーションに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   これにより、以下の ClusterResourceQuota オブジェクトが作成されます。

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   選択されたプロジェクトに対して実施される ResourceQuotaSpec オブジェクトです。

   2

   アノテーションの単純なキー/値のセレクターです。

   3

   プロジェクトを選択するために使用できるラベルセレクターです。

   4

   選択された各プロジェクトの現在のクォータの使用状況を記述する namespace ごとのマップです。

   5

   選択されたすべてのプロジェクトにおける使用量の総計です。

   この複数プロジェクトのクォータの記述は、デフォルトのプロジェクト要求エンドポイントを使用して <user_name> によって要求されるすべてのプロジェクトを制御します。ここでは、10 Pod および 20 シークレットに制限されます。

2. 同様にラベルに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $  oc create clusterresourcequota for-name \ 1
       --project-label-selector=name=frontend \ 2
       --hard=pods=10 --hard=secrets=20

   1

   clusterresourcequota および clusterquota は同じコマンドのエイリアスです。for-name は ClusterResourceQuota オブジェクトの名前です。

   2

   ラベル別にプロジェクトを選択するには、--project-label-selector=key=value 形式を使用してキーと値のペアを指定します。

   これにより、以下の ClusterResourceQuota オブジェクト定義が作成されます。

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

手順

1. プロジェクトに適用されているクォータを表示するには、以下を実行します。

   $ oc describe AppliedClusterResourceQuota

   例:

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20

手順

1. 単一のサービスをアイドリングするには、以下を実行します。

   $ oc idle <service>

手順

1. 複数サービスの一覧を含むファイルを作成します (それぞれを各行に指定)。

2. --resource-names-file オプションを使用してサービスをアイドリングします。

   $ oc idle --resource-names-file <filename>

手順

1. プルーニング操作によって削除されるものを確認するには、以下を実行します。

   1. 最高 3 つのタグリビジョンを保持し、6 分前よりも後に作成されたリソース (イメージ、イメージストリームおよび Pod) を保持します。

      $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

   2. 定義された制限を超えるすべてのイメージをプルーニングします。

      $ oc adm prune images --prune-over-size-limit

2. 前述のステップからオプションを指定してプルーニングの操作を実際に実行するには、以下を実行します。

   $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

   $ oc adm prune images --prune-over-size-limit --confirm

1. prune コマンドが --force-insecure オプションと共に実行される。
2. 指定される registry-url の前に http:// スキームが付けられる。
3. 指定される registry-url はローカルリンクアドレスまたは localhost である。
4. 現行ユーザーの設定が非セキュアな接続を許可する。これは、ユーザーが --insecure-skip-tls-verify を使用してログインするか、またはプロンプトが出される際に非セキュアな接続を選択することによって生じる可能性があります。

1. 推奨される解決法として、レジストリーのセキュリティーを保護することができます。そうしない場合は、--force-insecure をコマンドに追加して、クライアントに対して非セキュアな接続の使用を強制することができますが、これは推奨される方法ではありません。