ビッグ・データ・サービス3.0.27以降でのJupyterHubの使用

JupyterHubを使用して、ユーザーのグループのビッグ・データ・サービス3.0.27以降のODH 2.xノートブックを管理します。

前提条件

JupyterHubへのアクセス

ビッグ・データ・サービス3.0.27以降のODH 2.xクラスタのブラウザからJupyterHubにアクセスします。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。

ノートブックの生成

ビッグ・データ・サービス3.0.27以降のODH 2.xクラスタでは、次のSpawner構成がサポートされています。

次を完了します:

システムネイティブ認証:
1. サインインしたユーザー資格証明を使用してサインインします。
2. ユーザー名を入力します
3. パスワードの入力
SamlSSOAuthenticatorの使用:
1. SSOサイン・インでサイン・インします。
2. 構成されたSSOアプリケーションでサインインを完了します。

HAクラスタでのノートブックの生成

AD統合クラスタの場合:

前述のいずれかの方法を使用してサインインします。この認可は、ユーザーがLinuxホストに存在する場合にのみ機能します。JupyterHubは、ノートブック・サーバーの起動の試行中にLinuxホストでユーザーを検索します。
「サーバー・オプション」ページにリダイレクトされ、Kerberosチケットをリクエストする必要があります。このチケットは、Kerberosプリンシパルとkeytabファイル、またはKerberosパスワードを使用してリクエストできます。クラスタ管理者は、Kerberosプリンシパルとkeytabファイル、またはKerberosパスワードを提供できます。Kerberosチケットは、使用するHDFSディレクトリおよびその他のビッグ・データ・サービスにアクセスする必要があります。

非HAクラスタでのノートブックの生成

AD統合クラスタの場合:

前述のいずれかの方法を使用してサインインします。この認可は、ユーザーがLinuxホストに存在する場合にのみ機能します。JupyterHubは、ノートブック・サーバーの起動の試行中にLinuxホストでユーザーを検索します。

JupyterHubの管理

JupyterHub adminユーザーは、次のタスクを実行して、ビッグ・データ・サービス3.0.27以降のODH 2.xノードでJupyterHubのノートブックを管理できます。

systemctlコマンドを使用してOracle Linux 7サービスを管理するには、システム・サービスの作業を参照してください。

Oracle Cloud Infrastructureインスタンスにサインインするには、インスタンスへの接続を参照してください。

Ambariを使用したJupyterHubの停止、起動または再起動

管理者は、JupyterHubを停止または無効化して、メモリーなどのリソースを消費しないようにできます。予期しない問題や動作が発生した場合は、再起動すると解決することがあります。

ノート

Ambari for Big Data Service 3.0.27以降のクラスタでJupyterHubを停止または起動します。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「アクション」をクリックします:
- JupyterHubを起動するには、「開始」をクリックします。
- JupyterHubを停止するには「停止」をクリックします。
- JupyterHubを再起動するには、「再起動」をクリックします。

JupyterHubサーバーの追加

管理者は、JupyterHubサーバーをビッグ・データ・サービス・ノードに追加できます。

ノート

これは、Big Data Service 3.0.27以降のクラスタで使用できます。

Apache Ambariにアクセスします。
サイド・ツールバーで、「ホスト」をクリックします。
JupyterHubサーバーを追加するには、JupyterHubがインストールされていないホストを選択します。
「追加」をクリックします。
JupyterHubサーバーを選択します。

JupyterHubサーバーの移動

管理者は、JupyterHubサーバーを別のビッグ・データ・サービス・ノードに移動できます。

ノート

これは、Big Data Service 3.0.27以降のクラスタで使用できます。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「アクション」、「JupyterHubサーバーの移動」の順にクリックします。
「次へ」をクリックします。
JupyterHubサーバーの移動先のホストを選択します。
移動ウィザードを完了します。

JupyterHubサービス/ヘルス・チェックの実行

管理者は、Ambariを介してJupyterHubサービス/ヘルス・チェックを実行できます。

ノート

これは、Big Data Service 3.0.27以降のクラスタで使用できます。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「処理」、「サービス・チェックの実行」の順にクリックします。

ユーザーおよび権限の管理

ノートブックを作成し、オプションでビッグ・データ・サービス3.0.27以降のODH 2.xクラスタでJupyterHubを管理できるように、2つの認証メソッドのいずれかを使用してJupyterHubに対してユーザーを認証します。

JupyterHubユーザーは、Active Directory (AD)以外のビッグ・データ・サービス・クラスタのすべてのビッグ・データ・サービス・クラスタ・ノードでOSユーザーとして追加する必要があります。この場合、ユーザーはすべてのクラスタ・ノード間で自動的に同期されません。管理者は、JupyterHubにサインインする前に、JupyterHubユーザー管理スクリプトを使用してユーザーおよびグループを追加できます。

前提条件

JupyterHubにアクセスする前に、次のことを完了します。

JupyterHubがインストールされているノードにSSHサインインします。
/usr/odh/current/jupyterhub/installにナビゲートします。

sample_user_groups.jsonファイル内のすべてのユーザーおよびグループの詳細を指定するには、次を実行します:

sudo python3 UserGroupManager.py sample_user_groups.json
          
          Verify user creation by executing the following command:
          id <any-user-name>

サポートされる認証タイプ

NativeAuthenticator: このオーセンティケータは、小規模または中規模のJupyterHubアプリケーションに使用されます。サインアップおよび認証は、外部サービスに依存することなく、JupyterHubにネイティブとして実装されます。
SSOAuthenticator: このオーセンティケータは、SAML2サービス・プロバイダとして機能するjupyterhub.auth.Authenticatorのサブクラスを提供します。適切に構成されたSAML2アイデンティティ・プロバイダに移動し、JupyterHubのシングル・サインオンを有効にします。

システム固有の認証

ネイティブ認証は、ユーザーを認証するためのJupyterHubユーザー・データベースによって異なります。

ネイティブ認証は、HAクラスタと非HAクラスタの両方に適用されます。ネイティブ・オーセンティケータの詳細は、ネイティブ・オーセンティケータを参照してください。

HAクラスタでユーザーを認可するための前提条件

ネイティブ認証を使用してビッグ・データ・サービスHAクラスタのユーザーを認可するには、これらの前提条件が満たされている必要があります。

ユーザーは、Linuxホストに存在する必要があります。次のコマンドを実行して、クラスタのすべてのノードで新しいLinuxユーザーを追加します。
```
# Add linux user
dcli -C "useradd -d /home/<username> -m -s /bin/bash <username>"
```
ノートブック・サーバーを起動するには、ユーザーは、プリンシパルおよびkeytabファイルのpath/passwordを提供し、JupyterHubインタフェースからKerberosチケットをリクエストする必要があります。keytabを作成するには、クラスタ管理者は、パスワードおよびkeytabファイルを持つKerberosプリンシパルを追加する必要があります。クラスタの最初のマスター・ノード(mn0)で次のコマンドを実行します。
```
# Create a kdc principal with password or give access to existing keytabs.
kadmin.local -q "addprinc <principalname>"
Password Prompt: Enter passwrod
 
# Create a kdc principal with keytab file or give access to existing keytabs.
kadmin.local -q 'ktadd -k /etc/security/keytabs/<principal>.keytab principal'
```
新しいユーザーは、個々のノートブックが/users/<username>/notebooksに格納されるため、HDFSディレクトリ hdfs:///users/<username>にファイルを格納するための正しいRanger権限を持っている必要があります。クラスタ管理者は、Webブラウザで次のURLを開いて、Rangerインタフェースから必要な権限を追加できます。
```
https://<un0-host-ip>:6182
```
新しいユーザーには、Yarn、Hiveおよびオブジェクト・ストレージでデータの読取りと書込み、およびSparkジョブを実行するための正しい権限が必要です。または、Spark、Yarnおよびその他のサービスに対する明示的な権限を取得せずに、Livy偽装を使用(Livyユーザーとしてビッグ・データ・サービス・ジョブを実行)することもできます。

次のコマンドを実行して、新しいユーザーにHDFSディレクトリへのアクセス権を付与します。

# Give access to hdfs directory
# kdc realm is by default BDSCLOUDSERVICE.ORACLE.COM
kinit -kt /etc/security/keytabs/hdfs.headless.keytab hdfs-<clustername>@<kdc_realm> 
sudo su hdfs -c "hdfs dfs -mkdir /user/<username>"
sudo su hdfs -c "hdfs dfs -chown -R jupy5 /user/<username>"

非HAクラスタでのユーザーの認可の前提条件

ネイティブ認証を使用してビッグ・データ・サービス非HAクラスタのユーザーを認可するには、これらの前提条件が満たされている必要があります。

ユーザーは、Linuxホストに存在する必要があります。次のコマンドを実行して、クラスタのすべてのノードで新しいLinuxユーザーを追加します。
```
# Add linux user
dcli -C "useradd -d /home/<username> -m -s /bin/bash <username>"
```
新しいユーザーは、HDFSディレクトリ hdfs:///users/<username>にファイルを格納するための適切な権限を持っている必要があります。次のコマンドを実行して、新しいユーザーにHDFSディレクトリへのアクセス権を付与します。
```
# Give access to hdfs directory
sudo su hdfs -c "hdfs dfs -mkdir /user/<username>"
sudo su hdfs -c "hdfs dfs -chown -R jupy5 /user/<username>"
```

管理者ユーザーの追加

管理者ユーザーは、JupyterHubの構成および管理について責任を負います。また、管理者ユーザーは、JupyterHubで新しくサインアップしたユーザーの認可も担当します。

管理者ユーザーを追加するには、HAクラスタまたは非HAクラスタの前提条件が満たされている必要があります。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced Configs」の順にクリックします。
「Advanced jupyterhub-config」を選択します。
c.Authenticator.admin_usersに管理ユーザーを追加します。
「保存」をクリックします

JupyterHub構成ファイルの管理ユーザーは、サインイン時に明示的な認可を受ける必要はありません。サインアップ後、直接サインインできます。

他のユーザーの追加

他のユーザーを追加する前に、ビッグ・データ・サービス・クラスタの前提条件を満たす必要があります。

JupyterHubにアクセスします。
新しいユーザーをサインアップします。管理者以外のユーザーは、管理者ユーザーからの明示的な認可が必要です。
管理ユーザーは、JupyterHubにサインインし、新しいメニュー・オプションからサインイン・ユーザーを認可する必要があります。
これで、新しいユーザーはサインインできます。

ユーザーの削除

管理者ユーザーは、JupyterHubユーザーを削除できます。

JupyterHubにアクセスします。
「File」>HubControlPanelを開きます。
「Authorize Users」ページに移動します。
削除するユーザーを削除します。

LDAP認証

Ambari for Big Data Service 3.0.27以降のODH 2.xクラスタを介してLDAP認証を使用できます。

Ambariを使用したLDAP認証の使用

LDAP認証プロバイダを使用するには、LDAP接続の詳細でJupyterHub構成ファイルを更新する必要があります。

ノート

Big Data Service 3.0.27以降のクラスタでLDAP認証にAmbariを使用します。

LDAPオーセンティケータの詳細は、LDAPオーセンティケータを参照してください。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。

「構成」をクリックし、「拡張jupyterhub構成」→「ベース設定」で次のように入力します。

c.JupyterHub.authenticator_class = 'ldapauthenticator.LDAPAuthenticator'
          c.LDAPAuthenticator.server_port = <port>
          c.LDAPAuthenticator.server_address = 'ldaps://<host>'
          c.LDAPAuthenticator.lookup_dn = False
          c.LDAPAuthenticator.use_ssl = True
          c.LDAPAuthenticator.lookup_dn_search_filter = '({login_attr}={login})'
          c.LDAPAuthenticator.lookup_dn_search_user = '<user>'
          c.LDAPAuthenticator.lookup_dn_search_password = '<example-password>'
          #c.LDAPAuthenticator.user_search_base = 'ou=KerberosPrincipals,ou=Hadoop,dc=cesa,dc=corp'
          c.LDAPAuthenticator.user_attribute = 'sAMAccountName'
          c.LDAPAuthenticator.lookup_dn_user_dn_attribute = 'cn'
          c.LDAPAuthenticator.escape_userdn = False
          c.LDAPAuthenticator.bind_dn_template = ["cn={username},ou=KerberosPrincipals,ou=Hadoop,dc=cesa,dc=corp"]

JupyterHubを再起動します。

ビッグ・データ・サービスJupyterHubサービスでのSSO認証の構成

ビッグ・データ・サービス3.0.27以降のODH 2.x JupyterHubサービスのpConfigure SSO認証。

Oracleアイデンティティ・ドメインの使用

Oracle Identity Domainを使用して、ビッグ・データ・サービス3.0.27以降のODH 2.x JupyterHubクラスタでSSO認証を設定できます。

アイデンティティ・ドメインの作成詳細は、を参照してください。
ドメインの「統合アプリケーション」で、SAMLアプリケーションを追加します。
アプリケーションの作成中に、次の必要な詳細を指定します。
- エンティティID: これは一意のIDです。JupyterHubのベースURL(https://myjupyterhub/saml2_auth/entなど)を使用できます。
- アサーション・コンシューマのURL:
  - JupyterHub URL: https://<Jupyterhub-Host>:<Port>/hub/saml2_auth/acs
  - Load BalancerのURL: https://<Load-Balancer>:<Port>/hub/saml2_auth/acs
- シングル・ログアウトURL、ログアウト・レスポンスURL: https://<Jupyterhub-Host>:<Port>/hub/logout
アプリケーションをアクティブ化します。
アプリケーションにユーザーを割り当てます。
作成したアプリケーションに移動し、「アイデンティティ・プロバイダ・メタデータのダウンロード」をクリックしてから、このメタデータ・ファイルをJupyterHubホストにコピーし、すべてのユーザーの読取りアクセス権があることを確認します。
ユーザーのセッション・パラメータを更新します。詳細は、セッション制限の設定を参照してください。

Ambariを使用したOKTAの使用

OKTAを使用して、ビッグ・データ・サービス3.0.27以降のODH 2.x JupyterHubクラスタでSSO認証を設定できます。

OKTAへのサインイン
サイド・ツールバーで、「アプリケーション」→「アプリケーション」→「アプリケーション統合の作成」をクリックします。
「SAML 2.0」を選択します。
次の詳細を指定し、アプリケーションを作成します。
- アプリケーション名: アプリケーションの名前。たとえば、JupyterHub-SSOです。
- シングルサインオンURL: シングルサインオンURL。たとえば: https://<Jupyterhub-Host>:<Port>/hub/saml2_auth/acs。
- オーディエンスURI (SPエンティティID): 一意のID。JupyterHubのベースURLを使用できます。たとえば: https://myjupyterhub/saml2_auth/ent。
アプリケーションにユーザーを割り当てます。
「サインオン」タブをクリックして、次の詳細を取得します。
- メタデータURL: メタデータ・ファイルをダウンロードし、JupyterHubホストにコピーします。
- サインオンURL: サインオンURLをコピーし、JupyterHub構成(saml2_login_url)で更新します。

SSOの有効化

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「構成」→「設定」→「ノートブック・サーバー・オーセンティケータ」をクリックします。
SamlSSOAuthenticatorを選択します。
「保存」をクリックします
「詳細」をクリックします。
Advanced Jupiter-configのSamlSSOAuthenticator-Configsセクションのパラメータを更新します。
- c.Saml2Authenticator.saml2_metadata_file name: JupyterHubインストール済ノードのアイデンティティ・プロバイダ(IDP)メタデータ・ファイルへのパス。例: '/tmp/IDCSMetadata.xml'。
- c.Saml2Authenticator.saml2_entity_id: アイデンティティ・プロバイダ(IDP)からサービス・プロバイダ(JupyterHub)へのマッピングを維持するための一意の識別子。この識別子は、IDPアプリケーション構成とサービス・プロバイダ(JupyterHub)の両方で同じである必要があります。たとえば: https://myjupyterhub/saml2_auth/ent
- c.Saml2Authenticator.saml2_login_URL: シングル・サインオン(SSO)のサインインURL。Oracle IDCSユーザーの場合、IDP metadata.xml fileからこれを取得できます。metadata.xml fileファイルでAssertionConsumerServiceタグを検索し、location属性の値を取得します。OKTAの場合は、サインイン・タブにあるサインインURLの値をコピーします。たとえば: https://idcs-1234.identity.oraclecloud.com/fed/v1/sp/sso
- #c.Saml2Authenticator.saml2_metadata_URL: オプション。アイデンティティ・プロバイダ(IDP)・メタデータ・ファイルのURL。指定されたURLが、インストールされたJupyterHubノードからアクセス可能であることを確認してください。saml2_metadata_filenameまたはsaml2_metadata_urlのいずれかが必要です。たとえば: https://idcs-1234.identity.oraclecloud.com/sso/saml/metadata
- #c.Saml2Authenticator.saml2_attribute_username: オプション。SAMLアサーションからユーザーとみなす属性を指定します。属性が指定されていない場合、サインイン・ユーザー名はユーザーとして処理されます。「電子メール」を入力します。
- #c.Saml2Authenticator.saml2_private_file_pathおよび#c.Saml2Authenticator.saml2_public_file_path: オプション。IDプロバイダ(IDP)がアサーション・データを暗号化する場合、サービス・プロバイダ(SP)のJupyterHubは、アサーション・データを復号化するために必要な秘密キーと公開キーを提供する必要があります。例:
  
  #c.Saml2Authenticator.saml2_public_file_path: '/etc/security/serverKeys/jupyterhubsso.key'
  
  #c.Saml2Authenticator.saml2_public_file_path: '/etc/security/serverKeys/jupyterhubsso.crt'
- #c.Saml2Authenticator.login_service: オプション。これにより、サインイン・ボタンが'Sign in with {login_service}'として表示されるように構成されます。'Oracle IDCS'と入力します。
JupyterHubを再起動します。

Ambariを使用したJupyterHubの構成

管理者は、Ambari for Big Data Service 3.0.27以降のODH 2.xクラスタを介してJupyterHub構成を管理できます。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」をクリックします。次の構成がサポートされています。
- Spawner構成:
  - ODHSystemdSpawner: JupyterHubサーバーがインストールされているローカル・ノードでsystemdを使用してシングル・ユーザー・ノートブック・サーバーを生成するために使用されるカスタム・スポーナ。
  - ODHYarnSpawner: YARNクラスタでノートブック・サーバーを起動するJupyterHubのカスタム・スポーナ。これは、ビッグ・データ・サービスで使用されるデフォルトのスポーナです。
- 共通構成: バインディングIPやJupyterHubが実行されるポートなどの構成です。
- オーセンティケータ構成: JupyterHubにサインインするユーザーの認証に使用できる2つのオーセンティケータがサポートされています。認証タイプの詳細は、ユーザーおよび権限の管理を参照してください。
- 永続性モード:
  - HDFS: これにより、HDFSを介してノートブックを永続化できます
  - Git: これにより、Gitを使用したバージョン制御にJupyterLab拡張機能を使用でき、これにより、Gitを介したリモート・サーバー上のノートブックの永続化が可能になります。

ノートブックの生成

ビッグ・データ・サービス3.0.27以降のODH 2.xクラスタでは、次のSpawner構成がサポートされています。

次を完了します:

システムネイティブ認証:
1. サインインしたユーザー資格証明を使用してサインインします。
2. ユーザー名を入力します
3. パスワードの入力
SamlSSOAuthenticatorの使用:
1. SSOサイン・インでサイン・インします。
2. 構成されたSSOアプリケーションでサインインを完了します。

HAクラスタでのノートブックの生成

AD統合クラスタの場合:

前述のいずれかの方法を使用してサインインします。この認可は、ユーザーがLinuxホストに存在する場合にのみ機能します。JupyterHubは、ノートブック・サーバーの起動の試行中にLinuxホストでユーザーを検索します。
「サーバー・オプション」ページにリダイレクトされ、Kerberosチケットをリクエストする必要があります。このチケットは、Kerberosプリンシパルとkeytabファイル、またはKerberosパスワードを使用してリクエストできます。クラスタ管理者は、Kerberosプリンシパルとkeytabファイル、またはKerberosパスワードを提供できます。Kerberosチケットは、使用するHDFSディレクトリおよびその他のビッグ・データ・サービスにアクセスする必要があります。

非HAクラスタでのノートブックの生成

AD統合クラスタの場合:

Git環境の設定

ビッグ・データ・サービス・クラスタ・ノードのSSHキー/アクセス・トークンを構成します。
ノートブック永続性モードをGitとして選択します。

Git接続の設定

JupyterHubのGit接続を設定するには、次の手順を実行します。

ビッグ・データ・サービス・クラスタ・ノードのSSHキーの構成/アクセス・トークン。
ノートブック永続性モードをGitとして選択します

SSHキー・ペアの生成

ターミナルまたはコマンド・プロンプトを開きます。
新しいSSHキー・ペアを生成するには、次を実行します:
```
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
(オプション)プロンプトに従ってファイルの場所とパスフレーズを指定します(オプション)。
公開キーの登録:
1. Gitサーバー・アカウントにサインインします。
2. アカウントの設定またはSSHキー・セクションに移動します。
3. 公開キー(~/.ssh/id_rsa.pub)の内容をGitサーバー・アカウントに追加します。
SSHエージェントを構成します。

SSHエージェントによって管理されるSSHキーが多数ある場合は、構成ファイルを作成して、Gitサーバーごとに使用するキーを指定できます。
1. テキスト・エディタで、SSH構成ファイル(~/.ssh/config)を開くか作成します。
2. 各SSHキーに関連付けられたアイデンティティ・ファイルを指定する各Gitサーバーのエントリを追加します。
SSHを使用してローカルGitリポジトリをリモートに接続します。
1. ターミナルまたはコマンド・プロンプトを開きます。
2. ローカルGitリポジトリに移動します。
3. リモートURLをHTTPSからSSHに切り替えるには、次を実行します。
```
git remote set-url origin git@github.com:username/repository.git
```
  username/repository.gitを適切なGitリポジトリURLに置き換えます。
SSH接続を確認します。
1. GitサーバーへのSSH接続をテストします。
```
ssh -T git@github.com
```
(オプション)ホストの信頼性の確認を求められた場合は、yesを入力して続行します。

アクセス・トークンの使用

次の方法でアクセス・トークンを使用できます。

GitHub:
1. GitHubアカウントにサインインします。
2. 「設定」→「開発者設定」→「個人アクセス・トークン」にナビゲートします。
3. 適切な権限を持つ新しいアクセス・トークンを生成します。
4. 認証を求められたら、アクセス・トークンをパスワードとして使用します。
GitLab:
1. GitHubアカウントにサインインします。
2. 「設定」→「アクセス・トークン」にナビゲートします。
3. 適切な権限を持つ新しいアクセス・トークンを生成します。
4. 認証を求められたら、アクセス・トークンをパスワードとして使用します。
BitBucket:
1. BitBucketアカウントにサインインします。
2. 「設定」→「アプリケーション・パスワード」にナビゲートします。
3. 適切な権限を持つ新しいアプリケーション・パスワード・トークンを生成します。
4. 認証を求められたら、新しいアプリケーション・パスワードをパスワードとして使用します。

Gitでの永続性モードの選択

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Settings」の順にクリックします。
ノートブック永続性モードを検索し、ドロップダウンから「Git」を選択します。
「アクション」、「すべて再起動」の順にクリックします。

ノートブックを格納するためのJupyterHubでのHDFSの設定

HDFSをJupyterHubノートブックのデフォルト・ストレージとして設定するには、HDFSとして永続性モードを選択します。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Settings」の順にクリックします。
ノートブック永続性モードを検索し、ドロップダウンから「HDFS」を選択します。
「アクション」、「すべて再起動」の順にクリックします。

ノートブックを格納するためのJupyterHubでのオブジェクト・ストレージの設定

管理者ユーザーは、個々のユーザー・ノートブックをHDFSではなくオブジェクト・ストレージに格納できます。コンテンツ・マネージャをHDFSからオブジェクト・ストレージに変更すると、既存のノートブックはオブジェクト・ストレージにコピーされません。新しいノートブックはオブジェクト・ストレージに保存されます。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced」の順にクリックします。

c.YarnSpawner.args = yarn_spawner_default_ragsセクションに移動し、コンテンツを次のように置き換えます。

c.YarnSpawner.args = ['--ServerApp.contents_manager_class="s3contents.S3ContentsManager"', '--S3ContentsManager.bucket="<bucket-name>"', '--S3ContentsManager.access_key_id="<accesskey>"', '--S3ContentsManager.secret_access_key="<secret-key>"', '--S3ContentsManager.endpoint_url="https://<object-storage-endpoint>"', '–S3ContentsManager.region_name=""','–ServerApp.root_dir=""']

「アクション」メニューからすべてのJupyterHubサーバーを再起動します。

`rclone`とユーザー・プリンシパル認証を使用したOracle Object Storageバケットのマウント

JupyterHubユーザーに合せて調整されたrcloneおよびfuse3を使用して、rcloneとユーザー・プリンシパル認証(APIキー)をビッグ・データ・サービス・クラスタ・ノードで使用してOracle Object Storageをマウントできます。

Big Data Service 3.0.28以降のODH 2.xクラスタでは、この手順を実行して、JupyterHub環境から直接オブジェクト・ストレージにシームレスにアクセスおよび管理できるようにし、データ処理機能を強化します。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「サマリー」、JUPYTERHUB_SERVERの順にクリックします。
表示されるホスト情報からホスト情報を取得します。
クラスタの作成時に使用されたSSH資格証明を使用してビッグ・データ・サービス・ホストにサインインします。詳細は、SSHを使用したクラスタ・ノードへの接続を参照してください。
ノードにrcloneおよびfuse3がインストールされていることを確認するには、次を実行します:
```
rclone version 
# Ensure version is v1.66

fusermount3 --version 
# Ensure FUSE version 3 is installed
```
APIキーを作成し、rclone構成を設定します。詳細は、OCIユーザーおよびAPIキーを使用した認証の設定、OCIテナンシ・ネームスペースおよびバケット・コンパートメントの取得を参照してください。
rclone構成を設定します。詳細は、「OCIオブジェクト・ストレージのRcloneの構成」を参照してください。
オブジェクト・ストレージ・バケットをマウントするには、サインイン・ユーザーとして次のコマンドを実行します。
次は、サインイン・ユーザー`Jupyterhub`を使用してマウント操作を実行します。デーモン・プロセスは、この操作がトリガーされるノードでLinuxプロセスとして実行されます。
```
sudo -u jupyterhub rclone mount remote_name:bucket1 /home/jupyterhub/mount_dir --allow-non-empty --file-perms 0666 --dir-perms 0777 --vfs-cache-mode=full --dir-cache-time=30s --vfs-write-back=2m --cache-info-age=60m --daemon
```
ノート

Jupyterノートブックを操作するには、マウントの場所がサインイン・ユーザーのホーム・ディレクトリ内にあることを確認し、マウント・ディレクトリが空であることを確認します。
```
sudo -u jupyterhub ls -ltr /home/jupyterhub/mount_dir
```
(オプション)マウントが成功したことを確認するには、次を実行します。この例では、mount_dirバケットの内容をリストします。
```
sudo -u jupyterhub ls -ltr /home/jupyterhub/mount_dir
```
クリーンアップ手順を実行します。
バックグラウンド・モードで実行する場合は、手動でマウントを停止する必要があります。JupyterHubおよびノートブック・サーバーが使用されていない場合、次のクリーンアップ操作を使用します。
Linuxの場合:
```
sudo -u jupyterhub fusermount3 -u /home/jupyterhub/mount_dir
```
マウントポイントがビジー状態の場合など、umount操作が失敗することがあります。その場合は、ユーザーが手動でマウントを停止する必要があります。
```
sudo -u jupyterhub umount -l /home/jupyterhub/mount_dir : lazy unmount
sudo -u jupyterhub umount -f /home/jupyterhub/mount_dir : force unmount
```

JupyterHubでのConda環境の管理

ノート

Big Data Service 3.0.28以降のODH 2.xクラスタでConda環境を管理できます。

特定の依存関係を持つconda環境を作成し、作成されたconda環境を指す4つのカーネル(Python/PySpark/Spark/SparkR)を作成します。
この操作を使用して作成されたConda環境およびカーネルは、すべてのノートブック・サーバー・ユーザーが使用できます。
個別のconda環境作成操作は、サービスの再起動で操作を切り離すことです。

前提条件

JupyterHubは、Ambari UIを介してインストールされます。
クラスタへのインターネット・アクセスを検証して、condaの作成中に依存関係をダウンロードします。
この操作を使用して作成されたConda環境およびカーネルは、すべてのノートブック・サーバー・ユーザーが使用できます。」
指定:
- conda作成の失敗を回避するためのConda追加構成。詳細は、conda createを参照してください。
- 標準要件.txt形式の依存性。
- 存在しないconda環境名。
conda envsまたはカーネルを手動で削除します。

グローバル構成のカスタマイズ

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced」の順にクリックします。
jupyterhub-conda-env-configsセクションまでスクロールします。
次のフィールドを更新します。
- Condaの追加構成: このフィールドは、デフォルトのconda作成コマンドに追加する追加パラメータを提供するために使用されます。デフォルトのconda作成コマンドは'conda create -y -p conda_env_full_path -c conda-forge pip python=3.8です。
  追加の構成が'--override-channels --no-default-packages --no-pin -c pytorch'として指定されている場合、最終的なconda作成コマンドの実行は'conda create -y -p conda_env_full_path -c conda-forge pip python=3.8 --override-channels --no-default-packages --no-pin -c pytorch'.です
- Conda環境名: このフィールドは、conda環境に一意の名前を指定するためのものです。新しい環境が作成されるたびに、一意のconda環境を指定します。
- Python依存性: このフィールドには、すべてのpython/R/Ruby/Lua/Scala/Java/JavaScript/C/C++/FORTRANなど、condaチャネルからアクセス可能な依存関係が要件.txtファイルの形式でリストされます。
  .txtファイルの要件の詳細は、「要件ファイルの形式」を参照してください。
「保存」をクリックします
「アクション」をクリックし、「Conda環境のアクティブ化」を選択します。
アクティブ化が完了すると、JupyterHub UIに次のように表示されます。
- Pythonカーネル: conda_python3_kernel_{conda_env_name}
- PySparkカーネル: conda_pyspark_kernel_{conda_env_name}
- Sparkカーネル: conda_spark_kernel_{conda_env_name}
- SparkRカーネル: conda_sparkr_kernel_{conda_env_name}
ノート

これらのカーネルは、作成されたconda環境を指しています。

ユーザー固有のConda環境の設定

この操作により、指定された依存関係を持つconda環境が作成され、作成されたconda環境を指す指定されたカーネル(Python/PySpark/Spark/SparkR)が作成されます。

指定されたconda環境がすでに存在する場合、操作は直接カーネル作成ステップに進みます
この操作を使用して作成されたConda環境またはカーネルは、特定のユーザーのみが使用できます

sudoモードでpythonスクリプトkernel_install_script.pyを手動で実行します。

 '/var/lib/ambari-server/resources/mpacks/odh-ambari-mpack-2.0.8/stacks/ODH/1.1.12/services/JUPYTER/package/scripts/'

例:

sudo python kernel_install_script.py --conda_env_name conda_jupy_env_1 --conda_additional_configs '--override-channels --no-default-packages --no-pin -c pytorch' --custom_requirements_txt_file_path ./req.txt --kernel_type spark --kernel_name spark_jupyterhub_1 --user jupyterhub

前提条件

クラスタへのインターネット・アクセスを検証して、condaの作成中に依存関係をダウンロードします。そうしないと、作成が失敗します。
--kernel_nameという名前のカーネルが存在する場合、例外がスローされます。
次の情報が提供されます。
- 作成の失敗を回避するためのConda構成。詳細は、https://conda.io/projects/conda/en/latest/commands/create.htmlを参照してください。
- 標準要件.txt形式で提供される依存性。
任意のユーザーのconda列挙またはカーネルを手動で削除します。

カスタマイズに使用可能な構成

--user (必須): カーネルおよびconda環境が作成されるOSおよびJupyterHubユーザー。
--conda_env_name (必須): --userに対して新しいenが作成されるたびに、conda環境に一意の名前を指定します。
--kernel_name: (必須)一意のカーネル名を指定します。
--kernel_type: (必須)次のいずれかである必要があります(python / PysPark / Spark / SparkR)
--custom_requirements_txt_file_path: (オプション)いずれかのPython/R/Ruby/Lua/Scala/Java/JavaScript/C/C++/FORTRANなどで、condaチャネルを使用して依存関係がインストールされている場合は、要件の.txtファイルにそれらのライブラリを指定し、フルパスを指定する必要があります。
要件.txtファイルを定義するための標準フォーマットの詳細は、https://pip.pypa.io/en/stable/reference/requirements-file-format/を参照してください。
--conda_additional_configs: (オプション)
- このフィールドには、デフォルトのconda作成コマンドに追加する追加パラメータが表示されます。
- デフォルトのconda作成コマンドは'conda create -y -p conda_env_full_path -c conda-forge pip python=3.8'です。
- --conda_additional_configsが'--override-channels --no-default-packages --no-pin -c pytorch'として指定されている場合、最終的なconda作成コマンドの実行は'conda create -y -p conda_env_full_path -c conda-forge pip python=3.8 --override-channels --no-default-packages --no-pin -c pytorch'です。

ユーザー固有のConda環境の設定

Ambari UIを介してJupyterHubがインストールされていることを確認します。
クラスタにSSH接続し、/var/lib/ambari-server/resources/mpacks/odh-ambari-mpack-2.0.8/stacks/ODH/1.1.12/services/JUPYTER/package/scripts/にナビゲートします。
ご使用の環境に合わせて実行します。
```
sudo python/python3 kernel_install_script.py --conda_env_name conda_jupy_env_1 --conda_additional_configs '--override-channels --no-default-packages --no-pin -c pytorch' --custom_requirements_txt_file_path ./req.txt --kernel_type spark --kernel_name spark_bds_1 --user bds
```
このサンプル・スクリプトの実行では、指定されたパラメータを使用して、ユーザーbdsのconda環境conda_jupy_env_1を作成し、conda_jupy_env_1のカスタム依存関係をインストールし、spark_bds_1という名前のsparkカーネルを作成します。この操作が正常に完了すると、spark_bds_1カーネルがbdsユーザーのJupyterHub UIにのみ表示されます。

Load Balancerおよびバックエンド・セットの作成

バックエンド・セットの作成の詳細は、Load Balancerバックエンド・セットの作成を参照してください。

Load Balancerの作成

パブリックLoad Balancerの作成の詳細は、Load Balancerの作成を参照し、次の詳細を入力します。

ナビゲーション・メニューを開き、「ネットワーキング」をクリックして、「ロード・バランサ」をクリックします。「ロード・バランサ」をクリックします。「ロード・バランサ」ページが表示されます。
「リスト範囲」の下で、クラスタが配置されている「コンパートメント」を選択します。
「ロード・バランサ名」フィールドに、Load Balancerを識別する名前を入力します。例: JupyterHub-LoadBalancer
「表示タイプの選択」セクションで、「パブリック」を選択します。
「パブリックIPアドレスの割当て」セクションで、「予約済IPアドレス」を選択します。
「Create new reserved IP address」を選択します。
「パブリックIP名」フィールドに、名前を入力します。たとえば、jupyterhub-ip
「コンパートメントに作成」で、クラスタが存在するコンパートメントを選択します。
「ネットワーキングの選択」セクションで、次を完了します:
1. 「仮想クラウド・ネットワーク<Compartment>」セクションで、クラスタで使用されるVCNを選択します。
2. 「<Compartment>のサブネット」フィールドで、クラスタで使用されるサブネットを選択します。
「次へ」をクリックします「バックエンドの選択」ページが表示されます。
「ロード・バランシング・ポリシーの指定」で、「IPハッシュ」を選択します。

ノート

この時点ではバックエンドを追加しないでください。
「ヘルス・チェック・ポリシーの指定」セクションで、次の手順を実行します:
1. 「ポート」フィールドに、8000と入力します。
2. 「URLパス(URI)」に、//hub/apiと入力します。
「SSLの使用」を選択します。
「証明書リソース」セクションで、次を入力します:
1. ドロップダウンから「ロード・バランサ管理対象証明書」を選択します。
2. 「SSL証明書の貼付け」を選択します。
3. 「SSL証明書」フィールドで、証明書をコピーしてこのフィールドに直接貼り付けます。
4. 「CA証明書の貼付け」を選択します。
5. 「CA証明書」フィールドに、クラスタに存在する /etc/security/serverKeys/bdsOracleCA.crtを使用してOracle証明書を入力します。公開認証局(CA)の場合、この証明書はサイトから直接取得できます。
6. (オプション)「秘密キーの指定」を選択します。
  1. 「Paste private key」を選択します。
  2. 「秘密キー」フィールドで、秘密キーをこのフィールドに直接貼り付けます。
「拡張オプションの表示」をクリックして、他のオプションにアクセスします。
「バックエンド・セット」タブをクリックし、バックエンド・セット名を入力します。例: JupyterHub-Backends
「セッション永続性」をクリックし、「ロード・バランサCookieの永続性を有効化」を選択します。Cookieは自動生成されます。
「次へ」をクリックします「リスナーの構成」ページが表示されます。次を完了します:
1. 「リスナー名」フィールドに、リスナーの名前を入力します。例: JupyterHub-Listener
2. 「リスナーで処理するトラフィック・タイプの指定」で、「HTTPS」を選択します。
3. 「リスナーがイングレス・トラフィックをモニターするポートを指定します」フィールドに、8000と入力します。
4. 「SSL証明書の貼付け」を選択します。
5. 「SSL証明書」フィールドで、証明書をコピーしてこのフィールドに直接貼り付けます。
6. ドロップダウンから「ロード・バランサ管理対象証明書」を選択します。
7. 「CA証明書の貼付け」を選択します。
8. 「CA certificate」フィールドに、クラスタのCA certificateと入力します。
9. 「秘密キーの指定」を選択します。
  1. 「Paste private key」を選択します。
  2. 「秘密キー」フィールドで、秘密キーをこのフィールドに直接貼り付けます。
「次」をクリックし、「送信」をクリックします。

バックエンド・セットの構成

パブリックLoad Balancerの作成の詳細は、Load Balancerの作成を参照し、次の詳細を入力します。

ナビゲーション・メニューを開き、「ネットワーキング」をクリックして、「ロード・バランサ」をクリックします。「ロード・バランサ」をクリックします。「ロード・バランサ」ページが表示されます。
リストからコンパートメントを選択します。そのコンパートメント内のすべてのロード・バランサが表形式でリストされます。
バックエンドを追加するロード・バランサをクリックします。ロード・バランサの詳細ページが表示されます。
「バックエンド・セット」を選択し、「Load Balancerの作成」で作成したバックエンド・セットを選択します。
IPアドレスを選択し、クラスタの必要なプライベートIPアドレスを入力します。
「ポート」に8000と入力します。
「追加」をクリックします。

バックエンド・セットの構成

パブリックLoad Balancerの作成の詳細は、Load Balancerの作成を参照し、次の詳細を入力します。

ブラウザを開き、https://<loadbalancer ip>:8000と入力します。
リストからコンパートメントを選択します。そのコンパートメント内のすべてのロード・バランサが表形式でリストされます。
JupyterHubサーバーのいずれかにリダイレクトされることを確認してください。確認するには、JupyterHubでターミナル・セッションを開いて、到達したノードを見つけます。

制限事項

ノードの追加操作の後、クラスタ管理者は、新しく追加されたノードのLoad Balancerホスト・エントリを手動で更新する必要があります。クラスタへのすべてのノード追加に適用できます。たとえば、ワーカー・ノード、コンピュートのみおよびノードです。
証明書の有効期限が切れた場合は、手動でLoad Balancerに更新する必要があります。このステップにより、Load Balancerで古い証明書が使用されていないことが保証され、バックエンド・セットに対するヘルス・チェック/通信の失敗が回避されます。詳細は、「期限切れが近いLoad Balancer証明書の更新」を参照して、期限切れの証明書を更新します。

Trino-SQLカーネルの起動

JupyterHub PyTrinoカーネルは、JupySQLを使用してTrino問合せを実行できるSQLインタフェースを提供します。これは、ビッグ・データ・サービス3.0.28以降のODH 2.xクラスタで使用できます。

PyTrinoカーネルの起動とTrino問合せの実行

Trinoをインストールします。
Trinoコーディネータおよびポートを構成します。
1. Apache Ambariにアクセスします。
2. サイド・ツールバーの「Services」で、JupyterHubをクリックします。
3. 「Configs」、「Advanced」の順にクリックします。
4. 「Advanced Jupyterhub-trino-kernel-configs」セクションで、「Trino Coordinator Hostname」および「Trino Port」を構成します。
「保存」をクリックし、JupyterHubを再起動します。
JupyterHubにアクセスします。
ノートブック・サーバーを開きます。「Launcher」ページにリダイレクトされます。
PyTrinoカーネルをクリックします。

Trino問合せは、次の方法でPyTrinoカーネルで実行できます。

%sql <Trino-query>を使用してTrinoサンプル問合せを実行し、「実行」をクリックします。
例:
```
%sql select custkey, name, phone, acctbal from tpch.sf1.customer limit 10
```

問合せ結果の上にPythonロジックを記述できます。例:

result = %sql select custkey, name, phone, acctbal from tpch.sf1.customer limit 10

 
def classify_balance(acctbal):
    if acctbal < 1000:
        return 'Low'
    elif 1000 <= acctbal < 5000:
        return 'Medium'
    else:
        return 'High'
df = result.DataFrame()
df['balance_class'] = df['acctbal'].apply(classify_balance)
print(df)

複数行問合せの場合は、%%sqlを実行します。例:

# Using the %%sql magic command to execute a multi-line SQL query with the limit variable



top_threshold = 3
 
%%sql
SELECT custkey, name, acctbal
FROM tpch.sf1.customer
WHERE acctbal > 1000
ORDER BY acctbal DESC limit {{top_threshold}}

Trinoセッション・パラメータの設定

Trinoセッション・パラメータは、JupyterHub Ambari UIから構成できます。これらのセッション・パラメータは、すべてのユーザー・セッションに適用されます。

セッションパラメータの詳細は、Properties reference#を参照してください。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced」の順にクリックします。
「カスタムJupyterhub-trino-kernel-configs」セクションで、次のセッション・パラメータを追加します。
```
trino_session_params_<SESSION_PARAM> = <VALUE>
```
たとえば、 trino_session_params_query_max_planning_time = 1200mです。
(オプション)セッション・パラメータのリストを表示するには、次を実行します:
```
%sql SHOW session
```
現在のノートブック・セッションのパラメータを設定するには、 %sql SET SESSIONを実行します。次に例を示します:
```
%sql SET SESSION query_max_run_time='2h'
```

Trino外部資格証明パラメータの設定

オブジェクト・ストア・データへのアクセスに必要なTrino追加資格証明パラメータは、JupyterHub Ambari UIから構成できます。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced」の順にクリックします。
「カスタムJupyterhub-trino-kernel-configs」セクションで、次の追加の資格証明パラメータを追加します。
```
trino_extra_credentials_<BDS_OSS_CLIENT_PARAM> = <VALUE>
```
たとえば、trino_extra_credentials_BDS_OSS_CLIENT_REGION = us-region-1です。

SqlMagicパラメータの設定

SqlMagic構成では、Jupyterノートブックで実行されるSQL操作の動作および外観を柔軟に制御できます。これらのパラメータは、JupyterHub Ambari UIから構成し、すべてのユーザー・セッションに適用できます。

SqlMagicパラメータの詳細は、https://jupysql.ploomber.io/en/latest/api/configuration.html#changing-configurationを参照してください。

Apache Ambariにアクセスします。
サイド・ツールバーの「Services」で、JupyterHubをクリックします。
「Configs」、「Advanced」の順にクリックします。
「カスタムJupyterhub-sql-magic-configs」セクションで、次のMagicalパラメータを追加します。
SqlMagic.<PARAM> = <VALUE>
例:
```
SqlMagic.displaycon = False
```
SqlMagicパラメータのリストを取得するには、次を実行します:
```
%config SqlMagic
```
(オプション)現在のノートブック・セッションにのみSqlMagicパラメータを設定できます。
例:
```
%config SqlMagic.displaycon=False
```

Oracle Cloud Infrastructureドキュメント

ビッグ・データ・サービス3.0.27以降でのJupyterHubの使用

前提条件

JupyterHubへのアクセス

ノートブックの生成

HAクラスタでのノートブックの生成

非HAクラスタでのノートブックの生成

JupyterHubの管理

ユーザーおよび権限の管理

前提条件

サポートされる認証タイプ

Ambariを使用したLDAP認証の使用

ノートブックの生成

HAクラスタでのノートブックの生成

非HAクラスタでのノートブックの生成

SSHキー・ペアの生成

アクセス・トークンの使用

Gitでの永続性モードの選択

rcloneとユーザー・プリンシパル認証を使用したOracle Object Storageバケットのマウント

JupyterHubでのConda環境の管理

前提条件

カスタマイズに使用可能な構成

ユーザー固有のConda環境の設定

Load Balancerおよびバックエンド・セットの作成

Trino-SQLカーネルの起動

`rclone`とユーザー・プリンシパル認証を使用したOracle Object Storageバケットのマウント