リソースをプロジェクトに移動または移行する方法

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

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

用語

• ホーム プロジェクト：これは通常、リソースが作成されたプロジェクトを指します。この移行ガイドでは、リソースを追加または移動するプロジェクトを指します。このプロジェクトがこれらのリソースの「ホーム プロジェクト」になります。リソースが属するホーム プロジェクトは 1 つのみですが、カタログを組織内の他のプロジェクトと共有することで、複数のユースケースで再利用できます。カタログのストレージはホーム プロジェクトに記録され、カタログを使用するためのデータ I/O はカタログを使用するプロジェクトに記録されます。
• リソースの追加と移動の違い：このガイドでは、プロジェクトへのカタログの追加について言及しています。これは、カタログがプロジェクトに追加されるものの、プロジェクトのコンテキスト外でカタログに関連付けられている権限は削除されないことを意味します。これらの権限を後で削除して、プロジェクト内のリソースを純粋に管理することもできます。一方で、カタログをプロジェクトに完全に「移動」するのではなく「追加」することで、ユースケースをプロジェクトに移行する際のエラーのリスクを軽減できます。パイプラインの場合、このガイドでは、パイプラインの追加ではなく移動を指します。つまり、移動したパイプラインはプロジェクト コンテキスト外でアクセスできなくなります。

ステップ 1 - ユースケースのプロジェクトを作成する

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

プラットフォームで[プロジェクトマネージャー]を使用してプロジェクトを作成するには、次の手順を実行します。

1. HEREプラットフォームにサインインします。
2. ランチャーから[プロジェクトマネージャー]を選択します。
3. [新しいプロジェクトを作成] をクリックします。
4. プロジェクトの名前を入力します (プロジェクト名は一意である必要はありません)。
5. プロジェクト ID を入力します。プロジェクト ID は組織と一意である必要があり、組織の存続期間中は変更できません。プロジェクト ID は 4 ～ 16 文字の範囲で指定する必要があります。
6. 必要に応じて説明を入力します。
7. [保存]をクリックします。

ステップ 2 - HERE カタログをプロジェクトにリンクする

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

🚧

注

「HEREビジュアル化に最適化した地図Plus」カタログ (hrn:here:data::olp-here:here-optimized-map-for-visualization-plus-2) をプロジェクトにリンクすると、データインスペクターが引き続きシームレスに機能します。これにより、プロジェクト内のカタログのレイヤーを視覚的に検査できます (データインスペクターではビジュアル化に最適化した地図を使用して背景マップを提供します)。

HEREプラットフォームからHEREカタログをリンクするには、次の手順を実行します。

1. HEREプラットフォームにサインインします。
2. ランチャから[プロジェクトマネージャー]を選択します。
3. カタログを追加するプロジェクトをクリックして [リソース] タブを選択します。
4. [Add catalog](カタログを追加) をクリックし、[Link a catalog](カタログをリンク) を選択します。
5. 表示されたリストから、リンクするカタログを選択します。

ステップ 3 - CLI を使用してプロジェクトに入出力カタログとスキーマを追加する

入出力カタログとスキーマをプロジェクトに追加できます。

🚧

注意

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

resource project add CLIコマンドを使用して、ステップ1で作成したプロジェクトに入出力カタログとスキーマを追加します。 現在これらのカタログを使用しているパイプラインは引き続き実行されるため、プロジェクト外の権限は影響を受けません。 カタログに関連付けられたスキーマへのアクセス権は、追加の作業を行うことなくプロジェクト スコープで使用できます。ただし、olp resource project addCLIコマンドを使用して、作成したスキーマをプロジェクトに追加することもできます。

プロジェクト外カタログとスキーマの削除方法

誤ってプロジェクトの外部にカタログまたはスキーマを作成した場合は、olp resource project remove CLIコマンドで削除できます。プロジェクトから削除される前にカタログまたはスキーマが他のプロジェクトと共有されている場合、この操作によって他のプロジェクトで使用できなくなります。カタログまたはスキーマが共有されていて、ホームプロジェクトから削除される前に別のプロジェクトにもリンクされている場合、この操作によってそれらのリンクは無効になります。

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

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

📘

注

パイプラインバージョンの実行ユーザーID (ランタイム資格情報) をプロジェクトのメンバーとして追加します。

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

必要に応じて実行ユーザー ID (ランタイム資格情報) でカタログへのアクセスを制限します (任意)。ただし、入力カタログからの読み取りと出力カタログへの書き込みに必要な最小限の権限があることを確認してください。

プロジェクトにメンバーを追加するには、次の手順を実行します。

1. HERE プラットフォームにサインインします。
2. [プロジェクトマネージャー]で、ユーザー、グループ、アプリにアクセス権を付与するプロジェクトをクリックします。
3. [アクセス権と権限]タブを選択すると、プロジェクトにアクセスできるユーザー、グループ、アプリのリストが表示されます。
4. [Grant access](アクセス権を付与) をクリックします。
5. ユーザー、グループ、アプリ タイプから選択します。
6. 検索フィールドに名前を入力して、目的のユーザー、グループ、アプリを名前で検索します。
7. 目的の名前を選択し、[Grant access](アクセス権を付与) をクリックします。これで名前が表示されます。

ステップ 5 - パイプラインと関連するパイプライン テンプレートをプロジェクトに移動する

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

📘

移動前からプロジェクト外のカタログに対する既存の権限を使用して、実行ユーザーID (ランタイム資格情報) でパイプラインジョブの実行が続行されます。パイプライン ジョブが想定どおりに実行されていることを確認します。パイプラインを新しいジョブで再デプロイして、プロジェクト スコープで実行ユーザー ID (ランタイム資格情報) とカタログを使用するように切り替え、プロジェクト スコープでの使用状況を報告する必要があります。再デプロイするには、実行中のパイプライン バージョンを一時停止するか再開します。保持する処理状態がない場合は、パイプラインバージョンの無効化と有効化を行うこともできます。

パイプラインをプロジェクトに移動するには、次の手順を実行します。

1. まず、移動するパイプラインに関連付けられているパイプライン バージョンをチェックして、直近 5 個 (サポートされている最大数) かそれ未満を移動するかを判断します。olp pipeline version list CLI コマンドを使用してこのチェックを実行できます。
2. 次に、必要なパイプライン バージョンで使用するパイプライン テンプレートが他のパイプラインで使用されているかどうかを確認します。olp pipeline move CLI コマンドの --report パラメーターを使用します。使用されている場合は、このパイプラインまたは他のパイプラインで使用するために別のパイプライン テンプレートを作成します。

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

📘

注

olp pipeline move コマンドを実行すると、プロジェクト コンテキスト外でパイプラインに関連付けられていたグループに割り当てられているアクセス許可が取り消されます。プロジェクト内の権限に影響はありません。これにより、プロジェクトを介してのみパイプラインにアクセスできるようになります。

移動に含まれていなかったパイプラインバージョンは、関連付けられたテンプレートが移動されなかったため、移動後に再有効化できません。

間違えた場合olp pipeline move CLIコマンドの--revert-to-groupパラメーターのロールバックオプションを使用して、パイプライン、パイプラインバージョン、関連するパイプラインテンプレートをプロジェクトから削除します。次に、それらを移行前に配置されていたグループに追加します。

ロールバック オプションは、次のいずれかの文が真の場合には使用できません。

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

ステップ 6 - プロジェクトにバッチ パイプラインを再作成する - ステップ 5 の代替

バッチパイプラインの場合は、パイプラインをすぐに実行するか、入力カタログデータが更新されたときに実行するようにスケジューリングするかを選択できます。

CLIかプラットフォームポータルを使用して、プロジェクトにバッチパイプライン (パイプラインテンプレート、パイプライン、最初のパイプラインバージョンを含む) を再作成できます。インターフェースにかかわらず、必ずプロジェクトスコープを指定してください。プラットフォーム ポータルを使用し、[プロジェクトマネージャー]ではなく[パイプライン]タブを使用する場合は、ドロップダウンメニューでプロジェクトが選択されていることを確認します。

ステップ 7 - プロジェクト外のバッチ パイプライン バージョンをキャンセルする - ステップ 5 の代替

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

ステップ 8 - プロジェクト内のバッチ パイプライン バージョンを有効にする - ステップ 5 の代替

ステップ 7 のキャンセルが完了していることを確認してから、olp activate pipeline version CLI コマンドかプラットフォーム ポータルを使用してプロジェクト内のパイプライン バージョンを有効にします。

ステップ 9 - プロジェクト コンテキストで動作するように自動デプロイを更新する

リソースへの自動デプロイ アクセスを更新して、新しいプロジェクトのコンテキストに含めるには、資格情報ファイルの here.token.scope オプション パラメーターで CLI コマンドを使用して --scope パラメーターでプロジェクトを指定するか、olp app scope CLI コマンドを使用してアプリのデフォルト プロジェクトを指定します。

スコープを指定するこれら 3 つの方法が「スコープ」セクションで解決される順序について詳しくは、「資格情報を設定する」セクションを参照してください。

ステップ 10 - 任意 - プロジェクト コンテキスト外のカタログへのアクセス権を削除する

ユースケースがプロジェクト内で機能していることを確認したら、必要に応じてプロジェクト コンテキスト外のカタログへのアクセス権を削除できます。これにより、これらのカタログへのアクセス権がプロジェクトのコンテキスト内でのみ管理されるようになります。

プロジェクト外のカタログの権限を削除するには、olp catalog permission list と olp catalog permission revoke の CLI コマンドを使用します。