ОБНОВЛЕНИЕ

ЭТО МОЖЕТ БЫТЬ НЕ ТОЧНЫМ. СМОТРИТЕ ОТВЕТ НИК.

(Хотя я не мог заставить это работать. Но я не очень старался)

Существует совершенно недокументированная, но абсолютно необходимая часть информации w.r.t. настраиваемые управляемые виртуальные машины:

ОНИ НЕЛЬЗЯ ЗАПУСКАТЬ НА СЕРВЕРЕ РАЗРАБОТКИ!

Если вы думаете, что этот важный факт будет упоминаться где-либо в здравом уме, например, на странице документации для настраиваемых управляемых виртуальных машин, или для dev_appserver.py, или даже в качестве сообщения об ошибке при запуске dev_appserver.py, то вы слишком доверяете Google.

Единственное место, где я могу найти какое-либо заявление об этом, — это файл Readme в appengine-java-vm-guestbook-extras demo на github (серьезно):

Cloud SDK больше не поддерживает запуск пользовательских сред выполнения при наличии файла Dockerfile. Вам нужно будет развернуть приложение в App Engine.

Google не заботится о:

1. Реализуйте эту основную и важную функцию.
2. Задокументируйте, что на сервере разработки отсутствует такая важная функция.
3. Дайте любое разумное сообщение об ошибке, когда пользователь устанет выполнять действие.

Я надеюсь, что этот ответ спасет какого-нибудь извиняющегося разработчика от дней мучений, которые я перенес из-за этого.

EDIT 1: решение, опубликованное user862857, использует сам Docker для создания образов из Dockerfile и запуска их в контейнерах. Это также хороший подход к запуску управляемых виртуальных машин и пользовательских сред выполнения в контексте разработки.

Принятый ответ не кажется правильным. README на github не должен превосходить официальную документацию в плане авторитетности при работе с с быстро развивающимся бета-продуктом. Это вполне возможно для приложения runtime: custom в среде разработки, используя Dockerfile, упомянутый в сообщении OP,

FROM gcr.io/google_appengine/python-compat
ADD . /app

используя флаг --runtime=python-compat. Однако им нужно будет перехватывать запросы к /_ah/start и /_ah/health. Попробуйте запустить следующую команду, учитывая следующие файлы, и убедитесь сами:

devserver command

$ dev_appserver.py app.yaml --runtime=python-compat

app.yaml

runtime: custom
vm: true
api_version: 1
threadsafe: true

handlers:
- url: /.*
  script: main.app

Dockerfile

FROM gcr.io/google_appengine/python-compat

RUN apt-get update

RUN apt-get install -y gwhois

ADD . /app

main.py

import logging
import webapp2
from subprocess import Popen, PIPE

class OkHandler (webapp2.RequestHandler):
    def get (self): 
        self.response.write ('ok')

class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        domain = self.request.get ('domain')
        cmd = ["gwhois", domain]
        process = Popen (cmd, stdout=PIPE, stderr=PIPE)
        output, err = process.communicate()
        exit_code = process.wait()
        self.response.write('stdout: %s' % output)
        logging.info ('stderr: %s' % err)

app = webapp2.WSGIApplication([
    ('/', MainPage),
    ('/_ah/start', OkHandler),
    ('/_ah/health', OkHandler)
], debug=True)

Отправьте запрос на /?domain=stackoverflow.com, чтобы увидеть это в действии.

Примечание

Если бы они хотели полностью отделиться от среды выполнения, совместимой с python, и просто развернуть / протестировать приложение WSGI на python через, они также могли бы использовать флаг --custom_entrypoint, если у них была команда, которая запускала бы соответствующее приложение WSGI на подходящем порту. (такой командой будет uwsgi или gunicorn).

После попытки заставить мою пользовательскую виртуальную машину работать с dev_appserver большую часть дня, принятый ответ на этот пост пришел как довольно неприятный сюрприз. Но я полагал, что развертывание сервера разработки не может быть такой проблемой, потому что, в конце концов, виртуальная машина — это стандартный образ Docker.

Что ж, оказалось, что есть несколько проблем, которые мешают работе прямого развертывания. Я представил краткое изложение этих проблем ниже, а также то, как я их решил. Возможно, я упустил некоторые несовместимости между средами Docker и App Engine (особенно многие аспекты App Engine, которые не использовались в моем проекте), но, надеюсь, этого достаточно, чтобы люди начали работать.

Источники неприятностей

Во-первых, я обнаружил, что среда Python, работающая на виртуальных машинах Compute Engine, немного более снисходительна, чем обычная среда виртуальных машин (например, такие пакеты, как webapp2, всегда доступны). Следовательно, развертывание в менее щадящей контейнерной среде Docker выявило некоторые скрытые ошибки в моем проекте.

При этом существуют некоторые различия в средах, которые требуют некоторых настроек, даже если ваш проект безупречен:

• Проблема: gunicorn (или выбранный вами сервер) должен быть установлен на пути контейнера Docker.

  • While this may seem obvious, I ran into trouble because I included gunicorn in my project's requirements.txt file. Unfortunately, I was installing all of these dependencies using pip install -t ... which is only able to install source. As a result, there was no gunicorn binary on the image let alone on the PATH.

• Решение: явным образом pip install gunicorn

• Problem: google.appengine.* packages are not available from the App Engine base Docker image nor are they available via pip (AFAICT).
  • This may be a common source of trouble because google.appengine.ext.vendor is the recommended interface for importing third-party libraries into your App Engine app.
• Решение. Я обошел эту проблему, загрузив всю иерархию пакетов Google App Engine и поместив ее в путь к приложению.

Как получить скрипт

Сценарий для создания и развертывания образа виртуальной машины в Docker-контейнере, работающем локально, доступен здесь.

Рабочий пример см. в моем проекте.

Дайте мне знать, если у вас есть комментарий, запрос функции или если вы пишете более красивый bash, чем я (я чувствую, что установил планку на достаточно низком уровне в этом отношении).