コンテナイメージを扱うときにセキュリティ上の懸念や環境の構成などの理由でオンプレ上のプライベートレジストリを用意したいケースもあるかと思います。
その際、レジストリのストレージ領域としてオブジェクトストレージを利用したい場合があるかと思いますが、オンプレ環境で信頼性の高いオブジェクトストレージをどう用意するかというのはひとつの考慮事項かと思います。

NetAppストレージでは ONTAP ver 9.8以降でONTAP Simple Storage Service （ S3 ）オブジェクトストレージサーバ（ONTAP S3）を有効にすることができるようになっています。ファイル・ブロックストレージとして利用していた環境で、追加のハードウェア/ソフトウェアを用意することなくシンプルにオブジェクトストレージの利用を開始することができます。

今回、オンプレでよく利用されるKubernetesディストリビューションであるOpenShiftで標準で利用できるOpenShift Image Registryと組み合わせて、オンプレプライベートレジストリを構成してみたので、その手順を紹介したいと思います。

前提

以下の環境で試しています。

ONTAP 9.13.1P4
OpenShift 4.13

やってみること

ストレージにONTAP S3を構成して OpenShift Image Registry（以下OCR)の有効化しコンテナイメージのアップロードや利用ができることを確認してみる。

ONTAP S3でBucket/アクセスユーザを準備
OpenShift Image Registry（OCR)でONTAP S3をバックエンドオブジェクトストレージとして指定
OpenShift Image Registry（OCR)の有効化
動作確認(OCRを利用してみる)

なお、OpenShift Cluster環境は展開済みの前提としています。

1. ONTAP S3でバケット/アクセスユーザを準備

OCR から ONTAP S3を利用するために、 ONTAPでバケットとアクセス用ユーザ（アクセスキー・シークレットキー）を準備します。

ONTAP S3を構成しているONTAPクラスタにアクセスして作業を実施します。

なお、ONTAP S3の作業は System ManagerからWeb GUIの画面で実施でも可能ですが、今回はCLIで実施しています。作業に際しては、ONTAP S3用のSVM名はsvm48h、S3アクセス用のLIF名はlif_data_svm48h、作成するバケット名はs48bucketとして実施しています。

ONTAP S3を新規に構成する場合は、こちらの手順ではなく別記事でAnsibleを利用した構成手順を紹介していますのでそちらを参考にしてください。別記事の作業を実施した場合、ここで手動で作成しているバケット/ユーザ等はAnsibleで自動で作成されます。手動作成は不要になりますのでその場合は確認作業のみ実施してください。

1-1. LIF（IPアドレス）の確認

ONTAP S3用のLIF情報からS3 Dataアクセス用のIPアドレスを確認します。

soc-ontap2-01::> network interface show -vserver svm48h
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
svm48h
            lif_data_svm48h
                         up/up    10.128.211.49/24   soc-ontap2-01-01
                                                                   e0a     true
            lif_mgmt_svm48h
                         up/up    10.128.211.48/24   soc-ontap2-01-01
                                                                   e0a     true
2 entries were displayed.

soc-ontap2-01::>

今回 Dataアクセス用LIFはlif_data_svm48hなので、IPアドレスは10.128.211.49となります。

1-2. バケットの作成

OCRへアップロードされるイメージデータ等を配置するためのバケットを新規に作成します。

soc-ontap2-01::>  object-store-server bucket create -vserver svm48h -bucket s48bucket -type s3 -size 200G
  (vserver object-store-server bucket create)
[Job 2259] Job succeeded: Successful

soc-ontap2-01::> object-store-server bucket show　-bucket s48bucket
  (vserver object-store-server bucket show)
Vserver     Bucket          Type     Volume            Size       Encryption Role       NAS Path
----------- --------------- -------- ----------------- ---------- ---------- ---------- ----------
svm48h      s48bucket       s3       fg_oss_1706227514 200GB      false      standalone -

soc-ontap2-01::>

新規バケット s48bucket が作成されました。

1-3. アクセス用ユーザ作成

ONTAP S3へアクセスするためのユーザを作成し、アクセスキーとシークレットキーを確認します。あわせてアクセス許可ポリシーを作成してグループで関連付けします。

soc-ontap2-01::> object-store-server user create -vserver svm48h -user s48bucket_user1
  (vserver object-store-server user create)

soc-ontap2-01::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

soc-ontap2-01::*> object-store-server user show -vserver svm48h -user s48bucket_user1
  (vserver object-store-server user show)

                               Vserver Name: svm48h
              Object Store Server User Name: s48bucket_user1
                Object Store Server User ID: 4
       Object Store Server User Description:
Access Key for the Object Store Server User: ACCESSKEYXXXXXXXXXX
Secret Key for the Object Store Server User: SECRETKEYXXXXXXXXXXXXXXXXXXXXXX

soc-ontap2-01::*> set admin
soc-ontap2-01::> object-store-server policy create -vserver svm48h -policy s48bucket_policy
soc-ontap2-01::> object-store-server policy show -policy s48bucket_policy
  (vserver object-store-server policy show)
Vserver     Name               Is Read-Only Comment
----------- ------------------ ------------ ----------------
svm48h    s48bucket_policy   false

soc-ontap2-01::> object-store-server policy add-statement -vserver svm48h -policy s48bucket_policy -effect allow -actions * -resource s48bucket,s48bucket/*
  (vserver object-store-server policy add-statement)

soc-ontap2-01::> object-store-server policy show-statements -vserver svm48h -policy s48bucket_policy
  (vserver object-store-server policy show-statements)
Vserver   Policy       Index  Effect Actions          Resources
--------- ------------ ------ ------ ---------------- -----------------
svm48h
          s48bucket_policy  1 allow  *                s48bucket,
                                                      s48bucket/*

soc-ontap2-01::> object-store-server group create -vserver svm48h -name s48bucket_group -users s48bucket_user1 -policies s48bucket_policy
  (vserver object-store-server group create)

soc-ontap2-01::> object-store-server group show -name s48bucket_group
  (vserver object-store-server group show)
Vserver     Group ID  Group Name     Users            Policies
----------- --------- -------------- ---------------- -------------------
svm48h              1  s48bucket_group
                                     s48bucket_user1  s48bucket_policy

soc-ontap2-01::>

ONTAP S3アクセス用ユーザを作成しました。
アクセス許可の設定も実施したのでこのユーザに紐づくAccessKey、SecretKeyをつかってONTAP S3のバケットs48bucketへアクセスできます。

2. OpenShift Image Registry（OCR)でONTAP S3をバックエンドオブジェクトストレージとして指定

次に、ONTAP S3 を OCRへアップロードされるコンテナイメージを保存するバックエンドストレージとして利用するために、OCRのconfigへの設定追加と新規Secretの設定を実施します。

OpenShiftクラスタに接続できる環境から作業を実施します。

2-1. ONTAP S3 アクセス情報を設定

OCRのconfigにストレージとしてONTAP S3のバケット名とアクセス情報を設定します。
今回はIPアドレスをそのまま指定しています。

$ oc edit configs.imageregistry.operator.openshift.io/cluster
→ 以下のようにspec.storage部分を更新・追記
---
  storage:
    managementState: Unmanaged
    s3:
      bucket: s48bucket
      region: dummyregion
      regionEndpoint: http://10.128.211.49/
---

2-2. ONTAP S3のユーザ情報を設定

OCR の Namespace(openshift-image-registry) の Secret として、ONTAP S3へのアクセスユーザのAccessKeyとSecretKey情報を設定します。

$ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=ACCESSKEYXXXXXXXXXX --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=SECRETKEYXXXXXXXXXXXXXXXXXXXXXX --namespace openshift-image-registry

これで、OCRからONTAP S3へアクセスするための準備が整いました。

3. OpenShift Image Registry（OCR)の有効化

OCRを有効化するため Image Registry Operatorのconfigで StatusをManagedに更新します。

OpenShiftクラスタに接続できる環境から以下コマンドを実行してStatusをManagedに更新します。

$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
config.imageregistry.operator.openshift.io/cluster patched
$ oc get configs.imageregistry.operator.openshift.io -o yaml | grep managementState
     managementState: Managed

設定完了後、image-registryが起動することを確認します。

$ oc -n openshift-image-registry get pod
NAME                                               READY   STATUS      RESTARTS      AGE
cluster-image-registry-operator-7447c6f595-wm8n9   1/1     Running     2 (48d ago)   104d
image-pruner-28562400-zhmp5                        0/1     Completed   0             2d23h
image-pruner-28563840-mm2mc                        0/1     Completed   0             47h
image-pruner-28565280-wxcsh                        0/1     Completed   0             23h
image-registry-54774c8957-tbff8                    1/1     Running     0             58s
node-ca-5vf54                                      1/1     Running     0             104d
node-ca-9cp9h                                      1/1     Running     0             104d
node-ca-dzbjg                                      1/1     Running     1             104d
node-ca-fq4bt                                      1/1     Running     1             104d
node-ca-gg8zz                                      1/1     Running     0             90d
node-ca-lcjcw                                      1/1     Running     0             104d
node-ca-th24l                                      1/1     Running     1             104d
$ oc -n openshift-image-registry get deploy
NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
cluster-image-registry-operator   1/1     1            1           104d
image-registry                    1/1     1            1           58s
$

これで OCR によるレジストリサービスの提供が開始されました。
コンテナイメージのデータは OCR を経由して ONTAP S3 バケットに保存されアクセスされます。

4. 動作確認：

今回構成した OCR によるレジストリサービスを利用してみます。

4-1. コンテナイメージアップロード：

OpenshiftクラスタのWorker NodeからOCRにアクセスして、イメージをPushできることを確認してみます。

OpenShiftクラスタに接続できる環境から Worker Nodeにアクセスします。

$ oc get node
NAME                         STATUS   ROLES                  AGE    VERSION
ocp13-sfn95-master-0         Ready    control-plane,master   104d   v1.26.5+7a891f0
ocp13-sfn95-master-1         Ready    control-plane,master   104d   v1.26.5+7a891f0
ocp13-sfn95-master-2         Ready    control-plane,master   104d   v1.26.5+7a891f0
ocp13-sfn95-worker-0-ctxmj   Ready    worker                 104d   v1.26.5+7a891f0
ocp13-sfn95-worker-0-gm5s5   Ready    worker                 104d   v1.26.5+7a891f0
ocp13-sfn95-worker-0-nqwrs   Ready    worker                 104d   v1.26.5+7a891f0
ocp13-sfn95-worker-0-rhczr   Ready    worker                 90d    v1.26.5+7a891f0
$ oc debug node/ocp13-sfn95-worker-0-ctxmj
Temporary namespace openshift-debug-j86xt is created for debugging node...
Starting pod/ocp13-sfn95-worker-0-ctxmj-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.128.211.177
If you don't see a command prompt, try pressing enter.
sh-4.4#

Worker Node上から OCR にアクセスします。

OCR を OpenShiftクラスタから利用するためサーバ名"image-registry.openshift-image-registry.svc:5000"でアクセスします。

sh-4.4# chroot /host
sh-5.1# oc login -u kubeadmin -p XXXXXXXXXXXXXXXXXXX https://api-ocp13-green-lab:6443
WARNING: Using insecure TLS client config. Setting this option is not supported!

Login successful.

You have access to 75 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".
sh-5.1# 
sh-5.1# HOST=image-registry.openshift-image-registry.svc:5000
sh-5.1# 
sh-5.1# podman login -u kubeadmin -p $(oc whoami -t) $HOST
Login Succeeded!

OCRへコンテナイメージをアップロードしてみます。
今回は ubuntu のイメージを取得してタグ付けし、OCRへアップロードします。

sh-5.1# podman pull ubuntu
Resolved "ubuntu" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/ubuntu:latest...
Getting image source signatures
Copying blob 3c645031de29 done
Copying config 7af9ba4f0a done
Writing manifest to image destination
Storing signatures
7af9ba4f0a47d9bc8b1ffa492c6b0276476f1889cf4e699fba2236924e5932ed
sh-5.1# 
sh-5.1# podman tag ubuntu $HOST/ns01/ubuntu:latest
sh-5.1# 
sh-5.1# podman push $HOST/ns01/ubuntu:latest
Getting image source signatures
Copying blob e0a9f5911802 done
Copying config 7af9ba4f0a done
Writing manifest to image destination
Storing signatures
sh-5.1#

OCRへアップロードしたコンテナイメージを利用できるか確認してみます。
コンテナを起動してアクセスし、OS情報を確認してみます。

sh-5.1# podman run -it $HOST/ns01/ubuntu:latest
root@b9e207264947:/# 
root@b9e207264947:/# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
root@b9e207264947:/# exit
exit
sh-5.1# exit
exit
sh-4.4# exit
exit

Removing debug pod ...
Temporary namespace openshift-debug-j86xt was removed.
$

OCRへコンテナイメージをアップロード、またアップロードしたイメージを利用できることを確認しました。

4-2. Podのイメージとして利用

次に、4-1でアップロードしたイメージを利用するPodをOpenShiftクラスタにデプロイしてみます。

OpenShiftクラスタに接続できる環境から以下の作業を実施します。

$ cat <<EOF>> ns01pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: ubuntu01
  namespace: ns01
spec:
  containers:
  - image: image-registry.openshift-image-registry.svc:5000/ns01/ubuntu
    name: ubuntu01
    command:
    - "/bin/sh"
    - "-c"
    - "while true; do sleep 1; done"
EOF
$ oc apply -f ns01pod.yaml
Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "ubuntu01" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "ubuntu01" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "ubuntu01" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "ubuntu01" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/ubuntu01 created
$ oc -n ns01 get pod
NAME       READY   STATUS    RESTARTS   AGE
ubuntu01   1/1     Running   0          5s
$ oc -n ns01 exec -it ubuntu01 -- bash
root@ubuntu01:/#
root@ubuntu01:/# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
root@ubuntu01:/# exit
exit
$

OCRにあるイメージを利用して OpenShiftクラスタ　に　Pod　をデプロイできることを確認しました。

4-3. ONTAP S3のバケットを確認

アップロードしたコンテナイメージがONTAP S3 のバケット上に配置されていることを確認してみます。

今回はAWS CLIを利用し、プロファイル情報にONTAP S3アクセス用のAccessKey/SecretKeyを設定してバケット情報を確認してみます。

なお、AWS CLIのインストール手順などについては、AWSのサイトを参照ください。

$ aws configure --profile ontap_s48bucket_user1
AWS Access Key ID [None]: ACCESSKEYXXXXXXXXXX
AWS Secret Access Key [None]: SECRETKEYXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]:
Default output format [None]:
$ aws s3 ls s3://s48bucket --endpoint-url http://10.128.211.49/ --no-verify-ssl --profile ontap_s48bucket_user1 --recursive|grep ubuntu
2024-04-24 19:13:19         71 docker/registry/v2/repositories/ns01/ubuntu/_layers/sha256/2ce11891398c80721baec016ec69d1f7b0cb37fa31d906832199ddf787ef7603/link
2024-04-24 19:13:20         71 docker/registry/v2/repositories/ns01/ubuntu/_layers/sha256/7af9ba4f0a47d9bc8b1ffa492c6b0276476f1889cf4e699fba2236924e5932ed/link
2024-04-24 19:13:20         71 docker/registry/v2/repositories/ns01/ubuntu/_manifests/revisions/sha256/4d66089a2787cee74fdea03a67f93cd2500b9e4c1f3464abc127775a8850d7fc/link
$ aws s3 ls s3://s48bucket --endpoint-url http://10.128.211.49/ --no-verify-ssl --profile ontapselect_s48bucket_user1 --recursive|grep 2ce11891398c80721baec016ec69d1f7b0cb37fa31d906832199ddf787ef7603
2024-04-24 19:13:19   31524221 docker/registry/v2/blobs/sha256/2c/2ce11891398c80721baec016ec69d1f7b0cb37fa31d906832199ddf787ef7603/data
2024-04-24 19:13:19         71 docker/registry/v2/repositories/ns01/ubuntu/_layers/sha256/2ce11891398c80721baec016ec69d1f7b0cb37fa31d906832199ddf787ef7603/link
$ aws s3 ls s3://s48bucket --endpoint-url http://10.128.211.49/ --no-verify-ssl --profile ontapselect_s48bucket_user1 --recursive|grep 7af9ba4f0a47d9bc8b1ffa492c6b0276476f1889cf4e699fba2236924e5932ed
2024-04-24 19:13:20       2297 docker/registry/v2/blobs/sha256/7a/7af9ba4f0a47d9bc8b1ffa492c6b0276476f1889cf4e699fba2236924e5932ed/data
2024-04-24 19:13:20         71 docker/registry/v2/repositories/ns01/ubuntu/_layers/sha256/7af9ba4f0a47d9bc8b1ffa492c6b0276476f1889cf4e699fba2236924e5932ed/link
$ aws s3 ls s3://s48bucket --endpoint-url http://10.128.211.49/ --no-verify-ssl --profile ontapselect_s48bucket_user1 --recursive|grep 4d66089a2787cee74fdea03a67f93cd2500b9e4c1f3464abc127775a8850d7fc
2024-04-24 19:13:20        407 docker/registry/v2/blobs/sha256/4d/4d66089a2787cee74fdea03a67f93cd2500b9e4c1f3464abc127775a8850d7fc/data
2024-04-24 19:13:20         71 docker/registry/v2/repositories/ns01/ubuntu/_manifests/revisions/sha256/4d66089a2787cee74fdea03a67f93cd2500b9e4c1f3464abc127775a8850d7fc/link
[root@ansi-vm0m tmp]#

ONTAP S3のバケット上に4-1でアップロードしたubuntuコンテナイメージのデータが配置されていることを確認しました。

まとめ。

OpenShift Image Registry（OCR) ＋ ONTAP S3 でオンプレプライベートレジストリを構成し OpenShift クラスタからレジストリとして利用できることを確認してみました。

ONTAP S3を利用することで、ONTAPストレージがある環境であればオンプレでも手軽にオブジェクトストレージを用意してレジストリのデータ配置場所として利用できます。

今回はオブジェクトストレージを用意しましたが、代わりにストレージとしてファイル / ブロックを利用するためONTAP + Astra Tridentを利用することも可能です。NFSで利用する際に大量のコンテナイメージを扱う環境で利用する場合は"nfsMountOptions: "lookupcache=pos"を指定してnegative dentryをキャッシュしないようにしておくと良いかと思います。
また、エンタープライズ環境でサービスの冗長性を考慮した構成が必要な場合はRed Hat Quay + ONTAP S3での構成を選択するなども可能です。

こういった形で用途や環境等にあわせて柔軟にファイル/ブロック/オブジェクトストレージを適用できるのもNetAppストレージ ONTAPの利点だと思います。