从应用程序引擎访问计算引擎 [英] Access compute engine from app engine

问题描述

我有一个运行在计算引擎上的实例，它使用Torch来预测图像中的对象。我想创建一个简单的Web界面，用户可以使用该界面上传图像，将图像发送到服务器（计算引擎），预测对象并将列表返回给用户。
在我的计算引擎（Ubuntu 14.04）中，这行代码用于预测图像中的对象。 （所有其他设置已经在计算引擎中完成了。）

  th eval.lua -model / path / to / model -image_folder / path / to / image / directory -num_images 10 
  

我想从这行中调用Web应用程序并将图像传递到图像文件夹并取回对象列表。

解决方案

在过去的项目中，我讨论过并使用不同的方法在Google App Engine和Google之间进行通信计算引擎。一般来说，两个常见的嫌疑人是：

• App Engine的编排：在这种方法中，App Engine应用程序活动部分并将请求发送到计算实例上的服务。这是 Igor Artamonov 在他的评论中已经描述的内容。我们在运行完整休息api的计算实例上使用了一个tomcat实例来调用实例上的命令。可能的助手：
  
  
  
  
  • 使用
    


• 来自计算实例的轮询：既然您知道您的App Engine应用程序的应用程序ID可以在您的计算实例上编写一个简单的循环，从应用程序引擎应用程序请求新的作业。我已经将这种方法与编排结合使用，它会将关闭命令发送到不再需要的实例，从而减少应用引擎上的轮询负载。如果创建了新的作业，我将启动一个新的计算实例，然后再进行轮询，直到它再次收到关闭命令。好。如果您使用Compute API并知道计算实例的IP地址，则可以将您的轮询端点和命令调用请求限制为这些IP以获得基本安全性。
  
  
  

  我会尝试避免过多的投票，因为，让我给你一个报价：
  
  

  
  

  积极轮询是穷人的解决方案来启动工作流程。 （ javaworld.com ）

  
  

  但是，如果您在完成计算实例时关闭计算实例工作量我没有看到你不应该使用轮询的好理由。如果您不这样做，并且您将计算实例的数量增加到几个实例，那么您的App Engine应用程序将无法获得任何成本，而只会带来成本。

  
  

  I have an instance running on the Compute Engine which uses Torch to predict objects in images. I wanted to make a simple web interface using which a user can upload an image, the image is sent to the server(compute engine), the objects are predicted and the list is returned back to the user. In my compute engine (Ubuntu 14.04) this line of code is used to predict objects in images. (All the other setup has been already done in the compute engine.)

  th eval.lua -model /path/to/model -image_folder /path/to/image/directory -num_images 10 
  

  I want to call this line from the web app and pass the image to the image folder and get back the list of objects. How do I go about it?

  解决方案

  In past projects I have discussed and used different approaches to communicate between Google App Engine and Google Compute Engine. Generally speaking the two usual suspects are:

  • Orchestration from App Engine: In this approach the App Engine application is the active part and sends requests to a service on the compute instance. This is what Igor Artamonov already described in his comment. We used a tomcat instance on the compute instances which ran a full rest api to invoke commands on the instance. Possible helpers:
    • When using the Google Compute API from App Engine you can get the external IP address of compute instances. So you know where your requests will have to go.
  • Polling from the compute instance: Since you know the app id of your App Engine application you could code a simple loop on your compute instances that request new jobs from the app engine application. I have used this approach in combination with an orchestration that will send a shutdown command to instances that are no longer required, therefor reducing the polling load on app engine. If new jobs were created I would start a new compute instance which would then poll until it receives a shutdown command again.

  Both approaches work well. If you use the Compute API and know the IPs of your compute instances you can restrict your polling endpoints and command invoke requests to these IPs for basic security.

  I would try to avoid too much polling though since, well let me give you a quote:

  Actively polling is the poor man's solution to kicking off a workflow process. (javaworld.com)

  But if you shut down your compute instances when they are finished with their workload i don't see a good reason why you shouldn't use polling. If you don't and you increase the number of compute instances to a couple instances you will have load on your App Engine application without achieving anything but cost.

  这篇关于从应用程序引擎访问计算引擎的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！