在Google App Engine中使用Docker进行组合 [英] Using Docker compose within Google App Engine

问题描述

目前我正在试用 Google App Engine灵活环境，特别是可让您建立。

Docker提供了一个非常好的功能，称为 docker-compose 用于定义和运行多容器Docker应用程序。

现在问题是，有没有什么办法可以使用码头工人在GAE内组成？如果答案是否定的，那么在使用Docker的GAE灵活环境中部署多容器应用程序（例如Nginx + PHP-FPM + RabbitMQ + Elasticsearch + Redis + MongoDB ......）的最佳方法是什么？

解决方案

目前无法使用docker-compose在单个App Engine实例中拥有多个应用程序容器。这看起来不过是设计。

独立扩展应用程序组件

如果您想要有多个应用程序容器，则需要将它们部署为单独的App Engine服务。每个服务实例仍然只有一个应用程序容器，但每个服务可能有多个实例。这将为您提供灵活性，以便您寻求独立扩展每个应用程序组件。另外，如果容器中的应用程序挂起，它不会影响其他服务，因为它们将驻留在不同的VM中。
将每个组件作为单独服务部署的附加好处是不需要为每个服务使用灵活的环境。对于一些非常小的任务，如API后端或提供相对缓慢变化的Web内容，标准环境可能就足够了，并且在资源水平较低的情况下可能会更便宜。 组件

由于您的评论之一提到了获取实例IP，我认为您可能会发现跨服务通信很有用。我不确定您希望使用VM实例IP的原因，但典型的用例可能是在实例或服务之间进行通信。要做到这一点没有实例IP，最好的办法就是简单地使用适当的URL，从一个服务到另一个服务发出HTTP请求。如果您有一个名为 web 的服务和一个名为 api 的服务， web 服务可以向 api.mycustomdomain发出请求.com 您的应用程序托管在哪里， api 服务将通过 X-Appengine-Inbound-Appid 您的项目ID指定的标头。这可以用来识别来自您自己的应用程序的请求。

使用Docker的多容器应用程序

您提到了很多应用程序的例子，包括NGinx，PHP-FPM，RabbitMQ等等。使用App Engine使用自定义运行时，只要它响应来自端口8080的请求，就可以部署任何容器来处理流量。请记住，应用程序的主要用途是提供响应。这些实例应该设计成可以快速启动和关闭以实现横向扩展。他们不应该被用来存储任何应用程序数据。这应该保持在App Engine之外，使用云端SQL ， Cloud Datastore ，BigQuery或您自己的运行在Compute Engine上的Redis实例。

我希望这个澄清几件事情，并回答你的问题。

I am currently experimenting with the Google App Engine flexible environment, especially the feature allowing you to build custom runtimes by providing a Dockerfile.

Docker provides a really nice feature called docker-compose for defining and running multi-container Docker applications.

Now the question is, is there any way one can use the power of docker-compose within GAE? If the answer is no, what would be the best approach for deploying a multi-container application (for instance Nginx + PHP-FPM + RabbitMQ + Elasticsearch + Redis + MongoDB, ...) within GAE flexible environment using Docker?

解决方案

It is not possible at this time to use docker-compose to have multiple application containers within a single App Engine instance. This does seem however to be by design.

Scaling application components independently

If you would like to have multiple application containers, you would need to deploy them as separate App Engine services. There would still only be a single application container per service instance but there could be multiple instances of each service. This would grant you the flexibility you seek of scaling each application component independently. In addition, if the application in a container were to hang, it could not affect other services as they would reside in different VMs. An added benefit of deploying each component as a separate service is that one need not use the flexible environment for every service. For some very small tasks such as API backends or serving relatively slow-changing web content, the standard environment may suffice and may be less expensive at low resource levels.

Communication between components

Since one of your comments mentions getting instance IPs, I thought you might find inter-service communication useful. I'm not certain for what reason you wish to use VM instance IPs but a typical use case might be to communicate between instances or services. To do this without instance IPs, your best bet is to issue HTTP request from one service to another simply using the appropriate url. If you have a service called web and one called api, the web service can issue a request to api.mycustomdomain.com where your application is hosted and the api service will receive a request with the X-Appengine-Inbound-Appid header specified with your project ID. This can serve as a way a identifying the request as coming from your own application.

Multicontainer application using Docker

You mention many examples of applications including NGinx, PHP-FPM, RabbitMQ, etc.. With App Engine using custom runtimes, you can deploy any container to handle traffic as long as it responds to requests from port 8080. Keep in mind that the primary purpose of the application is to serve responses. The instances should be designed to start up and shut down quickly to be horizontally scalable. They should not be used to store any application data. That should remain outside of App Engine using tools like Cloud SQL, Cloud Datastore, BigQuery or your own Redis instance running on Compute Engine.

I hope this clarifies a few things and answers your questions.

这篇关于在Google App Engine中使用Docker进行组合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！