Убегая из привязки Google App Engine Python? [закрытый]
Я также получал ту же ошибку, ниже приведено решение, которое я пробовал, и оно работает: 1. Запустите команду: aws ecr get-login --no-include-email --region ap-southeast-1 (изменить регион в соответствии с вашим хранилищем) 2. вы получите что-то вроде: вход в докер -u AWS -p xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx == https://youraccountid.dkr.ecr.ap-southeast-1.amazonaws.com
Удалите «https: //», а затем выполните команду от имени входа в докер -u AWS -p xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx == youraccountid.dkr.ecr.ap-southeast-1.amazonaws.com
И это сработает, и вы сможете нажать на изображение.
8 ответов
Для полной переносимости приложения требуется ряд компонентов:
- Сама среда выполнения. Это можно перенести относительно просто, настроив сервер CGI или FastCGI, который имитирует среду App Engine (которая, по сути, представляет собой слегка улучшенный CGI). Большая часть кода для этого уже находится в SDK. К сожалению, для этого пока нет простого готового набора инструментов.
- Хранилище данных. Безусловно, самый сложный API для переноса. В настоящее время ведется ряд работ: AppScale работает на EC2 / Eucalyptus / Xen и использует серверную часть HyperTable или HBase; это все еще очень бета-качество, и они не распространяют коннектор данных отдельно (это начало полного решения для запуска вашего приложения в вашем собственном облаке). Йенс пишет / писал серверную часть SQLite , и есть мой собственный проект BDBDatastore , который использует BDB-JE в качестве бэкэнда и является полностью функциональным (хотя и в бета-качестве). AppDrop , о котором упоминали другие, просто использует сервер разработки в качестве бэкэнда и, следовательно, не подходит для производственного использования.
- Пользовательский API необходимо заменить чем-то другим, например API на основе OpenID . Опять же, довольно простые, но готовых решений пока нет.
- API Memcache нуждается в бэкэнде, который использует стандартные бэкэнды memcache C.
- Другие API имеют прекрасно работающие бэкэнды как часть SDK, так что портировать на самом деле не нужно .
- Также потребуется реализовать поддержку Cron, как и фоновую обработку, XMPP и т. Д., Когда они станут доступны.
Как видите, предстоит еще много работы, но нет никаких фундаментальных препятствий для запуска вашего приложения App Engine за пределами среды Google. Фактически, если вам интересно, вы можете принять участие - я и другие планирую объединить решения для различных частей в единое решение OpenEngine для размещения ваших собственных приложений.
Используйте высокоуровневую структуру, работающую на App-Engine. Таким образом, вы можете переносить свой код на другие серверы, когда захотите.
django был пропатчен и портирован для работы в проекте Appengine patch и является наиболее часто используемым встроенным ПО в appengine.
Вы можете хочу сослаться на это пошаговое вступление к запуску приложения django на движке приложений
Что касается параллельной инфраструктуры для запуска приложения движка приложений, то до него еще далеко. Сам App Engine не стал таким популярным, как люди думали и хотели видеть Google. Кроме того, разработку на встроенной платформе WebApp сложнее, чем на django.
Маловероятно, чтобы увидеть параллельную инфраструктуру для запуска приложения движка приложения, по крайней мере, в ближайшие годы.
Вы можете создавать приложения AppEngine, используя среду Python Django (хотя поддерживаемая версия немного отстает от последней версии Django). Когда вы теряете переносимость (по крайней мере, прямо сейчас), так это при использовании GQL / BigTable для сохранения. Это проприетарная платформа базы данных Google. Как упомянул Хэнк, это одна из главных причин для фактического использования AppEngine, но это также и самая большая точка блокировки.
Вот пара ссылок на поддержку Django в AppEngine и GQL / BigTable:
Пока что я нашел экспериментальный хост под названием app-drop , на котором можно размещать проекты движка приложений Google. Это должно означать, что по крайней мере возможно запускать проекты движков приложений вне инфраструктуры Google.
Однако это явно еще не подходит для производства.
AppDrop - это доказательство концептуального переноса AppEngine на Amazon Web Services / Elastic Computing, завершенного в апреле 2008 года. Он использует плоский файл вместо BigTable и работает в единственном экземпляре, поэтому есть проблемы с масштабированием; но разработчик говорит, что это заняло у него всего четыре дня, и, возможно, эти ограничения могут быть устранены другими.
Код должен быть в основном переносимым (они довольно хорошо показывают, какие модули вы не можете использовать в AppEngine и какой код, специфичный для AppEngine, каким запрещенным модулям соответствует), но в целом Пункт AppEngine - получить доступ к инфраструктуре Google. Нет особого смысла писать свой код с учетом ограничений AppEngine, если вы не собираетесь использовать их инфраструктуру.
Недавно я очень легко сделал обратную миграцию с ванильного Unix на движок приложений, используя ресурсы WHIFF. В основном настройте все, что зависит от платформы, как ресурс, а затем поменяйте местами / замените ресурсы на разные конфигурации.
http://piopio.appspot.com/W1000_1000.resources
также см.
http: //aaron.oirt .rutgers.edu / myapp / docs / W1100_1200.wwiki
для получения подробного примера обмена / конфигурации ресурсов. (примечание: со временем ссылки могут исчезнуть, приложение является экспериментальным.)
Посмотрите на typhoonae. Это бета-версия, но вполне пригодная для использования - мы перенесли одно из наших приложений на внутренний сервер под управлением этого стека.