Поддержка Django приложений в Google App Engine

    Недавно google анонсировал Cloud SQL для своего облака. Но вначале подержки django не было, и вот в начале февраля выходит App Engine 1.6.2 с поддержкой запуска приложений на django. Теперь можно забыть про скакания вокруг app-engine-patch и django-nonre, и пытаться эмулировать реляционную базу данных поверх bigtable.

    Нам дают django 1.2 и модуль работы с Cloud SQL из коробки, и мы можем забыть про костыли с упаковкой пакетов в zip архивы. Вот какие шаги нам необходимо сделать для получения простого приложения в облаке:
    1. Для начала необходимо запросить тестовый доступ к Cloud SQL через Google APIs Console. Мне выдали доступ в течений 3-х дней, после этого в консоли мы получим доступ к управлению сервисом.

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

    3. Теперь создаем обычное GAE приложение внутри которого будет веб приложение на django + app.yaml файл в который необходимо прописать:
      application: appname
      version: 1
      runtime: python27
      api_version: 1
      threadsafe: true
      
      libraries:
      - name: django
        version: "1.2"
      
      builtins:
      - django_wsgi: on

    4. Для того что бы django-приложение сумело обращаться к Cloud SQL необходимо лишь в конфиге для DATABASES прописать:
      DATABASES = {
          'default': {
              'ENGINE': 'google.appengine.ext.django.backends.rdbms',
              'INSTANCE': 'my_project:instance1',
              'NAME': 'my_database',
          }
      }


    Это основное что необходимо сделать для подготовки приложения. При первой попытки сделать syncdb нас попросят авторизоваться, для этого нужно получить токен через Google APIs Console на вкладке «API Access», и как говорит инструкция расположить его в ~/.googlesql_oauth2.dat (для windows %USERPROFILE%\.googlesql_oauth2.dat). Во время syncdb в Cloud SQL создаться необходимая схема базы для приложения и загрузятся fixtures если они есть. Пока разработка идет на локальной машине, приложение работает с sqlite3 базой. После этого можно смело пушить приложение в облако.

    ИМХО


    Я считаю что гугл сделал правильный шаг, давая SQL базу. У них не получилось выстрелить со своим облаком. Да в то время это смотрелось интересно, но все быстро поняли что оно слишком ограничено, и завязнуф на сервисах google будет очень тяжело перенести приложение куда либо. Да есть инструменты для миграций на амазоноские сервисы, но они не дают гарантий, и в любом случае потребуется N-ое количество человеко часов для переноса. Я не вспомню не одного крупного сайта работающего поверх GAE, был интересный проект интернет магазина, но и тот скорее мертв чем жив. Большие проекты скорее избегают GAE или даже о нем не думают, когда рядом есть амазон, на котором можно построить свою архитектуру, легко смигрироваф при необходимости.
    Для тех кому нужно что то поменьше, запустить бложик, сайт визитку и т.п это слишком сложно, да и зачем разбираться в особенностях разработки под GAE, когда можно без особых усилий запустить подобное на специализированных сервисах.
    А вот с запуском Cloud SQL ситуация хоть немного может измениться. Теперь можно спокойно запускать django сайты средней сложности на GAE, прикрутить к нему домен, и забыть про администрирование сервера. Только не стоит забывать про то что GAE поддерживает библиотеки написанные только на чистом python, про все сишные модули стоит забыть, а также ограничения на http запросы из приложения. И нам все еще надо будет использовать API GAE для загрузки файлов в хранилище, отсылку email и кэширование в memcache, но даже с этими ограничениями это покроет большую часть нужд для разворачивания «простых» сайтов.

    Ссылки:
    Share post

    Comments 20

      +2
      Непонятно, почему не выстрелило.
      Было много разговоров о том, что документ-ориентированные базы гораздо удобнее для веба вообще.
      Да и с точки зрения банальной эрудиции, данные интернет-магазина, например, удобнее и эффективнее хранить документами, а не вытаскивать мега-джойнами.
        0
        Я согласен с тем что документ-ориентированные базы это супер удобно, тут вопрос в том какие инструменты предоставляет google для разработки приложения. Нам дали API, вот и крутимся как можем у кого руки чешутся.
          0
          Тут согласен, webapp, webapp2 до django никак не дотягивают, а tipfy, кажется, умер.
          Однакож сердце фреймворка — ORM, который в GAE по сути вообще не нужен. А Guido vanRossum пилит более адекватный API к базе.

          Но это всё не имеет отношения к SQL
          +3
          Основная проблема в другом. Это все может быть очень удобно, но писать код только под GAE — серьезный риск. Если завтра AppEngine по какой-то причине перестанет устраивать, придется переписывать всю логику работы с СУБД, файлами — для проектов крупнее бложика, а тем более серьезных коммерческих проектов это никуда не годится.
            0
            На самом деле не выстрелило, потому что банально ДОРОГО. Как только приложение переходит в разряд highload готовимся к сумасшедшим счетам. Но это относится ко многим клаудам, тот же Heroku взять например. Только с другого облачного сервиса можно было спрыгнуть на свои сервера, если проект выстрелит, а в случае с GAE полный vendor lock-in, в основе которого своя БД.

            Так что гуглу некуда деваться, надо дать людям то, что они хотят, конкуренты (с упомянутым Heroku во главе) сильно поджимают.
          0
          По поводу проектов поверх GAE — gmail, googledocs, googlemaps и прочее — разве не на gae построены?
            0
            Нет, GAE это лишь попытка продать свои простаивающие мощности. Я конечно не могу точно сказать, но я очень сомневался бы если gmail на 100% совместим с GAE. По началу энтузиасты строили решения на GAE в надежде что их купит гугл, так как интеграцию будет проще делать. А еще гугл обещал выдержать милион посетителей и почти не брать за это деньги, но оказалось что это очень дорого, особенно если много писать в базу.
              0
              Нет. Разве что может использоваться Bigtable, но совсем через другие интерфейсы.
              0
              Прекрасно.
              Но если проект не на Джанге, а на другом фреймворке? Кто-нибудь знает, как связать SQLAlchemy с CloudSQL?
                0
                Судя по документаций трудностей не должно быть, нам дают обычный доступ DB-API 2.0, нужно отдать свой «connect» для SQLAlchemy
                0
                Только не стоит забывать про то что GAE поддерживает библиотеки написанные только на чистом python, про все сишные модули стоит забыть

                GAE поддерживает некоторые популярные сишные библиотеки, например, PIL, NumPy.
                  0
                  PIL используется только на локальной машине для эмуляций Images API
                    0
                    В составе GAE уже идет набор неплохих «батареек», плюс появление python27 runtime сильно упростило работусо времён, когда была доступна 2.5 версия.
                    Кстати — странно что пост появился только сейчас CloudSQL анонсировали ажно 7-го ноября, а недавно вышла уже версия 1.6.3 SDK с поддержкой django 1.3
                    Правда проблем от этого не убавилось — отсутствуют инструменты нормальной миграции базы, что при длительной командной разработке проекта доставляет массу неудобств.

                    От себя хотел добавить — не нужно было пытаться взгромоздить django поверх Datastore — последний всё же noSQL решение и отношение должно быть соответствующим, но зато там были асинхронные запросы на чтение/запись, и в общем, я его до сих пор считаю неодооцененным. Попробуйте поработать с Datastore не стандартным google.appengine.ext.db а через google.appengine.ext.ndb — который с релиза 1.6.1 появился в составе SDK, Гвидо плохого не напишет :)
                      +2
                      Я бы даже сказал что в октябре анонсировали, об 1.6.2 я сказал. Изначально писал статью типа – «создаем проект django на GAE», с инструкцией по шагам, но бросил это дело, кому надо тот понял суть, новички сюда не полезут.
                      На счет запуска django поверх Datastore, в сети много обсуждения этого, значит это кому то надо. Да это дикий костыль, но пользовались этим потому что иных инструментов по возможностям не было. Любой более-менее сложный проект приходилось писать с нуля руками, начиная авторизаций, заканчивая админкой.
                      Datastore это хорошо, я согласен, но это дорого, и перенести потом приложение на свой сервер допустим с монгой будет наверное так же затратно как написать приложение по новой.
                        0
                        Практически согласен во всём, кроме повального увлечения django — есть куча хороших python-фреймворков отвязанных от ORM совершенно :)

                        По переносимости — работая ранее с ndb нашел множество похожих подходов у ребят сделавших asyncmongoorm поверх asyncmongo для tornado — так что, если код раньше был на чем-то вроде webapp — перенос не составит труда :)
                          0
                          Какие, например?
                  0
                  Django 1.2 is too old.
                    0
                    На данный момент Google Cloud SQL уже, похоже, не бесплатный… Печально.
                      0
                      Да, убрали и к сожалению на реальных проектах стало видно что база очень медленная + бывают прерывания в работе со стороны сервиса

                    Only users with full accounts can post comments. Log in, please.