5.4. S3 プロトコルを使用してレガシーアプリケーションデータをクラウドネイティブアプリケーションと共有する

多くのレガシーアプリケーションは、ファイルシステムを使用してデータセットを共有します。S3 操作を使用して、ファイルシステム内のレガシーデータにアクセスして共有できます。データを共有するには、次のことを行う必要があります。

  • 既存のファイルシステムデータセット、つまり Ceph FileSystem (CephFS) などの RWX ボリュームをエクスポートするか、S3 プロトコルを使用して新しいファイルシステムデータセットを作成します。
  • ファイルシステムと S3 プロトコルの両方からファイルシステムデータセットにアクセスします。
  • S3 アカウントを設定し、それらを既存または新規のファイルシステムの一意の識別子 (UID) とグループ識別子 (GID) にマップします。

5.4.1. ファイルシステムを使用するための NamespaceStore の作成

前提条件

  • OpenShift Data Foundation Operator を使用した OpenShift Container Platform のインストール
  • Multicloud Object Gateway (MCG) へのアクセス。

手順

  1. OpenShift Web コンソールにログインします。
  2. StorageData Foundation をクリックします。
  3. Namespace Store タブをクリックして、namespace バケットで使用される NamespaceStore リソースを作成します。
  4. Create namespaces をクリックします。
  5. NamespaceStore の名前を入力します。
  6. プロバイダーとしてファイルシステムを選択します。
  7. 永続ボリュームクレームを選択します。
  8. フォルダー名を入力します。

    フォルダー名が存在する場合は、そのフォルダーを使用して NamespaceStore を作成するか、その名前のフォルダーを作成します。

  9. Create をクリックします。
  10. namespacestore が Ready 状態にあることを確認します。

5.4.2. NamespaceStore ファイルシステム設定を使用したアカウントの作成

NamespaceStore ファイルシステム設定を使用して新しいアカウントを作成するか、YAML を編集して既存の通常のアカウントを NamespaceStore ファイルシステムアカウントに変換できます。

注記

NamespaceStore ファイルシステム設定をアカウントから削除することはできません。

前提条件

  • Multicloud Object Gateway (MCG) コマンドラインインターフェイスをダウンロードします。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg

手順

  • MCG コマンドラインインターフェイスを使用して、NamespaceStore ファイルシステム設定で新しいアカウントを作成します。

    $ noobaa account create <noobaa-account-name> [flags]

    以下に例を示します。

    $ noobaa account create testaccount --full_permission --nsfs_account_config --gid 10001 --uid 10001 –default_resource fs_namespacestore

    allow_bucket_create

    アカウントが新しいバケットの作成を許可されているかどうかを示します。サポートされている値は true または false です。デフォルト値は true です。

    allowed_buckets

    ユーザーがアクセス権と管理権を持つことを許可されているバケット名のコンマ区切りのリスト。

    default_resource

    S3 CreateBucket 操作を使用するときに新しいバケットが作成される NamespaceStore リソース。NamespaceStore は、RWX (ReadWriteMany) 永続ボリューム要求 (PVC) によってサポートされている必要があります。

    full_permission

    アカウントに完全な許可を許可するかどうかを示します。サポートされている値は true または false です。デフォルト値は false です。

    new_buckets_path

    新しいバケットに対応するディレクトリーが作成されるファイルシステムパス。パスは、NamespaceStore ファイルシステム PVC のファイルシステム内にあり、新しく作成されたオブジェクトバケットクラスのファイルシステムマッピングとして機能する新しいディレクトリーが作成されます。

    nsfs_account_config

    アカウントが NamespaceStore ファイルシステムに使用されているかどうかを示す必須フィールド。

    nsfs_only

    アカウントが NamespaceStore ファイルシステムにのみ使用されるかどうかを示します。サポートされている値は true または false です。デフォルト値は false です。true に設定すると、他のタイプのバケットへのアクセスが制限されます。

    uid

    MCG アカウントがマップされるファイルシステムのユーザー ID であり、ファイルシステム上のデータにアクセスして管理するために使用されます。

    gid

    MCG アカウントがマップされるファイルシステムのグループ ID であり、ファイルシステム上のデータにアクセスして管理するために使用されます。

    MCG システムは、アカウント設定とその S3 クレデンシャルを含む応答を送信します。

    # NooBaaAccount spec:
    allow_bucket_creation: true
    Allowed_buckets:
      full_permission: true
      permission_list: []
    default_resource: noobaa-default-namespace-store
    Nsfs_account_config:
      gid: 10001
      new_buckets_path: /
      nsfs_only: true
      uid: 10001
    INFO[0006] ✅ Exists: Secret "noobaa-account-testaccount"
    Connection info:
      AWS_ACCESS_KEY_ID      : <aws-access-key-id>
      AWS_SECRET_ACCESS_KEY  : <aws-secret-access-key>

    次のコマンドを使用して、すべてのカスタムリソース定義 (CRD) ベースのアカウントを一覧表示できます。

    $ noobaa account list
    NAME          ALLOWED_BUCKETS   DEFAULT_RESOURCE               PHASE   AGE
    testaccount   [*]               noobaa-default-backing-store   Ready   1m17s

    特定のアカウントに関心がある場合は、そのカスタムリソース定義 (CRD) をアカウント名で直接読み取ることができます。

    oc get noobaaaccount/testaccount -o yaml
    spec:
      allow_bucket_creation: true
      allowed_buckets:
        full_permission: true
        permission_list: []
      default_resource: noobaa-default-namespace-store
      nsfs_account_config:
        gid: 10001
        new_buckets_path: /
        nsfs_only: true
        uid: 10001

5.4.3. openshift-storage namespace からレガシーアプリケーションデータにアクセスする

Multicloud Object Gateway (MCG) NamespaceStore ファイルシステム (NSFS) 機能を使用する場合、データが openshift-storage namespace に存在する 永続ボリューム要求 (PVC) が必要です。ほとんどすべての場合、アクセスする必要のあるデータは、openshift-storage namespace ではなく、レガシーアプリケーションが使用する namespace にあります。

別の namespace に保存されているデータにアクセスするには、レガシーアプリケーションが使用するのと同じ CephFS ボリュームを指す PVC を openshift-storage namespace に作成する必要があります。

手順

  1. scc を使用してアプリケーションの namespace を表示します。

    $ oc get ns <application_namespace> -o yaml | grep scc
    <application_namespace>

    アプリケーションの namespace の名前を指定します。

    例5.1 例

    $ oc get ns testnamespace -o yaml | grep scc

    例5.2 出力例

    openshift.io/sa.scc.mcs: s0:c26,c5
    openshift.io/sa.scc.supplemental-groups: 1000660000/10000
    openshift.io/sa.scc.uid-range: 1000660000/10000
  2. アプリケーションの namespace に移動します。

    $ oc project <application_namespace>

    例5.3 例

    $ oc project testnamespace
  3. MCG NSFS 機能を使用して、noobaa S3 エンドポイントから消費する Pod に ReadWriteMany (RWX) PVC がマウントされていることを確認します。

    $ oc get pvc

    例5.4 出力例

    NAME                                               STATUS VOLUME
    CAPACITY ACCESS MODES STORAGECLASS              AGE
    cephfs-write-workload-generator-no-cache-pv-claim  Bound  pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
    10Gi     RWX          ocs-storagecluster-cephfs 12s
    $ oc get pod

    例5.5 出力例

    NAME                                                READY   STATUS              RESTARTS   AGE
    cephfs-write-workload-generator-no-cache-1-cv892    1/1     Running             0          11s
  4. Pod 内の永続ボリューム (PV) のマウントポイントを確認します。

    1. Pod から PV のボリューム名を取得します。

      $ oc get pods <pod_name> -o jsonpath='{.spec.volumes[]}'
      <pod_name>

      pod の名前を指定します。

      例5.6 例

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.volumes[]}'

      例5.7 出力例

      {"name":"app-persistent-storage","persistentVolumeClaim":{"claimName":"cephfs-write-workload-generator-no-cache-pv-claim"}}

      この例では、PVC のボリュームの名前は cephfs-write-workload-generator-no-cache-pv-claim です。

    2. Pod 内のすべてのマウントを一覧表示し、前の手順で特定したボリュームのマウントポイントを確認します。

      $ oc get pods <pod_name> -o jsonpath='{.spec.containers[].volumeMounts}'

      例5.8 例

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.containers[].volumeMounts}'

      例5.9 出力例

      [{"mountPath":"/mnt/pv","name":"app-persistent-storage"},{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-8tnc5","readOnly":true}]
  5. Pod 内の RWX PV のマウントポイントを確認します。

    $ oc exec -it <pod_name> -- df <mount_path>
    <mount_path>

    前の手順で特定したマウントポイントへのパスを指定します。

    例5.10 例

    $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- df /mnt/pv

    例5.11 出力例

    main
    Filesystem
    1K-blocks Used Available  Use%  Mounted on
    172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
    10485760  0    10485760   0%    /mnt/pv
  6. UID および SELinux ラベルが、レガシー namespace が使用するものと同じであることを確認してください。

    $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

    例5.12 例

    $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

    例5.13 出力例

    total 567
    drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
    -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
    drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..
  7. openshift-storage namespace からアクセス可能にするレガシーアプリケーション RWX PV の情報を取得します。

    $ oc get pv | grep <pv_name>
    <pv_name>

    PV の名前を指定します。

    例5.14 例

    $ oc get pv | grep pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a

    例5.15 出力例

    pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a   10Gi       RWX            Delete           Bound    testnamespace/cephfs-write-workload-generator-no-cache-pv-claim   ocs-storagecluster-cephfs              47s
  8. 1 つ以上の noobaa-endpoint Pod が PVC にアクセスできるように、レガシーアプリケーションの PVC が openshift-storage namespace からアクセス可能であることを確認します。

    1. volumeAttributes から subvolumePathvolumeHandle の値を検索します。これらの値は、レガシーアプリケーション PV の YAML 記述から取得できます。

      $ oc get pv <pv_name> -o yaml

      例5.16 例

      $ oc get pv pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a -o yaml

      例5.17 出力例

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        annotations:
          pv.kubernetes.io/provisioned-by: openshift-storage.cephfs.csi.ceph.com
        creationTimestamp: "2022-05-25T06:27:49Z"
        finalizers:
        - kubernetes.io/pv-protection
        name: pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
        resourceVersion: "177458"
        uid: 683fa87b-5192-4ccf-af2f-68c6bcf8f500
      spec:
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi
        claimRef:
          apiVersion: v1
          kind: PersistentVolumeClaim
          name: cephfs-write-workload-generator-no-cache-pv-claim
          namespace: testnamespace
          resourceVersion: "177453"
          uid: aa58fb91-c3d2-475b-bbee-68452a613e1a
        csi:
          controllerExpandSecretRef:
            name: rook-csi-cephfs-provisioner
            namespace: openshift-storage
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
            clusterID: openshift-storage
            fsName: ocs-storagecluster-cephfilesystem
            storage.kubernetes.io/csiProvisionerIdentity: 1653458225664-8081-openshift-storage.cephfs.csi.ceph.com
            subvolumeName: csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213
            subvolumePath: /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213
        persistentVolumeReclaimPolicy: Delete
        storageClassName: ocs-storagecluster-cephfs
        volumeMode: Filesystem
      status:
        phase: Bound
    2. 前のステップで特定した subvolumePathvolumeHandle の値を使用して、レガシーアプリケーション PV と同じ CephFS ボリュームを指す openshift-storage namespace に新しい PV および PVC オブジェクトを作成します。

      例5.18 サンプル YAML ファイル

      $ cat << EOF >> pv-openshift-storage.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: cephfs-pv-legacy-openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi     1
        csi:
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
          # Volume Attributes can be copied from the Source testnamespace PV
            "clusterID": "openshift-storage"
            "fsName": "ocs-storagecluster-cephfilesystem"
            "staticVolume": "true"
          # rootpath is the subvolumePath: you copied from the Source testnamespace PV
            "rootPath": /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213-clone   2
        persistentVolumeReclaimPolicy: Retain
        volumeMode: Filesystem
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: cephfs-pvc-legacy
        namespace: openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 10Gi     3
        volumeMode: Filesystem
        # volumeName should be same as PV name
        volumeName: cephfs-pv-legacy-openshift-storage
      EOF
      1
      openshift-storage namespace で作成する PV のストレージ容量は、元の PV と同じである必要があります。
      2
      openshift-storage で作成するターゲット PV のボリュームハンドルには、元のアプリケーション PV とは異なるハンドルが必要です。たとえば、ボリュームハンドルの末尾に -clone を追加します。
      3
      openshift-storage namespace で作成する PVC のストレージ容量は、元の PVC と同じである必要があります。
    3. 前のステップで指定した YAML ファイルを使用して、openshift-storage namespace に PV と PVC を作成します。

      $ oc create -f <YAML_file>
      <YAML_file>

      YAML ファイルの名前を指定します。

      例5.19 例

      $ oc create -f pv-openshift-storage.yaml

      例5.20 出力例

      persistentvolume/cephfs-pv-legacy-openshift-storage created
      persistentvolumeclaim/cephfs-pvc-legacy created
    4. PVC が openshift-storage namespace で使用可能であることを確認します。

      $ oc get pvc -n openshift-storage

      例5.21 出力例

      NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      cephfs-pvc-legacy                     Bound    cephfs-pv-legacy-openshift-storage         10Gi       RWX                                          14s
    5. openshift-storage プロジェクトに移動します。

      $ oc project openshift-storage

      例5.22 出力例

      Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".
    6. NSFS namespace ストアを作成します。

      $ noobaa namespacestore create nsfs <nsfs_namespacestore> --pvc-name='<cephfs_pvc_name>' --fs-backend='CEPH_FS'
      <nsfs_namespacestore>
      NSFS namespace ストアの名前を指定します。
      <cephfs_pvc_name>

      openshift-storage namespace で CephFSPVC の名前を指定します。

      例5.23 例

      $ noobaa namespacestore create nsfs legacy-namespace --pvc-name='cephfs-pvc-legacy' --fs-backend='CEPH_FS'
    7. noobaa-endpointPod が再起動し、NSFS namespace ストア (/nsfs/legacy-namespace mountpoint など) に PVC が正常にマウントされていることを確認します。

      $ oc exec -it <noobaa_endpoint_pod_name> -- df -h /nsfs/<nsfs_namespacestore>
      <noobaa_endpoint_pod_name>

      noobaa エンドポイント Pod の名前を指定します。

      例5.24 例

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -- df -h /nsfs/legacy-namespace

      例5.25 出力例

      Filesystem                                                                                                                                                Size  Used Avail Use% Mounted on
      172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c   10G     0   10G   0% /nsfs/legacy-namespace
    8. MCG ユーザーアカウントを作成します。

      $ noobaa account create <user_account> --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid <gid_number> --uid <uid_number> --default_resource='legacy-namespace'
      <user_account>
      MCG ユーザーアカウントの名前を指定します。
      <gid_number>
      GID 番号を指定します。
      <uid_number>

      UID 番号を指定します。

      例5.26 例

      重要

      レガシーアプリケーションと同じ UIDGID を使用します。前の出力から見つけることができます。

      $ noobaa account create leguser --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid 0 --uid 1000660000 --default_resource='legacy-namespace'
    9. MCG バケットを作成します。

      1. レガシーアプリケーション Pod の CephFS PV および PVC の NSFS 共有内に S3 専用のフォルダーを作成します。

        $ oc exec -it <pod_name> -- mkdir <mount_path>/nsfs

        例5.27 例

        $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- mkdir /mnt/pv/nsfs
      2. nsfs/ パスを使用して MCG バケットを作成します。

        $ noobaa api bucket_api create_bucket '{
          "name": "<bucket_name>",
          "namespace":{
            "write_resource": { "resource": "<nsfs_namespacestore>", "path": "nsfs/" },
            "read_resources": [ { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }]
          }
        }'

        例5.28 例

        $ noobaa api bucket_api create_bucket '{
          "name": "legacy-bucket",
          "namespace":{
            "write_resource": { "resource": "legacy-namespace", "path": "nsfs/" },
            "read_resources": [ { "resource": "legacy-namespace", "path": "nsfs/" }]
          }
        }'
    10. レガシーアプリケーションおよび openshift-storage namespace の PVC にあるフォルダーの SELinux ラベルを確認します。

      $ oc exec -it <noobaa_endpoint_pod_name> -n openshift-storage -- ls -ltraZ /nsfs/<nsfs_namespacstore>

      例5.29 例

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -n openshift-storage -- ls -ltraZ /nsfs/legacy-namespace

      例5.30 出力例

      total 567
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26      2 May 25 06:35 .
      -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c0,c26 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26     30 May 25 06:35 ..
      $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

      例5.31 例

      $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

      例5.32 出力例

      total 567
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
      -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

      これらの例では、SELinux ラベルが同じではないため、アクセス許可が拒否されたり、アクセスの問題が発生したりすることがわかります。

  9. レガシーアプリケーションと openshift-storage Pod がファイルで同じ SELinux ラベルを使用していることを確認します。

    これは、次の 2 つの方法のいずれかで実行できます。

  10. NSFS namespace ストアを削除します。

    1. MCG バケットを削除します。

      $ noobaa bucket delete <bucket_name>

      例5.33 例

      $ noobaa bucket delete legacy-bucket
    2. MCG ユーザーアカウントを削除します。

      $ noobaa account delete <user_account>

      例5.34 例

      $ noobaa account delete leguser
    3. NSFS namespace ストアを削除します。

      $ noobaa namespacestore delete <nsfs_namespacestore>

      例5.35 例

      $ noobaa namespacestore delete legacy-namespace
  11. PV と PVC を削除します。

    重要

    PV と PVC を削除する前に、PV に保持ポリシーが設定されていることを確認してください。

    $ oc delete pv <cephfs_pv_name>
    $ oc delete pvc <cephfs_pvc_name>
    <cephfs_pv_name>
    レガシーアプリケーションの CephFS PV 名を指定します。
    <cephfs_pvc_name>

    レガシーアプリケーションの CephFS PVC 名を指定します。

    例5.36 例

    $ oc delete pv cephfs-pv-legacy-openshift-storage
    $ oc delete pvc cephfs-pvc-legacy

5.4.3.1. レガシーアプリケーションプロジェクトのデフォルトの SELinux ラベルを、openshift-storage プロジェクトのラベルと一致するように変更します

  1. 現在の openshift-storage namespace を sa.scc.mcs で表示します。

    $ oc get ns openshift-storage -o yaml | grep sa.scc.mcs

    例5.37 出力例

    openshift.io/sa.scc.mcs: s0:c26,c0
  2. レガシーアプリケーションの namespace を編集し、openshift-storage namespace の sa.scc.mcs の値で sa.scc.mcs を変更します。

    $ oc edit ns <appplication_namespace>

    例5.38 例

    $ oc edit ns testnamespace
    $ oc get ns <application_namespace> -o yaml | grep sa.scc.mcs

    例5.39 例

    $ oc get ns testnamespace -o yaml | grep sa.scc.mcs

    例5.40 出力例

    openshift.io/sa.scc.mcs: s0:c26,c0
  3. レガシーアプリケーション Pod を再起動します。すべてのファイルの再ラベル付けが行われ、SELinux ラベルが openshift-storage デプロイメントと一致するようになりました。

5.4.3.2. レガシーアプリケーション PVC をマウントする Pod を持つデプロイメント設定に対してのみ SELinux ラベルを変更する

  1. MustRunAs および seLinuxOptions オプションを使用して、openshift-storage プロジェクトが使用するマルチカテゴリーセキュリティー (MCS) を使用して新しい scc を作成します。

    例5.41 サンプル YAML ファイル

    $ cat << EOF >> scc.yaml
    allowHostDirVolumePlugin: false
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: true
    allowPrivilegedContainer: false
    allowedCapabilities: null
    apiVersion: security.openshift.io/v1
    defaultAddCapabilities: null
    fsGroup:
      type: MustRunAs
    groups:
    - system:authenticated
    kind: SecurityContextConstraints
    metadata:
      annotations:
      name: restricted-pvselinux
    priority: null
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - KILL
    - MKNOD
    - SETUID
    - SETGID
    runAsUser:
      type: MustRunAsRange
    seLinuxContext:
      seLinuxOptions:
        level: s0:c26,c0
      type: MustRunAs
    supplementalGroups:
      type: RunAsAny
    users: []
    volumes:
    - configMap
    - downwardAPI
    - emptyDir
    - persistentVolumeClaim
    - projected
    - secret
    EOF
    $ oc create -f scc.yaml
  2. デプロイメント用のサービスアカウントを作成し、新しく作成した scc に追加します。

    1. サービスアカウントを作成します。

      $ oc create serviceaccount <service_account_name>
      <service_account_name>

      サービスアカウントの名前を指定します。

      例5.42 例

      $ oc create serviceaccount testnamespacesa
    2. 新しく作成した scc にサービスアカウントを追加します。

      $ oc adm policy add-scc-to-user restricted-pvselinux -z <service_account_name>

      例5.43 例

      $ oc adm policy add-scc-to-user restricted-pvselinux -z testnamespacesa
  3. 新しく作成されたサービスアカウントを使用するように、レガシーアプリケーションのデプロイメントにパッチを適用します。これで、デプロイメントで SELinux ラベルを指定できるようになりました。

    $ oc patch dc/<pod_name> '{"spec":{"template":{"spec":{"serviceAccountName": "<service_account_name>"}}}}'

    例5.44 例

    $ oc patch dc/cephfs-write-workload-generator-no-cache --patch '{"spec":{"template":{"spec":{"serviceAccountName": "testnamespacesa"}}}}'
  4. デプロイメントを編集して、デプロイメント設定の SELinux ラベルで使用するセキュリティーコンテキストを指定します。

    $ oc edit dc <pod_name> -n <application_namespace>

    以下の行を追加します。

    spec:
     template:
        metadata:
          securityContext:
            seLinuxOptions:
              Level: <security_context_value>
    <security_context_value>

    この値は、レガシーアプリケーション Pod の CephFS PV および PVC で、NSFS 共有内に S3 専用のフォルダーを作成するコマンドを実行するときに見つかります。

    例5.45 例

    $ oc edit dc cephfs-write-workload-generator-no-cache -n testnamespace
    spec:
     template:
        metadata:
          securityContext:
            seLinuxOptions:
              level: s0:c26,c0
  5. デプロイメント設定の SELinux ラベルで使用されるセキュリティーコンテキストが正しく指定されていることを確認してください。

    $ oc get dc <pod_name> -n <application_namespace> -o yaml | grep -A 2 securityContext

    例5.46 例

    $ oc get dc cephfs-write-workload-generator-no-cache -n testnamespace -o yaml | grep -A 2 securityContext

    例5.47 出力例

          securityContext:
            seLinuxOptions:
              level: s0:c26,c0

    レガシーアプリケーションが再起動され、openshift-storage namespace と同じ SELinux ラベルの使用が開始されます。