移行ガイド

はじめに

HERE platform プロジェクトは、プラットフォームリソースへのアクセスをグループ化および管理できるようにする、組織固有のリソースコンテナです。 プロジェクトを使用すると、プラットフォームポータルとコマンド ライン インターフェース（ CLI ）の両方を使用して、アクセス制御の管理やリソース使用量の追跡を簡単に行うことができます。

すべてのプラットフォームリソースを管理するには、プロジェクトを使用することをお勧めします。 このガイドでは、カタログ、スキーマ、パイプライン、関連するパイプラインテンプレートなどのユースケースのリソースを、元々プラットフォームプロジェクトで作成されていない場合にプラットフォームプロジェクトに移行するための、 CLI ベースの主な手順について説明します。 ユースケースのカタログがプロジェクトに追加された後も、組織内のすべてのプロジェクトまたは特定のプロジェクトとカタログを共有して、他のユースケースで再利用できます。

用語集

ホームプロジェクト: これは通常、リソースが作成されたプロジェクトを意味します。 この移行ガイドでは、リソースを追加または移動するプロジェクトを意味します。 このプロジェクトは、これらのリソースの「ホームプロジェクト」になります。 1 つのリソースには 1 つのホームプロジェクトのみを含めることができますが、カタログは組織内の他のプロジェクトと共有できるため、複数のユースケースで再利用できます。 カタログのストレージがホームプロジェクトに記録され、カタログを使用するためのデータ I/O が、カタログを使用しているプロジェクトに記録されます。

リソースの追加と移動: このガイドでは、プロジェクトへのカタログの追加について説明します。 つまり、カタログをプロジェクトに追加しようとしていますが、プロジェクトのコンテキスト外でカタログに関連付けられている権限は削除されません。 後でこれらの権限を削除して、プロジェクト内のリソースのみを管理することもできますが、カタログをプロジェクトに完全に「移動」するのではなく、「追加」することで、ユースケースをプロジェクトに移行する際に、すべての内容が壊れるリスクを軽減できます。 パイプラインを使用する場合、ガイドでは、パイプラインを追加するのではなく、移動することを指します。つまり、移動したパイプラインは、プロジェクトのコンテキスト外ではアクセスできなくなります。

移行手順

ステップ 1 ： ユースケースのプロジェクトを作成します

プラットフォームポータル プロジェクトマネージャー または olp project create CLI コマンドを使用してプロジェクトを作成します。

ユースケースで使用されているすべての HERE カタログを、プラットフォームポータル olp project resource link availability listolp project resources link または CLI コマンドを使用してステップ 1 で作成したプロジェクトにリンクします。

プラットフォームポータルから HERE カタログをリンクするに は、プロジェクトマネージャーに移動し、カタログを追加するプロジェクトをクリックして、 [ リソース ] タブを選択します。 [ カタログを追加 ] をクリックし 、カタログのリンクを選択します。 使用可能な HERE カタログのリストが表示されます。

重要 : 「 HERE Optimized Map for Visualization Plus 」カタログ (hrn: here::data::olp-here: here-optimized-map-for-visualization-2) をプロジェクトにリンク して、データ インスペクターがシームレスに動作し続けるようにします。 これにより、プロジェクト内のカタログのレイヤーを視覚的に検査できます ( データ インスペクターでは、 Optimized Map for Visualization を使用して背景マップを提供します ) 。

ステップ 3 ： CLI を使用して、入力および出力のカタログおよびスキーマをプロジェクトに追加します

重要 : プロジェクトにカタログを追加する前に、少なくとも 1 つのアプリが入力および出力カタログへのアクセス権を管理していることを確認してください。これにより、プロジェクト外で引き続きアクセス権を管理できます。 プロジェクトにカタログを追加すると、ポータルを介してプロジェクト外でカタログへのアクセスを管理することはできなくなりますが、 CLI を介して引き続き管理できます。この場合、アプリの認証が必要になります。

olp resource project add ステップ 1 で作成したプロジェクトに入力および出力カタログを追加するには、 [ 追加（ CLI ） ] コマンドを使用します。

プロジェクト外の権限には影響がありません。つまり、これらのカタログを使用するパイプラインは引き続き実行されます。

カタログに関連付けられているスキーマへのアクセスは、追加の作業を行うことなく、プロジェクト範囲で利用できます。 ただし olp resource project add 、 CLI コマンドを使用して、作成したスキーマをプロジェクトに追加することもできます。

間違えた場合はどうすればよいですか？ プロジェクト外で作成されたカタログおよびスキーマは、プロセスのこのステップで誤りを修正できるように、プロジェクトから削除できます。 olp resource project remove CLI コマンドを使用するだけです。 カタログまたはスキーマがプロジェクトから削除される前に他のプロジェクトと共有されている場合、このアクションによって他のプロジェクトに対する可用性が削除されます。 カタログまたはスキーマが共有され、ホームプロジェクトから削除される前に別のプロジェクトにもリンクされている場合、この操作によってそれらのリンクが削除されます。

ステップ 4 ： プロジェクトにメンバーを追加し、プロジェクトリソースへのアクセス権を管理します

olp project access grant CLI コマンドまたはプラットフォームポータルを使用して、メンバー（ユーザー、グループ、アプリ）をプロジェクトに追加します。

プラットフォームポータルを使用してプロジェクトにメンバーを追加するには、次の手順を実行します。

  1. プロジェクトマネージャーで、ユーザー、グループ、またはアプリのアクセス権を付与するプロジェクトをクリックします。
  2. [ アクセスと権限 ] タブを選択して、プロジェクトへのアクセス権を持つユーザー、グループ、およびアプリのリストを表示します。
  3. [ アクセス権を付与] をクリックし
  4. ユーザー、グループ、またはアプリタイプから選択します。
  5. 検索フィールドに名前を入力して、目的のユーザー、グループ、またはアプリを名前で検索します。
  6. 目的の名前を選択し 、 [ アクセス権を付与] をクリックします。 名前が一覧表示されます。

重要 : パイプラインバージョンの Run-As ID ( ランタイム資格情報 ) をプロジェクトのメンバーとして追加します。

既定では、プロジェクト内のすべてのリソースへのフルアクセス権がこれらのプロジェクトメンバーに付与されます。 CLI を使用して既存の HERE またはカスタム作成のポリシーを適用することで、プロジェクトメンバーによるリソースへのアクセスを制限することもできます。CLI プロジェクトワークフロー では、プロジェクトポリシーを使用してプロジェクトリソースへの詳細なアクセスを設定する方法について説明します。 プロジェクトポリシーコマンド を使用すると、カスタムポリシーを作成および管理できます。

必要に応じて Run-As ID ( ランタイム資格情報 ) によってカタログへのアクセスを制限しますが ( 任意 ) 、入力カタログからの読み取りおよび出力カタログへの書き込みに必要な最小限の権限を持っていることを確認してください。

このステップでは、プロジェクトの外部で作成されたパイプラインをプロジェクトに移動する方法について説明します。 バッチパイプラインの場合は、以下の手順 6 ～ 8 で説明するように、パイプラインを再作成し、プロジェクト外のバージョンをキャンセルしてから、プロジェクト内のバージョンをアクティブ化することをお勧めします。

まず、移動するパイプラインに関連付けられているパイプラインのバージョンを確認して、最新の 5 つ ( サポートされている最大数 ) 以下のバージョンを移動する必要があるかどうかを判断します。 olp pipeline version list この確認は、 [ 検索（ CLI ） ] コマンドを使用して行うことができます。

次に、必要なパイプラインバージョンで使用されているパイプラインテンプレートを他のパイプラインが使用しているかどうかを確認します。 --reportolp pipeline move CLI コマンドのパラメータを使用します。 存在する場合 は、このパイプラインまたは他のパイプラインで使用するために、別々のパイプラインテンプレートを作成します。

これで olp pipeline move 、 CLI コマンドを使用して、パイプライン、指定したパイプラインバージョン、および関連付けられているパイプラインテンプレートをプロジェクトに移動する準備ができました。

重要 : パイプラインジョブは、移動前からプロジェクト外のカタログに対する既存の権限を使用して、 Run-As ID ( ランタイム資格情報 ) で引き続き実行されます。 パイプラインジョブが期待どおりに実行されていることを確認します。 パイプラインを新しいジョブで再展開して、プロジェクト範囲で Run-As ID ( ランタイム資格情報 ) およびカタログを使用するように切り替え、プロジェクト範囲での使用状況をレポートする必要があります。 再展開するには、実行中のパイプラインバージョンを一時停止して再開します。 保持する処理状態がない場合は、パイプラインバージョンを非アクティブ化およびアクティブ化することもできます。

注 : olp pipeline move このコマンドは、プロジェクトコンテキスト外でパイプラインに関連付けられているグループに割り当てられている権限を削除します。この権限は、プロジェクト内の権限に影響を与えることはありません。 これは、プロジェクト経由でのみパイプラインにアクセスできるようになったことを意味します。

移動に含まれていなかったパイプラインバージョンは、関連付けられているテンプレートが移動されなかったため、移動後に再度アクティブ化することはできません。

間違えた場合はどうすればよいですか？ --revert-to-groupolp pipeline move CLI コマンドのパラメーターを使用して、プロジェクトからパイプライン、パイプラインバージョン、および関連するパイプラインテンプレートを削除し、それらのテンプレートを移行前のグループに再度追加します。 次のいずれかに該当する場合、ロールバックオプションは使用できません。

  • 移行後 5 日以上経過しました。
  • 元のグループが削除されました。
  • 1 つ以上の新しいパイプラインテンプレートが作成され、移動後に新しいパイプラインバージョンに関連付けられました。
  • 1 つ以上の移動したパイプラインテンプレートが移動後に削除されました。
  • 1 つ以上の関連するパイプラインテンプレートが共有されているか、他のプロジェクトとリンクされています。
  • 1 つ以上の関連するパイプラインテンプレートが、同じプロジェクト内の別のパイプラインのバージョンによって参照されています。

ステップ 6 ： バッチパイプラインをプロジェクトに再作成します ( 手順 5 の代わり )

CLI または プラットフォームポータルを使用して、プロジェクト内のバッチパイプライン（パイプライン テンプレート、パイプライン、および最初のパイプラインバージョンを含む）を再作成します。 インターフェイスに関係なく、プロジェクトの範囲を指定してください。 プラットフォームポータルを使用し、プロジェクトマネージャーではなくパイプラインタブを使用する場合は、画面右上のドロップダウンメニューでプロジェクトが選択されていることを確認してください。

ステップ 7 ： プロジェクト外のバッチ パイプラインバージョンをキャンセルします ( 手順 5 の代わり )

プロジェクト外のパイプラインバージョンをキャンセル するには、olp pipeline version cancel CLI コマンドまたはプラットフォームポータルを使用します。

ステップ 8 ： プロジェクトのバッチ パイプラインバージョンをアクティブ化します ( 手順 5 の代わり )

手順 7 のキャンセルが完了 したことを確認してから、olp activate pipeline version CLI コマンドまたはプラットフォームポータルを使用してプロジェクトのパイプラインバージョンをアクティブ化します。

ステップ 9 ： 自動化された展開を更新して、プロジェクトのコンテキストで作業できるようにします

--scope CLI コマンドを使用してパラメーターでプロジェクトを指定 here.token.scope するか、資格情報ファイルのオプションのパラメーターでプロジェクトを指定するか olp app scope 、または CLI コマンドを使用してアプリの既定のプロジェクトを指定することで、新しいプロジェクトのコンテキストになるようにリソースへの自動デプロイメントアクセスを更新します。 これら 3 つのスコープ指定メソッドが解決される順序については 、「 Scopes 」セクション HERE を参照してください。

ステップ 10 ： プロジェクトコンテキスト外のカタログへのアクセス権を削除します ( オプション )

ユースケースがプロジェクト内で動作していることを確認したら、プロジェクトコンテキスト外のカタログへのアクセス権を削除することを選択できます。 これにより、これらのカタログへのアクセスがプロジェクトのコンテキスト内でのみ管理されるようになります。 プロジェクト外のカタログの権限を削除するに olp catalog permission listolp catalog permission revoke は、および CLI コマンドを使用します。

「」に一致する結果は 件です

    「」に一致する結果はありません