fbpx

CL LAB

HOME > CL LAB > MSR(Mirantis Secure Registry) 2.9のコンテナイメージをMSR 3.0へマイグレーションしてみよう #msr #k8s #kubernetes #mirantis

MSR(Mirantis Secure Registry) 2.9のコンテナイメージをMSR 3.0へマイグレーションしてみよう #msr #k8s #kubernetes #mirantis

 ★ 25

Mirantis Secure Registry(MSR:旧 Docker Trusted Registry)は、エンタープライズ級のプライベートなレジストリで、コンテナイメージを安全に保管・共有・管理できるソリューションです。
コンテナイメージの保管だけでなく、アクセス制御やイメージスキャンを実施して脆弱性チェックをおこなえる機能がついています。イメージスキャンについてはこちらのブログで紹介しておりますのでご参照ください。
本稿ではMSR2.9をお使いのユーザがすぐにMSR3.0を使えるようになるためにリポジトリにあるコンテナイメージ、ユーザーやオーガニゼーションなどの情報をまとめてMSR3.0へマイグレーションする方法をご紹介します。

マイグレーションするメリットとは?

MSR2.9はKubernetesプラットフォームであるMKE(Mirantis Kubernetes Engine)のWorker上で動作するため、利用するにはMKEのインストールが必須となります。
一方、MSR3.0はKubernetes 1.20以降がインストールされていれば、MKEだけでなく他のKubernetesプラットフォーム上で動作することができ、Kubernetesディストリビューションに依存しない柔軟な環境でリポジトリ管理が可能になります。

動作環境

Source MSR(MSR2.9.9)
本稿ではマイグレーション元のMSRをSource MSRと呼びます。
MKE3.5.5のWorkerノード上にMSRをインストールしています。

Target MSR(MSR3.0.5)
マイグレーション先のMSRを本稿ではTarget MSRと呼びます。
Kubeadmを使いKubernetes v1.25.4をインストールしMSR3.0.5をインストールしています。

作業概要

マイグレーションにはMirantis社が用意しているMirantis Migration Tool(以下MMT)を使用します。Target MSRでのMMTはMSR3.0.3からサポートされており、それより前のMSRバージョンでは対応していません。
Source MSRとしてはMSR2.9をサポートしており、MSR2.8以前のバージョンでは未対応です。
なお、シングルサインオンの設定と自動スキャンタイムアウトの設定はマイグレーション対象外です。

全体の作業の流れです。


作業は全てCLIでおこないます。
事前準備、estimate、extractはSourceMSRでおこない、マイグレーションに必要な情報を収集します。それらの情報をTarget MSRへ移動したあとにtransform、restoreでMSR3.0に適した形式に変換しデータを格納します。最後に動作確認を実施して終了です。

事前準備

それでは作業に取り掛かっていきましょう。
作業には当然TargetとなるMSR3.0の構築が必要ですが、インストールについては過去に取り扱っているこちらのブログに記載されているので省略します。
作業をおこなうにはSource MSRを読み取り専用モードにすることが推奨されています。以下コマンドを実行します。
Source MSR:

$ curl -u $USER:$TOKEN -X POST "https://<msr-url>/api/v0/meta/settings" -H "accept: application/json" -H "content-type: application/json" -d "{ \"readOnlyRegistry\": true }" --insecure

<msr-url>にはSource MSRのURLを入力してください。
$USERにはSource MSRへWebUIでログインする際のadmin権限のアカウント、$TOKENはWebUIにてAccess TokensタブからNew access tokenで作成したトークンを環境変数に事前に格納しています。

コマンド実行時のログ抜粋

"readOnlyRegistry": true,
"disablePersistentCookies": false,
"globalEnforcementPolicy": {
"rules": {},
"enabled": false
}

"readOnlyRegistry": trueとなっていれば読み取り専用、つまりSource MSRリポジトリへPush不可(Pullは可能)の状態に更新されています。

estimate
Source MSRにてdtr-registryのVOLUME NAMEを確認します。

$ docker volume ls --filter name=dtr-registry
DRIVER VOLUME NAME
local dtr-registry-000000000001

estimateは以下のコマンドで実行します。
Source MSR:

$ docker run \
--rm \
-it \
-v <local-migration-directory>:/migration:Z \
--mount source=<dtr-registry-id>,target=/storage \
registry.mirantis.com/msr/mmt:$MMT_VERSION \
estimate msr  \
--source-mke-url <MKE url> \
--source-username <MKE admin username> \
--source-password <MKE admin password> \
--source-url <MSR 2.9 url> \
--storage-mode copy \
--source-insecure-tls \
/migration

コマンド内でstorage-modeパラメータを指定する必要があり、storage-modeはcopyとinplaceの2種類用意されています。
Target MSRとSource MSRでは別々にローカル上でデータを保管しているのでcopyを使用しています。共通の外部ストレージを使用している場合はinplaceを使用します。copyとinplaceの説明についてはこちらをご参照ください。

Source MSRのノードで任意のディレクトリを作成します。例として<local-migration-directory>には/home/ubuntu/temp/migrationを入力しています。このあとの手順でディレクトリ配下にマイグレーションに必要なファイルがコピーされます。
<dtr-registry-id>には始めに確認したVOLUME NAMEを入力してください。ここではdtr-registry-000000000001となります。
$MMT_VERSIONはMMTのバージョンを表すもので”latest”にしています。
<MKE url>にはhttps://172.31.5.196/、<MSR 2.9 url>にはhttps://172.31.11.170/をこちらの環境に併せて入力しています。<MKE admin username>、<MKE admin password>もそれぞれの環境に適した値をご入力ください。

実行時のログ抜粋

Source Registry: "https://172.31.11.170/" (Type: "msr")
with authentication data from MKE: "https://172.31.5.196/"
Mode: "copy"
Registry Metadata: 90 MB
Image tags: 6 (1.2 GB)

Existing MSR storage will be copied.

このようなログが出ればestimate完了です。特にエラーが無ければ次に進みましょう。

extract
estimateと同じく必要箇所に値を入れてSource MSRにてextractを実施します。
extractにより/home/ubuntu/temp/migrationにマイグレーションに必要な情報が格納されます。

extract実行コマンド
Source MSR:

docker run \
--rm \
-it \
-v <local-migration-directory>:/migration:Z \
--mount source=<dtr-registry-id>,target=/storage \
registry.mirantis.com/msr/mmt:$MMT_VERSION \
extract msr  \
--source-mke-url <MKE url> \
--source-username <MKE admin username> \
--source-password <MKE admin password> \
--source-url <MSR 2.9 url> \
--storage-mode copy \
--source-insecure-tls \
/migration

実行時のログ抜粋

Source Registry: https://172.31.11.170/
Mode: copy
Image data: 51 blobs (1.2 GB)

/home/ubuntu/temp/migrationにマイグレーション用のファイルがコピーされました。

$ ls -l /home/ubuntu/temp/migration
-rw------- 1 root root     6399 Dec 12 04:28 auth-store.tar.gz
drwxr-xr-x 3 root root     4096 Dec 12 04:28 blobs
-rw-r--r-- 1 root root 26028544 Dec 12 04:28 dtr-metadata-mmt-backup.tar
-rw------- 1 root root     5078 Dec 12 04:29 migration_summary.json
-rw------- 1 root root       77 Dec 12 04:29 stats.json

transform
ここからはTarget MSRでの作業に移ります。ドキュメントにあるテンプレートを参考にしてMMT用のPodやその他必要なKubernetesのオブジェクトを作成します。

下記は実際に使用したyamlファイルです。各リソースの名前を任意のものに変更し、コンテナイメージのタグはlatestとしています。
mmt-objects.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: msr-migration-account
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: msr-migration-role
rules:
  # Add/remove more permissions as needed
  - apiGroups: ["", "apps", "rbac.authorization.k8s.io", "cert-manager.
    io", "acid.zalan.do"]
    resources: ["*"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: msr-migration-role-binding
subjects:
  - kind: ServiceAccount
    name: msr-migration-account
roleRef:
  kind: Role
  name: msr-migration-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Pod
metadata:
  name: msr-migration-pod
spec:
  serviceAccountName: msr-migration-account
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: msr
  containers:
    - name: msr-migration-tool
      image: registry.mirantis.com/msr/mmt:latest
      imagePullPolicy: IfNotPresent
      command: [ "sh", "-c", "while true; do sleep 30; done;" ]
      volumeMounts:
      - name: storage
        mountPath: /storage
  restartPolicy: Never

このyamlファイルを使って各リソースを作成します。
Target MSR:

$ kubectl apply -f mmt-objects.yaml
serviceaccount/msr-migration-account created
role.rbac.authorization.k8s.io/msr-migration-role created
rolebinding.rbac.authorization.k8s.io/msr-migration-role-binding created
pod/msr-migration-pod created

次にSource MSRで取得した/home/ubuntu/temp/migration配下のファイルを全てTarget MSRの~/temp/migrationへコピーします。
Source MSR:

$ sudo scp -ri [key-file] /home/ubuntu/temp/migration/* \
 [target-account]@172.31.5.235:~/temp/migration

Target MSRの~/temp/migrationに設置されたファイルをコンテナ上の/migrationへコピーします。そのあとファイルをMSR3.0に適した形式にするため、コンテナ上でMMTを使用してtransformを実行します。
Target MSR:

$ kubectl cp ~/temp/migration msr-migration-pod:/migration

$ kubectl exec --stdin --tty msr-migration-pod -- sh
/ #
/ # ./mmt transform metadata msr  \
> --storage-mode copy \
> /migration

実行時のログ抜粋

INFO[0000] Finalizing backup directory structure
INFO[0000] Creating tar file
INFO[0000] Cleaning transform operation artifacts from directory: "/migration"

エラー無くTransform終了しました。

restore
そのままコンテナ上でmmtを使ってrestoreを実施します。

/ # ./mmt restore msr \
> --fullname msr \
> --storage-mode copy \
> /migration

実行時のログ抜粋

INFO[0010] Restoring metadata from: "/migration/msr-backup-v3.0.5-mmt.tar"
{"level":"info","msg":"Append data option set, will not empty existing tables","time":"2022-12-12T04:36:10Z"}
{"level":"info","msg":"Restoring from backup version \"3.0.5-mmt\"","time":"2022-12-12T04:36:10Z"}
{"level":"info","msg":"Restoring data","time":"2022-12-12T04:36:10Z"}
INFO[0013] Successfully restored metadata from: "/migration/msr-backup-v3.0.5-mmt.tar"

以上でマイグレーションは終了です。

最後に残作業としてMMT用につくった各リソースを消しましょう。
Target MSR:

$ kubectl delete -f mmt-objects.yaml
serviceaccount "msr-migration-account" deleted
role.rbac.authorization.k8s.io "msr-migration-role" deleted
rolebinding.rbac.authorization.k8s.io "msr-migration-role-binding" deleted
pod "msr-migration-pod" deleted

動作確認

Target MSRのWebUIへアクセスし、リポジトリにイメージが表示されているか、登録されているユーザやオーガニゼーションが正しく存在するかなど確認してみて下さい。
マイグレーションされたイメージを用いてコンテナが起動するかまで確認しておけば更に安心です。
Repository

Organizations

Target MSRよりPull&Run

$ docker run 172.31.5.235:30357/dos/hello-world:1.0
Unable to find image '172.31.5.235:30357/dos/hello-world:1.0' locally
1.0: Pulling from dos/hello-world
2db29710123e: Already exists
Digest: sha256:f54a58bc1aac5ea1a25d796ae155dc228b3f0e11d046ae276b39c4bf2f13d8c4
Status: Downloaded newer image for 172.31.5.235:30357/dos/hello-world:1.0

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

まとめ

Mirantis社によりMMTが作成されたことで、MSR2.9の環境にあるコンテナイメージは数回コマンドを実行するだけでMSR3.0の環境にマイグレーションするようになりました。
MSR2.9をご利用のお客様が、Kubernetesディストリビューションに依存しない環境で利用できるMSR3.0へマイグレーションする手助けになってくれれば幸いです。
製品に関する質問や価格、ライセンス体系などにつきましてはこちらからお問い合わせ願います。

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post

Kubernetes vs Swarm_whitepaper