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

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

from app import app
from update import update

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

Каждый из двух пакетов python под основным (приложение и обновление) имеет свой собственный app.yaml, как говорится в новом документе развертывания. Проблема в пакете обновления. Раньше я указывал обработчик, у которого был скрипт: main.update. Это больше не разрешено (разрешено только auto). Обратите внимание, что пакет 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

person greylock    schedule 09.03.2019    source источник
comment
Покажите структуру каталога вашего приложения, 2 файла .yaml и 2 файла python, содержащих серверные приложения (соответствующие настроенным точкам входа, если таковые имеются). Возможно, взгляните на stackoverflow.com/a/34111170/4495081 (хотя первое поколение, но это не должно быть таким проблема).   -  person Dan Cornilescu    schedule 10.03.2019
comment
Я посмотрел на это, и раньше у меня было именно так, но новые документы [здесь] (cloud.google.com/appengine/docs/standard/python3/) говорят, что это не сработает. Но я отредактирую выше   -  person greylock    schedule 10.03.2019
comment
Я не понимаю, где это говорится в документе. И я не понимаю, как то, что вы сделали, похоже на то, что написано в документе ...   -  person Dan Cornilescu    schedule 10.03.2019
comment
Вы пытаетесь разделить приложение с одной службой на приложение с двумя службами одновременно с переходом с 2.7 на 3.7? Покажите также before версии .yaml файлов, которые работали.   -  person Dan Cornilescu    schedule 10.03.2019
comment
В мире 2.7 у меня были только все служебные файлы .yaml в корневом каталоге. У каждого из них была своя строка сценария (под url: /.*), которая сообщала точку входа службы. (main.app и main.update). Затем я просто собрал все файлы .yaml в одном операторе развертывания, и все заработало. Я могу попытаться исправить все так, как вы предлагаете, но пока я просто втиснул все это в службу по умолчанию, и она работает нормально, но у меня есть только одна служба. Это не слишком большая проблема, потому что я могу просто использовать cron.yaml для запуска службы обновления самостоятельно, указав входной маршрут.   -  person greylock    schedule 11.03.2019


Ответы (1)


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

У вас все еще есть код в верхнем / корневом каталоге приложения, над каталогами служб - файлы 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
person Dan Cornilescu    schedule 10.03.2019