Несколько сервисов в Google App Engine Python 3.7 - PullRequest
Новая
       24

Несколько сервисов в Google App Engine Python 3.7

0 голосов
/ 10 марта 2019

У меня есть приложение, которое нормально работает в среде Python 2.7 Standard и прекрасно работает как два отдельных приложения в среде 3.7, но я не могу понять, как настроить их как одно приложение с двумя службами.
main.app состоит из следующих двух строк (параллельно тому, что раньше работало в платформе 2.7) 

from app import app
from update import update

app.yaml для main состоит только из среды выполнения: python37

Каждаяиз двух пакетов python в main (app и update) есть свой собственный app.yaml, как говорится в новом документе развертывания.Проблема в пакете update .Я использовал для указания обработчика, который имеет скрипт: main.update.Это больше не разрешено (разрешен только auto.) Обратите внимание, что пакет app работает нормально, потому что app является точкой входа по умолчанию.Я понял, что новый способ указать, куда обращаться при запуске службы обновлений, - это использовать точку входа, но даже после добавления gunicorn к требованиям, оператор yaml 

entrypoint: gunicorn b :$PORT main::update

, который, кажется, является тем, что требуется,просто дает мне возвращение 500 http.Я также пробовал варианты, такие как main.update, но безрезультатно. 

main.py  
app.yaml  
-->/app
-----> /app/__init__.py  
-----> /app/app.yaml  
-->/update  
------> /update/__init__.py  
------> /update/app.yaml

Есть также подкаталоги шаблонов для обоих пакетов и некоторых других вещей, но все они отлично работают, когда работают как отдельные версии

Вот мой попытанный yaml в каталоге обновлений: 

runtime: python37

service: update

entrypoint: gunicorn -b :$PORT main.update

А вот yaml в каталоге приложений, который, кажется, работает нормально: 

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 Ответ

2 голосов
/ 10 марта 2019

Глядя на то, что вы описали, и предполагая, что вы стремитесь к структуре каталогов, аналогичной той, которая упоминалась в разделе Пример документа, на который вы ссылались, я вижу несколько проблем.

У вас все еще есть код в верхнем / корневом каталоге приложения, над каталогами служб - файлами main.py и app.yaml - такой код недоступен службам. В частности, файл app.yaml может вызвать проблемы, так как может случайно быть интерпретирован как файл .yaml приложения с одним сервисом. Я бы избавился от этих файлов.

Я бы оставил только в директории верхнего уровня приложения необязательные файлы конфигурации на уровне приложения и, если применимо, файлы, предназначенные для хранения кода, совместно используемого несколькими службами, который я бы поставил символическую ссылку внутри каждой из служб разделение кода см. Совместное использование сущностей между модулями App Engine

В файле update/app.yaml вы используете неверный синтаксис для конфигурации точки входа:

  • у вас должно быть один : разделитель между именем модуля и именем переменной приложения WSGI, т.е. main:update, а не main::update или main.update. Предполагается, что у вас есть файл update/main.py, определяющий ваше WSGI-совместимое приложение с именем update (если вместо этого приложение называется app, то вы будете использовать main:app)
  • в одном примере у вас есть b вместо -b

У вас нет точки входа, определенной в файле app/app.yaml. Скорее всего, ваша служба default соответствует условиям, при которых автоматически добавляется точка входа по умолчанию, см. Запуск приложения :

  • Корень каталога вашего приложения содержит файл main.py с WSGI-совместимым объектом с именем app.
  • app.yaml не содержит поля точки входа.
  • Ваше приложение не содержит Pipfile или Pipfile.lock файлов.

Лично я предпочитаю не полагаться на это поведение по умолчанию, я бы явно добавил точку входа: 

entrypoint: gunicorn -b :$PORT main:app
...