我正在尝试使用应用引擎标准在Google云中实施简单设计,并使用数据存储区实现灵活性。 App1生活在GAE标准环境中。当用户与此应用程序交互时,它会将一些数据写入数据存储区并对任务进行排队。排队任务的目标是App2,它位于应用程序引擎灵活的环境中(任务可能需要比标准环境允许的更长的时间才能完成)。我们的想法是让App2从数据存储区读取数据,使用数据执行任务,一旦完成,它应该将报告实体写入数据存储区。我附上了一个简单的图表。
在App1中,我设置了一个名为flexKey且具有所有者权限的服务帐户,下载了json文件。
当我在本地运行App2时,我首先将路径作为环境变量导出到凭证json文件:
GOOGLE_APPLICATION_CREDENTIALS: "path/to/flexKey.json"
然后用mvn jetty:run-exploded
启动应用程序,一切正常,App2能够通过实时数据存储(非本地模拟)进行身份验证,并读取App1写入的数据。当我取消设置环境变量时,出现“未经验证”错误(预期)
要在部署App2时使用相同的服务帐户,我在app.yaml中为App2添加了以下内容,将环境变量GOOGLE_APPLICATION_CREDENTIALS
设置为服务帐户json文件flexKey.json的路径(这是部署实例上文件的路径):
env: flex
env_variables:
GOOGLE_APPLICATION_CREDENTIALS: "/var/lib/jetty/webapps/root/WEB-INF/classes/flexKey.json"
runtime: java
但是,当我将App2部署到app engine灵活环境时,在尝试执行读取查询时,使用数据存储区进行身份验证时出错(在从本地运行的App2实例查询具有相同凭据的数据存储时,此方法正常): / p>
com.google.cloud.datastore.DatastoreException: Missing or insufficient permissions.
at com.google.cloud.datastore.spi.v1.HttpDatastoreRpc.translate(HttpDatastoreRpc.java:129)
at com.google.cloud.datastore.spi.v1.HttpDatastoreRpc.translate(HttpDatastoreRpc.java:114)
at com.google.cloud.datastore.spi.v1.HttpDatastoreRpc.runQuery(HttpDatastoreRpc.java:182)
at com.google.cloud.datastore.DatastoreImpl$1.call(DatastoreImpl.java:178)
at com.google.cloud.datastore.DatastoreImpl$1.call(DatastoreImpl.java:174)
at com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:89)
at com.google.cloud.RetryHelper.run(RetryHelper.java:74)
at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:51)
at com.google.cloud.datastore.DatastoreImpl.runQuery(DatastoreImpl.java:173)
.....
代码是PERMISSION_DENIED
我无法理解为什么相同的凭据(使用所有者角色创建)在从本地运行的应用程序实例查询数据存储时工作正常但在从部署版本的数据存储区查询数据存储时不起作用应用程序(部署到灵活的环境)。通过app.yaml中的环境变量设置凭证文件的路径是文档中建议的方法,除非我弄错了。
所有帮助表示赞赏。
答案 0 :(得分:1)
您的设计中存在阻塞问题:一个应用程序无法将任务排入针对来自其他应用程序的服务的推送队列。来自<target> (push queues)
表中Syntax
行的queue.yaml
和queue.xml
引用:
该字符串会在您的应用的域名前加上 构造任务的HTTP请求。例如,如果您的应用ID 是 my-app ,您将目标设置为 my-version.my-service , URL主机名将设置为 的 my-version.my-service.my-app.appspot.com 强>
如果要使用任务队列,则必须使2个服务成为同一应用程序的一部分。作为(正面)副作用,您不必担心为数据存储访问设置身份验证 - 这两种服务都可以直接访问应用程序的数据存储。