realm-cli
v1 [非推奨]
項目一覧
重要
Realm CLI は非推奨
realm-cli
は非推奨であり、将来の機能やバグ修正は行われません。 代わりに、 App Services CLI を使用してください。
App Services CLI はnpm
で利用できます。 システムに CLI をインストールするには、 Node.js があることを確認してくださいがインストールされたら、shell で次のコマンドを実行します。
npm install -g atlas-app-services-cli
Overview
Atlas App Services コマンドラインインターフェイス( realm-cli
)を使用すると、アプリをプログラムで管理できます。 realm-cli
を使用すると、ローカル ディレクトリからアプリを作成またはアップデートしたり、既存のアプリケーションをローカル ディレクトリにエクスポートしたりできます。
インストール
realm-cli
はnpm
で利用可能です。 1realm-cli
システムに のバージョン をインストールするには、次の Node.js があることを確認してください がインストールされたら、shell で次のコマンドを実行します。
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
値が割り当てられました。