问题
I have an application that ran fine under the Python 2.7 Standard framework, and runs fine as two separate applications in the 3.7 framework, but I can't figure out how to configure them as a single application with two services.
main.app consists of the following two lines (paralleling what used to work in the 2.7 framework)
from app import app
from update import update
The app.yaml for main consists of nothing but runtime: python37
Each of the two python packages under main (app and update) have their own app.yaml as the new deployment document says they are supposed to. The problem is in the update package. I used to specify a handler which had script: main.update. That is no longer allowed (only auto is allowed.) Note that the app package works fine because app is the default entrypoint. I gather that the new way to specify where to go when the update service is run is to use entrypoint, but even after adding gunicorn to the requirements, the yaml statement
entrypoint: gunicorn b :$PORT main::update
which seems to be what's required, simply gives me a 500 http return. I also tried variants like main.update to no avail.
main.py
app.yaml
-->/app
-----> /app/__init__.py
-----> /app/app.yaml
-->/update
------> /update/__init__.py
------> /update/app.yaml
There are also template subdirectories to both packages and some other stuff, but they all work fine when run as separate versions
Here is my attempted yaml in the update directory:
runtime: python37
service: update
entrypoint: gunicorn -b :$PORT main.update
And here is the yaml in the app directory, which seems to work fine:
runtime: python37
service: default
handlers:
- url: /static
static_files: static/\1
upload: static/(.*\.(bmp|gif|ico|jpeg|jpg|png))
automatic_scaling:
max_idle_instances: 2
max_concurrent_requests: 12
回答1:
Looking at what you described and assuming you are aiming for a directory structure similar to the one mentioned in the Example section of the doc you referenced I see a few problems.
You still have code in the app's top/root directory, above the services' directories - the main.py
and app.yaml
files - such code isn't accessible to the services. The app.yaml
file in particular may actually cause problems as it might accidentally be interpreted as the .yaml
file of a single-service app. I'd get rid of these files.
I would only keep in the app's top-level dir app-level optional config files and, if applicable, files intended to contain code shared by multiple services, which I would symlink inside each of the services sharing the code, see Sharing entities between App Engine modules
In the update/app.yaml
file you're using the wrong syntax for the entrypoint configuration:
- you should have a single
:
delimiter between the module name and the WSGI app variable name, i.emain:update
, notmain::update
ormain.update
. This assumes you have anupdate/main.py
file defining your WSGI-compatible application calledupdate
(if the application is calledapp
instead then you'd usemain:app
) - in one example you have
b
instead of-b
You don't have an entrypoint defined in the app/app.yaml
file. Most likely your default
service meets the conditions in which a default entrypoint is automatically added, see Application startup:
- The root of your app directory contains a
main.py
file with a WSGI-compatible object calledapp
.app.yaml
does not contain the entrypoint field.- Your app does not contain
Pipfile
orPipfile.lock
files.
Personally I prefer to not rely on this default behaviour, I'd explicitly add the entry point:
entrypoint: gunicorn -b :$PORT main:app
来源:https://stackoverflow.com/questions/55082302/multiple-services-in-google-app-engine-python-3-7