ホーム
製品
Red Hat OpenShift Data Foundation
4.10
ハイブリッドおよびマルチクラウドリソースの管理
5.4. S3 プロトコルを使用してレガシーアプリケーションデータをクラウドネイティブアプリケーションと共有する

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) へのアクセス。

手順

OpenShift Web コンソールにログインします。
Storage Data Foundation をクリックします。
Namespace Store タブをクリックして、namespace バケットで使用される NamespaceStore リソースを作成します。
Create namespaces をクリックします。
NamespaceStore の名前を入力します。
プロバイダーとしてファイルシステムを選択します。
永続ボリュームクレームを選択します。
フォルダー名を入力します。
フォルダー名が存在する場合は、そのフォルダーを使用して NamespaceStore を作成するか、その名前のフォルダーを作成します。
Create をクリックします。
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 に作成する必要があります。

手順

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

アプリケーションの namespace に移動します。
```
$ oc project <application_namespace>
```
例5.3 例
$ oc project testnamespace

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

Pod 内の永続ボリューム (PV) のマウントポイントを確認します。

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 です。

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}]

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

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 ..

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

1 つ以上の noobaa-endpoint Pod が PVC にアクセスできるように、レガシーアプリケーションの PVC が openshift-storage namespace からアクセス可能であることを確認します。

volumeAttributes から subvolumePath と volumeHandle の値を検索します。これらの値は、レガシーアプリケーション 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

前のステップで特定した subvolumePath と volumeHandle の値を使用して、レガシーアプリケーション 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


  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


  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cephfs-pvc-legacy
  namespace: openshift-storage
spec:
  storageClassName: ""
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi


  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 と同じである必要があります。

前のステップで指定した 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

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

openshift-storage プロジェクトに移動します。

$ oc project openshift-storage

例5.22 出力例

Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".

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'

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

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 例

重要

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

$ 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'

MCG バケットを作成します。

レガシーアプリケーション 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

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/" }]
  }
}'

レガシーアプリケーションおよび 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 ラベルが同じではないため、アクセス許可が拒否されたり、アクセスの問題が発生したりすることがわかります。

レガシーアプリケーションと openshift-storage Pod がファイルで同じ SELinux ラベルを使用していることを確認します。
これは、次の 2 つの方法のいずれかで実行できます。
- 「レガシーアプリケーションプロジェクトのデフォルトの SELinux ラベルを、openshift-storage プロジェクトのラベルと一致するように変更します」
- 「レガシーアプリケーション PVC をマウントする Pod を持つデプロイメント設定に対してのみ SELinux ラベルを変更する」

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

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

$ noobaa bucket delete <bucket_name>

例5.33 例

$ noobaa bucket delete legacy-bucket

MCG ユーザーアカウントを削除します。

$ noobaa account delete <user_account>

例5.34 例

$ noobaa account delete leguser

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

$ noobaa namespacestore delete <nsfs_namespacestore>

例5.35 例

$ noobaa namespacestore delete legacy-namespace

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 プロジェクトのラベルと一致するように変更します
リンクのコピー

現在の 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

レガシーアプリケーションの 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

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

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

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

デプロイメント用のサービスアカウントを作成し、新しく作成した 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
新しく作成されたサービスアカウントを使用するように、レガシーアプリケーションのデプロイメントにパッチを適用します。これで、デプロイメントで 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"}}}}'
デプロイメントを編集して、デプロイメント設定の 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
デプロイメント設定の 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 ラベルの使用が開始されます。

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

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

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

5.4.1. ファイルシステムを使用するための NamespaceStore の作成リンクのコピーリンクがクリップボードにコピーされました!

5.4.2. NamespaceStore ファイルシステム設定を使用したアカウントの作成リンクのコピーリンクがクリップボードにコピーされました!

5.4.3. openshift-storage namespace からレガシーアプリケーションデータにアクセスするリンクのコピーリンクがクリップボードにコピーされました!

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

5.4.3.2. レガシーアプリケーション PVC をマウントする Pod を持つデプロイメント設定に対してのみ SELinux ラベルを変更するリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.4.1. ファイルシステムを使用するための NamespaceStore の作成
リンクのコピー

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

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

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

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