Подтвердить что ты не робот

Клиентская сторона JS (например, AngularJS) + Django REST Backend: развертывание на одном PaaS?

В основном я структурирую свое приложение, похожее на этот проект GitHub: https://github.com/zackargyle/angularjs-django-rest-framework-seed

Можно ли развернуть бэкэнд и интерфейс на одном PaaS, таком как Heroku/Elastic Beanstalk?

Наличие разделенного бэкэнда REST и интерфейса JavaScript выглядит как более чистый/более масштабируемый способ делать что-то, а не пытаться смешивать их, как [django- angular]: (http://django-angular.readthedocs.org/en/latest/index.html/), или иметь бэкэнд-соединение REST с приложением Django, например http://blog.mourafiq.com/post/55099429431/end-to-end-web-app-with-django-rest-framework p >

Если его невозможно легко развернуть на эластичном бобовом стебле, существует ли простой способ развертывания бэкэнда Django на эластичном бобовом стебле, а интерфейс AngularJS для Amazon EC2/S3 с минимальной конфигурацией?

Я понимаю, что до этого было аналогичное обсуждение: Клиент JS + Django Rest Framework но в нем отсутствуют более конкретные детали.

4b9b3361

Ответ 1

Я нахожусь в одной и той же лодке с AngularJS как мой клиент и django-rest-framework как мой сервис. У меня также есть тот же тип установки git, где сервер и клиентский код являются братьями и сестрами в одном и том же репозитории. У меня нет опыта работы с Heroku, и я новичок в beanstalk, но я смог развернуть мой сайт и работать с AWS beanstalk.

С beanstalk есть два способа, которыми я знаю, чтобы развернуть ваш код.

  • Используйте eb и git описание здесь.
    • Хорошо работает, если вы хотите напрямую нажать исходный код.
  • Создайте свой собственный zip для загрузки в beanstalk через консоль управления AWS. У Amazon есть пошаговое руководство на нем здесь.
    • Маршрут Я выбрал так, чтобы я мог "grunt build" мой клиент и zip с кодом сервера перед развертыванием.

Я автоматизировал создание zip с помощью python script. Прохождение Amazon предоставляет пример python zip. Вы должны правильно его структурировать, мой взгляд выглядит примерно так.

app.zip
  /.ebextensions/
  /.elasticbeanstalk/
  /app/     <-- my django-rest-framework project (settings.py, wsgi.py, etc.)
  /restapi/ <-- my django-rest-framework application (my api)
  /static/  <-- AngularJS results of 'grunt build' put here
  /manage.py
  /requirements.txt

Я знаю, что вы специально не спрашивали, но файл .config внутри .ebextensions/занимал меня слишком долго, чтобы работать. Он может быть отформатирован как YAML или JSON (может быть запутанным сначала, так как каждый блог показывает его по-разному). Этот блог

В создаваемом zip файле (если вы следуете ), клиентский код в вашей/статической/папке автоматически s3 при развертывании.

Эта настройка не идеальна, и я планирую тонкую настройку, но она работает. Вот некоторые недостатки, с которыми я столкнулся, что я еще не решил:

Так как я помещаю свой клиентский код в статическую/папку, мой сайт находится под mysite.com/static/. В идеале я бы хотел, чтобы он служил корнем на mysite.com с моим содержимым django-rest-framework под mysite.com/api/ Если вы используете на beanstalk по умолчанию, активы не будут толкаться, так как они сидят в вашем каталоге python, а не с ваш исходный код.

ОБНОВЛЕНИЕ 4-17-2014

Я уточнил эту настройку, поэтому мне больше не нужно заходить на mysite.com/static/для загрузки моего index.html. Для этого я использовал , чтобы сопоставить index.html с корнем моего сайта. Мой urls.py выглядит как

urlpatterns = patterns('',
  (r'^$', TemplateView.as_view(template_name="index.html")),
  ...
)

и в моих настройках .py я сконфигурировал TEMPLATE_DIRS следующим образом

TEMPLATE_DIRS = (
  os.path.join(os.path.dirname(__file__) , '../static').replace('\\','/')
)

Я использую.. /static, потому что мой статический каталог является родным для моего каталога приложений.

Последняя часть должна была обновить мой Gruntfile.js, поэтому "grunt build" префикс всех относительных URL-адресов в моем angular коде со статической папкой. Для этого я использовал . Это последняя задача, которая выполняется после того, как мой код сидит в папке /dist. Недостатком этого подхода является то, что мне придется обновить эту задачу, если я когда-либо добавляю статический контент в новую подпапку, кроме скриптов, bower_components, styles и т.д.

replace: {
    replace_js_templates: {
        src: ['dist/scripts/*.js'],
        overwrite: true,                 // overwrite matched source files
        replacements: [{
            from: /templateUrl:\s*"/g,
            to: 'templateUrl:"static/'
        }]
    },
    replace_index: {
        src: ['dist/index.html'],
        overwrite: true,                 // overwrite matched source files
        replacements: [{
            from: /(src|href)="(bower_components|styles|scripts)/g,
            to: '$1="static/$2'
        }
        ]
    }
},

Теперь django будет обслуживать мою страницу index.html, но все остальное в каталоге my/static/может извлечь выгоду из CDN.