コンテナ事始め(4) レジストリを構成する

前回の投稿「コンテナ事始め(3) OpenShiftにおけるPersistent Volumeについて」はこちらから。

こんにちは。デル・テクノロジーズでクラウド、コンテナ関連を担当している平原です。前回はOpenShiftにおけるPersistent Volume (永続ボリューム) について説明しました。今回はコンテナレジストリについてです。これを構成すると、今回インストールしたOpenShift環境でとりあえずアプリケーションのビルドが行えるようになります。

レジストリとは何か？

コンテナがミドルウェアやOSライブラリを個別に用意することなく、どのような環境でもすぐに実行できるよう、あらかじめそうした必要なものがパッケージ化されたもの、というのは何となく理解されているかと思います。では、そうしたパッケージ化された「モノ」はどこにあるのでしょうか？それを保管管理する場所がレジストリです。レジストリにパッケージ化されたコンテナイメージが置かれることにより、どのOpenShift/K8sクラスタからもそのイメージをダウンロードして、同じアプリケーションを即座に実行することが可能です。また、疎通環境が許せば異なる組織との間でコンテナイメージを共有することも可能です。例えば、インターネット上にはDocker Hubと呼ばれるコンテナイメージ共有サービスがあります。ここでmysqlで検索してみるとmysqlまたはmysql派生のDBアプリケーションがリストされてきます。ユーザーはこれをダウンロードして迅速にSQL環境を構築することが可能なのです。

内部OpenShiftレジストリとは？

Docker Hubは知名度の高いコンテナイメージを含めて手軽に入手できる手段であり、アカウントを作成すれば自身が作成したコンテナイメージをアップロード（公開）することも可能です。しかし、企業ユースのOpenShift/K8sにおいてDocker Hubを標準のレジストリに使用することはほぼ無いでしょう。それはDocker Hubが公開型である故にセキュリティ上のリスクも高いからです。AppStoreやGoogle Playなどと同じようにセキュリティを脅かす機能を仕込んだアプリケーション（コンテナイメージ）が公開されていないとも限りません。また、自身が公開したコンテナイメージが改ざんされないとも限りません。そして、それらを追跡する仕組みも存在しません。そうした理由から、企業ユースにおいては自社内の環境に設置したプライベートレジストリを使用するのが一般的です。このプライベートレジストリを構築するには、Red Hatが提供するQuayやOSSのHarborなどが知られていますが、OpenShiftであればそれを更に簡易に実現できるのが内部OpenShiftレジストリなのです。

どうやったら内部OpenShiftレジストリを使えるの？

内部OpenShiftレジストリはデフォルトの機能として、OpenShiftクラスタインストール完了時にインストール済みですが使える状態にはなっていません。ここではレジストリを有効化する手順を紹介します。

NFS共有の作成
NFSでなくてもReadWriteMany可能なストレージがあれば良いのですが、ここではお手軽にNFS共有を作成します。細かい手順は省略しますが、LinuxサーバーでもWindowsサーバーでも何でも構いません。私は今回の環境にあるActive Directoryサーバー上にNFS共有を作成しました。ユーザーマッピング等を考えるのも面倒なので匿名アクセス許可にしてあります。
nfs-provisionerのインストール
NFS共有をPersistent Volumeとして利用するためにnfs-provisionerをインストールします。下記githubに置いてあるファイルを作業VMにダウンロード、解凍してください
https://github.com/hirahk/nfs-provisioner
nfs-provisioner.yamlファイルを編集します。該当部分のNFSサーバーのIPアドレスとNFSエクスポート名を置き換えます。
CLIでOpenShiftにログインしていることを確認し、下記コマンドを実行します。
oc project default
oc apply -f rbac.yaml
oc apply -f nfs-provisioner.yaml
nfs-provisionerのPodが起動していることを確認します。起動を確認したら、storageclass.yamlファイルを使用してNFS用のStorageClassを作成します。
oc get pod | grep nfs-client-provisioner
oc apply -f storageclass.yaml
Persitent Volume Claim (PVC) の作成テスト
OpenShiftコンソールから管理者パースペクティブで、「Storage」「StorageClasses」からストレージクラスを確認します。
「Storage」「PersistentVolumeClaims」からPVCを作成します。
ストレージクラスはnfs-storage
PVC名はtest-nfs
アクセスモードはRWX
容量は適宜
ボリュームモードはファイルシステム
PVCが作成されることを確認します。

内部レジストリの構成

プロジェクトを「openshift-image-registry」に切り替えて、「Storage」「PersistentVolumeClaims」から内部レジストリが使用するPVCを作成します。
CLIから下記コマンドを実行し、プロジェクトを「openshift-image-registry」に切り替え、内部レジストリを構成します。修正が完了したら保存します（viのコマンドモード :wq と同じ）
oc project openshift-image-registry
oc edit configs.imageregistry.operator.openshift.io -n openshift-image-registry
黄枠の部分を変更します。
spec.managementStateを Managed に
spec.storageの claim を前のステップで作成したPVC名に
DefaultRoute を True に設定して内部レジストリを公開し、内部レジストリのPodが起動しているのを確認します。service/image-registryにClusterIPのアドレスが割り当てられていればOKです。
oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
oc get all -n openshift-image-registry
routeが作成されているのを確認します。
oc get route -n openshift-image-registry
レジストリのホスト名も確認してみます。
HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}’)
echo $HOST

アプリケーションをビルドしてみる

では、コンテナ事始め①で試したnode.jsのサンプルアプリケーションをビルド、デプロイしてみましょう。

OpenShiftコンソールの開発者パースペクティブから、適当にプロジェクトを作成し、「+追加」「Gitリポジトリー」選びます。

GitリポジトリーURL (https://github.com/sclorg/nodejs-ex) を指定します。
「トポロジー」画面でPodが起動するのを確認し、赤丸のアイコンをクリックする。
前回と同じフロントエンド画面が表示されたらOK

いかがだったでしょうか？実際には監視ツールや開発ツールとの連携などやらなくてはいけないことは諸々あるのですが、ここまでだけでもピュアなOSSでやろうとしたらこの手順では到底すみません。多くの手間をかけずに環境を構築ができるという側面もOpenShiftの価値であり、また、インフラも含めてワンストップで提供しようというのが、パブリッククラウド各社のマネージドK8sサービスであったり、当社のAPEX Cloud Platform for Red Hat OpenShiftであったりするわけですね。もう暫くOpenShiftネタで書いていこうと思いますのでどうぞお付き合いのほどよろしくお願いいたします。

すべて表示

イベントは見つかりませんでした！

ストレージ Wiki

コンテナ事始め(4) レジストリを構成する