重要
Realm CLI は非推奨
realm-cli は非推奨であり、将来の機能やバグ修正は行われません。 代わりに、 App Services CLI を使用してください。
App Services CLI は npm で利用できます。システムに CLI をインストールするには、Node.js があることを確認してくださいがインストールされたら、 シェルで次のコマンドを実行します。
npm install -g atlas-app-services-cli
Overview
Atlas App Services コマンドラインインターフェイス( realm-cli )を使用すると、アプリをプログラムで管理できます。 realm-cliを使用すると、ローカル ディレクトリからアプリを作成またはアップデートしたり、既存のアプリケーションをローカル ディレクトリにエクスポートしたりできます。
インストール
realm-cli は npm で利用可能です。システムに realm-cli のバージョン 1 をインストールするには、Node.jsがインストールされていることを確認し、 シェルで次のコマンドを実行します。
npm install -g mongodb-realm-cli@^1
一般オプション
重要
CLI のバージョンを確認する
このページでは、 realm-cliのバージョン 1 のコマンド、引数、フラグについて説明します。 realm-cliの新しいバージョンをお持ちの場合は、更新されたコマンドと使用例のリストについては、 realm-cli --helpを実行してください。 CLI バージョンを確認するには、 realm-cli --versionを使用します。
次のオプションはすべてのrealm-cliコマンドで使用できます。
--config-path <File System Path>- Optional.
realm-cli loginに含まれている場合、 は認証されたセッションに関する情報を指定されたパスのファイルに保存します。 セッション情報には、MongoDB Cloud ユーザー名、 MongoDB Atlas プログラム API キー、およびセッション更新トークンが含まれます。他のコマンドに含まれている場合、 は、現在の CLI 認証状態ではなく、指定されたパスに保存されたセッション(存在する場合)でリクエストを認証します。
警告
セッション構成ファイルには MongoDB Atlas プログラム API 秘密キーが含まれているため、このファイルを意図せず共有するのは避ける必要があります。
認証
CLI ユーザーの認証
MongoDB Atlas プログラム API キーで MongoDB Cloud ユーザーを認証するには、 realm-cli loginを使用します。
realm-cli login --api-key="<my api key>" --private-api-key="<my private api key>"
--api-key <api key>ログインする MongoDB Cloud アカウントの有効な公開 MongoDB Atlasプログラム API キー。
--private-api-key <private api key>ログインする MongoDB Cloud アカウントの有効なプライベート MongoDB Atlasプログラム API キー。
現在の CLI ユーザーのログアウト
現在ログインしているユーザーをログアウトするには、 realm-cli logoutを使用します。
realm-cli logout
現在ログインしているユーザーの表示
現在 CLI にログインしているユーザーの詳細を表示するには、 realm-cli whoamiを使用します(該当する場合)。
realm-cli whoami
現在ログインしているユーザーが存在する場合、その情報は次の形式の次の行に表示されます。
<username> [API Key: ********-****-****-****-<last 12 digits of API key>]
ログインしているユーザーがいない場合、 realm-cliは次のメッセージを返します。
no user info available
アプリ
アプリケーションのインポート
ローカル アプリケーション ディレクトリをホスト型アプリにインポートするには、 realm-cli importを使用します。 存在しないアプリケーションにディレクトリをインポートすると、 realm-cliはアプリケーションを作成できます。
Tip
アプリをインポートするには、 Project Ownerである必要があります。 詳しくは、「 Atlas userロール 」を参照してください。
realm-cli import \ --app-id=myapp-abcde \ --path=./path/to/app/dir \ --strategy=merge \ --include-hosting \ --include-dependencies
--app-id <App Services Application ID>- Optional.
アプリのアプリケーションID。
指定しない場合、
realm-cliはconfig.jsonで定義されているapp_idの値を使用しようとします。config.jsonにapp_id値がない場合、realm-cliは新しいアプリケーションを作成するように要求します。注意
新しいアプリケーション・アプリID
realm-cliを使用して新しいアプリケーションを作成すると、App Services は新しいアプリ ID を生成し、--app-idフラグに指定した値を無視します。
--path <path>- Optional.
The path to the directory containing files you wish to import. ディレクトリには少なくとも有効なconfig.jsonファイルが含まれている必要があります。
path引数が省略されている場合、realm-cliは現在のアプリケーション ディレクトリでconfig.jsonファイルを検索します。
--strategy ['merge|replace|replace-by-name']- Optional.Default: Merge
インポートされたエンティティを調整するときに
realm-cliが使用する必要があるインポート戦略。
--project-id <MongoDB Cloud Project ID>- Optional.
新しく作成したアプリをホストするAtlas プロジェクトの Project ID 。 指定すると、
realm-cliでは新しいアプリの作成時にプロジェクトを選択するよう求められません。注意
realm-cliは、新しいアプリケーションをインポートしない限り、--project-idの値を無視します。
アプリケーションのエクスポート
アプリ構成をローカル アプリケーション ディレクトリに保存するには、 realm-cli exportを使用します。
realm-cli export \ --app-id=myRealmApp-abcde \ --output=path/to/exported/app/dir \ --include-hosting \ --as-template
--output <path>- Optional.
App Services がアプリケーションをエクスポートするディレクトリのパス。
この場合、
realm-cliは指定されたパスにディレクトリを作成し、アプリケーション構成を新しいディレクトリにエクスポートします。 指定したパスにファイルまたはディレクトリがすでに存在する場合、エクスポートは失敗します。注意
output引数が省略されている場合、realm-cliは現在の作業ディレクトリ内の新しいディレクトリにアプリケーション構成をエクスポートします。
保留中のアプリケーションの変更と差分
配置されたアプリケーションとローカル アプリケーション ディレクトリ間の構成ファイルの差を返すには、 realm-cli diffを使用します。
Diff application config files realm-cli diff Diff application config files and hosted files realm-cli diff --include-hosting
差は次のようになります。
--- functions/oldFunctionName/config.json +++ functions/oldFunctionName/config.json @@ -1,6 +1 @@ -{ - "id": "5d4c6a5cd28e555496a705da", - "name": "oldFunctionName", - "private": false -} --- functions/newFunctionName/config.json +++ functions/newFunctionName/config.json @@ -1 +1,6 @@ +{ + "id": "5d4c6a5cd28e555496a705da", + "name": "newFunctionName", + "private": false +} Modified Files: * /index.html * /auth/confirmEmail.html * /auth/resetPassword.html
シークレット
すべてのシークレットを一覧表示する
アプリケーション内の各シークレットの名前と ID を含むリストを返すには、 realm-cli secrets listを使用します。
realm-cli secrets list
返されるシークレットのリストは次のようになります。
ID Name 5d5c25415e30c7ef857c6a10 test-secret-please-ignore 5d56dd453b467e2a48a6ec32 some-other-secret
シークレットを作成する
realm-cli secrets addを使用して、指定された名前と値を持つ新しいシークレットを作成します。
realm-cli secrets add --name=mySecret --value=SuperSecretValue!
シークレットの値を更新
アプリケーション内の既存のシークレットの値を変更するには、 realm-cli secrets updateを使用します。
Update a Secret by name realm-cli secrets update --secret-name=mySecret --value=NewSecretValue realm-cli secrets update --name=mySecret --value=NewSecretValue Update a Secret by name realm-cli secrets update --secret-id=5ba9c5c2e707c02b38031412 --value=NewSecretValue realm-cli secrets update --id=5ba9c5c2e707c02b38031412 --value=NewSecretValue
シークレットを削除する
アプリケーションから既存のシークレットを削除するには、 realm-cli secrets removeを使用します。
Remove a Secret by name realm-cli secrets remove --secret-name=mySecret realm-cli secrets remove --name=mySecret Remove a Secret by ID realm-cli secrets remove --secret-id=5ba9c5c2e707c02b38031412 realm-cli secrets remove --id=5ba9c5c2e707c02b38031412
インポート戦略
アプリケーションのインポートを実行する際、既存のエンティティを処理するための複数の組み込み戦略があります。
すべてのインポートは、特に指定がない限り、デフォルトでmerge戦略になります。
merge
realm-cli import --strategy=merge
merge戦略では、アプリケーション ディレクトリ内のエンティティは非破壊的にアプリケーションに追加されます。 アプリケーション内の既存のエンティティは、インポートされたアプリケーション ディレクトリに表現されていない場合は変更されません。
インポートされたエンティティのid値が既存のエンティティのidと一致する場合、既存のエンティティはインポートされたエンティティと一致するように更新されます。 App Services は、 id値がないエンティティに、新しいエンティティとしてインポートする前に、システムによって生成されたid値を割り当てます。
既存のエンティティと一致しないidを使用してエンティティをインポートすると、インポートは失敗します。 非 ObjectID id値を持つエンティティをインポートすると、エラーが発生します。
注意
インポートされたエンティティに id フィールドがある場合、値はObjectIdである必要があります。そうでない場合、マージは失敗します。
例
既存のアプリケーションには、次の 3 つの機能があります。
{ "id": <ObjectID 1>, "name": "FunctionA", ... } { "id": <ObjectID 2>, "name": "FunctionB", ... } { "id": <ObjectID 3>, "name": "FunctionC", ... }
merge
strategy.{ "id": <ObjectID 1>, "name": "FunctionA_Updated!", ... } { "name": "FunctionD", ... }
インポート後、アプリケーションは次の機能を持ちます。
{ "id": <ObjectID 1>, "name": "FunctionA_Updated!" } { "id": <ObjectID 2>, "name": "FunctionB", ... } { "id": <ObjectID 3>, "name": "FunctionC", ... } { "id": <ObjectID 4>, "name": "FunctionD", ... }
FunctionA は、インポートされた構成ファイルに基づいてアップデートされました。 FunctionBとFunctionCはインポートされたアプリケーション ディレクトリに含まれていなかったため、 merge戦略でインポートした後も変更されていません。 FunctionDは新しいエンティティとしてインポートされ、システムによって生成されたid値が割り当てられました。
置換
realm-cli import --strategy=replace
replace戦略では、インポートされたエンティティのid値が既存のエンティティのidと一致する場合、App Services は既存のエンティティをインポートされたエンティティに置き換えます。 インポートされたエンティティのid値が既存のエンティティと一致しない場合、インポートは失敗します。 既存エンティティのidがインポートされたエンティティのidと一致しない場合、App Services はその既存のエンティティを削除します。
App Services は、 id値を持たないエンティティに対して、新しいエンティティとしてインポートする前にid値を生成します。 非 ObjectID id値を持つエンティティをインポートしても、エラーはスローされません。
例
既存のアプリケーションには、次の 3 つの機能があります。
{ "id": <ObjectID 1>, "name": "FunctionA", ... } { "id": <ObjectID 2>, "name": "FunctionB", ... } { "id": <ObjectID 3>, "name": "FunctionC", ... }
replace
strategy.{ "id": <ObjectID 1>, "name": "FunctionA_Updated!", ... } { "name": "FunctionD", ... } { "id": "non-ObjectID-value", "name": "FunctionE", ... }
インポート後、アプリケーションは次の機能を持ちます。
{ "id": <ObjectID 1>, "name": "FunctionA_Updated!" } { "id": <ObjectID 4>, "name": "FunctionD", ... } { "id": <ObjectID 5>, "name": "FunctionE", ... }
FunctionA は、インポートされた構成ファイルに基づいてアップデートされました。 FunctionBとFunctionCはインポートされたアプリケーション ディレクトリに含まれていなかったため、 replace戦略でインポートした後はアプリに存在しません。 FunctionDとFunctionEは新しいエンティティとしてインポートされ、システムによって生成されたid値が割り当てられました。
名前を使用して置換
realm-cli import --strategy=replace-by-name
replace-by-name戦略では、インポートされたエンティティのname値が既存のエンティティのnameと一致する場合、App Services は既存のエンティティをインポートされたエンティティに置き換えます。 インポートされたエンティティのname値が既存のエンティティと一致しない場合、そのエンティティは新しいエンティティになります。 既存エンティティのnameがインポートされたエンティティのnameと一致しない場合、App Services はその既存のエンティティを削除します。
インポートされたエンティティにname値がない場合、 realm-cliはエラーをスローします。
例
既存のアプリケーションには、次の 3 つの機能があります。
{ "id": <ObjectID 1>, "name": "FunctionA", ... } { "id": <ObjectID 2>, "name": "FunctionB", ... } { "id": <ObjectID 3>, "name": "FunctionC", ... }
replace
strategy.{ "name": "FunctionZ", ... } { "name": "FunctionB", ... } { "name": "FunctionC", ... }
インポート後、アプリケーションは次の機能を持ちます。
{ "id": <ObjectID 2>, "name": "FunctionB", ... } { "id": <ObjectID 3>, "name": "FunctionC", ... } { "id": <ObjectID 4>, "name": "FunctionZ", ... }
既存のアプリケーションとインポートされた構成ディレクトリの両方に、 FunctionBとFunctionCという名前の関数が含まれていました。 その結果、両方の関数は以前のid値と名前を保持しました。 両方の関数の値の残りの部分は、構成ファイルからアップロードされた値を反映します。 FunctionAはインポートされたアプリケーション ディレクトリに含まれていなかったため、 replace-by-name戦略でインポートした後のアプリには存在しません。 FunctionZは新しいエンティティとしてインポートされ、システムによって生成されたid値が割り当てられました。