OpenShift 上の ClearML に関する説明

Red Hat OpenShift Data Science は、ハイブリッドクラウド用のオープンソース機械学習 (ML) プラットフォームです。この投稿のタイトルから推測できると思いますが、ここでは Red Hat OpenShift Data Science について取り上げていません。OpenShift Container Platform は、無料のオープンソースとベンダーがサポートするオプションの両方を含む、非常に単純なものから複雑なものまで、AI/ML ソリューションの幅広いエコシステムをサポートします。 

この投稿は、AI ソリューションの独立系ソフトウェアベンダー (ISV) エコシステムに焦点を当てたシリーズの最初の記事です。最初に取り上げる ISV は ClearML です。

注記: これらの投稿は、Kubernetes、OpenShift、およびコンテナに関する技術的な知識があることを前提としています。Security Context Constraints (SCC) について詳しく説明するため、OpenShift ドキュメントのこのセクション が入門書として役立つでしょう。

ClearML は、機械学習ワークフロー全体に対応するオープンソースのツールスイートです。ClearML は、実験の追跡やモデル学習をはじめ、ハイパーパラメーターの最適化など、データサイエンスや MLOps 両方のあらゆる面に役立つ多数のコンポーネントを提供しています。

オープンソースと OpenShift

インターネットで見つけたソフトウェアの一部を OpenShift に組み込んで実行しようとしますが、すぐに失敗して、その試みを途中でやめてしまうことが多いようです。問題は、極めてシンプルなセキュリティ設定に関連することが一般的です。 

OpenShift では、極めて制限がかかったセキュリティ・パーミッションがデフォルトで指定されており、悪意のあるソフトウェアの影響範囲を抑え、企業を保護するように設計されています。ただし、このパーミッションのリストは、固定されているわけではありません。クラスタ管理者や、時には namespace の所有者でさえも、このようなパーミッションの範囲を細かな範囲で変更を加えることができます。また、当然ながら、管理者やセキュリティ担当者と、ソフトウェアのデプロイメントについて常に議論していることでしょう。Phoenix Project は、2013 年当初からこのような方法を取るように推奨してきました。

Helm および Operator

Kubernetes Operator のパラダイムは、デプロイするソフトウェアのインストール、更新/アップグレード、バックアップ、さらには自己修復も行うインテリジェンスを備えた制御ソフトウェアを記述するための極めて強力な手法です。しかし、レベルが 5 つにわたる成熟度をすべてサポートする Operator を作成するのは、そう簡単ではありません。

Helm チャートを使用すると、Kubernetes 環境にデプロイするソフトウェアのインストールやアップグレードを比較的簡単にテンプレート化できます。OpenShift は数年前から Helm をサポートしており、存在するソフトウェアプロジェクトの大部分で、Kubernetes にデプロイする手法として Helm が使用されています。ClearML も例外ではなく、Kubernetes へのソリューションのデプロイを可能にする堅牢な Helm チャートのセットが同梱されています。

ClearML と OpenShift

ClearML Helm チャートリポジトリ には、3 つの異なるチャートが含まれていますが、ここでは、サポート対象のデータストレージやその他のコンポーネントとともに、ClearML の Web アプリコンポーネントをデプロイするコアのサーバーチャートに着目します。この投稿の残りの部分では、OpenShift に ClearML をデプロイする手順を詳しく説明し、問題点を指摘します。 

ここでの目標は何でしょうか？トポロジーがすべてのシステムで稼働すると示されるように、チャートが完全にデプロイされた状態に到達することです。

以下を前提条件とします。

1. OpenShift クラスタの管理者であるか、クラスタ内の serviceaccounts のセキュリティ・コンテキスト制約の設定を変更するための十分な権限を持っている。
2. OpenShift CLI oc がインストールされており、権限を持つ前述のユーザーとしてクラスタにログインしている。
3. クラスタでは OpenShift ルーターが実行されており、ルートにアクセスできるように設定されている。
4. クラスタに、155GB 以上の空き容量がある RWO ボリュームの PersistentVolumeClaims に対応するように、ある種の永続ストレージが設定されている。

上記の前提条件すべてに簡単に対応する方法として、クラウドで Red Hat のマネージド OpenShift サービス の 1 つを使用することが挙げられます。

インストールに進みます。

1. ほぼすべてのパブリック Helm リポジトリと同様に、まずクライアントにリポジトリについて通知します。
    

   $ helm repo add allegroai https://allegroai.github.io/clearml-helm-charts
   
           $ helm repo update

   ClearML 手順の次のステップとして、チャートを namespace にインストールします。ただし、これについてはすでに試しており、何が問題になるかを把握しているため、OpenShift の特別な前提条件をいくつか示します。
   
    

2. OpenShift プロジェクトを作成します。
   
   こちらについては、手順が明確ではありませんが、おそらく、Kubernetes の知識があることが前提条件となっているようです。完全を期すために、忘れずにプロジェクトを作成し、クライアントでそのプロジェクトを使用するように設定されていることを確認してください。
    

   $ oc new-project clearml

3. Helm インストールで使用する次のローカルの value.yaml ファイルを作成します。
    

   elasticsearch:
   
             rbac:
   
               create: true
   
               serviceAccountName: "clearml-elastic"
   
           
   
           apiserver:
   
             podSecurityContext:
   
               runAsUser: 0
   
             service:
   
               type: ClusterIP
   
           
   
           fileserver:
   
             service:
   
               type: ClusterIP
   
           
   
           webserver:
   
             service:
   
               type: ClusterIP

4. ServiceAccounts に対して次の SCC を設定します。
    

   $ oc adm policy add-scc-to-user anyuid -z clearml-mongodb
   
           $ oc adm policy add-scc-to-user anyuid -z clearml-redis
   
           $ oc adm policy add-scc-to-user anyuid -z default
   
           $ oc adm policy add-scc-to-user privileged -z clearml-elastic

   
   上記を分析してみましょう。
   
   Helm チャートの特徴の 1 つとして、他のチャートを参照したり、他のチャートを含めたりできる点が挙げられます。ClearML のソリューションは、MongoDB、Redis、ElasticSearch を使用しており、それぞれに、該当のチャートが埋め込まれています。
   
   MongoDB チャートと Redis チャートはどちらも、デプロイ時に serviceaccounts (SA) を作成します。これらの各ソリューションのコンテナは、特定のユーザー/UID として実行されます。デフォルトでは、OpenShift は UID を指定してコンテナを実行できず、実行前に UID が無作為に割り当てられます。Mongo と Redis のそれぞれのデプロイメントは明示的に UID を要求するため、エラーが発生してデプロイに失敗します。
   
   anyuid SecurityContextConstraint (SCC) を使用すると、名前から予想されるように、root (UID=0) など、指定したユーザー ID で ServiceAccount を実行できます。そのため、最初の 2 つのコマンドを実行することで、作成された特定の SA で anyuid SCC を使用できるようになります。
   
   ElasticSearch にはもう少し要件があります。たとえば、アップストリームのチャートでは、実行先のノードにあるシステムの一部を変更する必要性があります。残念ながら、sysctl 操作は特権操作であるため、特権のある SCC を使用する必要があります。さらに、ElasticSearch チャートはデフォルトでは SA を作成しないため、前の手順の value.yaml で SA の作成が指定されていることがわかります。
   
   最後に、ClearML コンポーネント (Web サーバー、API サーバー、ファイルサーバー) は、それぞれのデプロイメントで SA を指定しません。SA が Pod テンプレートで指定されていない場合、OpenShift はデフォルトと呼ばれる SA を使用します。ClearML Web サーバーコンテナは UID 0 として実行されることが前提ですが、デプロイメントではこの点が指定されていません。Web サーバーを UID0 として実行するように OpenShift に指示し (Helm チャートの podSecurityContext/runAsUser 設定経由)、デフォルトの SCC anyuid を付与してこの動作を許可する必要がありました。
   
   これまでの内容をすべて確認して、ClearML をインストールしてないにもかかわらず、SCC をなぜ変更するのかと思ったかもしれません。こういった SA は存在するのでしょうか? 実際には、これらのアクセス許可設定は必須のアクセス制御の一種です。コマンドは最終的に、指定された動作を許可するエントリーを Kubernetes に作成します。ルールが許可する操作を行わなくても、特に問題ではありません。ただし、このような各種デプロイメントが作成されて、SA を使用すると、前述のルールは存在し、これらのルールにより、目的の動作が許可されます。
   
    

5. SCC 設定が完了すると、Helm チャートをインストールできるようになります。

   $ helm install -f values.yaml clearml allegroai/clearml

    

6. 値ファイルは、ClearML コンポーネント用に Ingress を作成するように要求せず、チャートの通常の動作では、Ingress も作成されません。これらの値は、サービスを NodePort ではなく ClusterIP として作成する必要があることを指定します。OpenShift 環境にはルーターが存在するため、Helm チャートによって作成されたサービスの Route オブジェクトを簡単に作成できます。

   $ oc expose svc clearml-apiserver
   
           $ oc expose svc clearml-webserver
   
           $ oc expose svc clearml-fileserver

    

7. しばらくすると、OpenShift UI にアクセスし、開発者パースペクティブに移動して、デプロイされた ClearML 環境のトポロジーを確認できます。
   
    

   

   
   
   OpenShift トポロジービューを使用すると、クラスタの外部に公開されているアプリケーションに簡単にアクセスできます。clearml-webserver デプロイメントの小さなアイコン (上の赤丸で囲んだ部分) をクリックするだけで、新しいブラウザータブでその URL が開きます。
   
    

8. 最終的に、ClearML はすべてのサンプルコンテンツとワークスペースで同期します。
   
    

   

以上です。これで、OpenShift で ClearML オープンソースを使用する準備が整いました。今後の投稿で、実稼働レベルの ClearML Enterprise をデプロイする点について説明します。