Посты с тэгом deployment


Поднимаем сложный проект на Django с использованием Docker


Добрый день, коллеги.

Сегодня я расскажу о не совсем простой концепции быстрого (до часа после нескольких тренировок) развёртывания проекта для работы команды, состоящей как минимум из отдельных фронтенд и бэкенд разработчиков.

Исходные данные у нас такие: начинается разработка проекта, в которой планируется «тонкий бэкенд». Т.е. бэк у нас состоит из закешированных страниц (рендерятся любым шаблонизатором), объёмных моделей с сопутствующей логикой (ORM) и REST API, выполняющего роль контроллера. Фактически, View в такой системе редуцировано и вынесено в JS, благо есть разные реакты, ангуляры и прочие вещи, которые позволяют фронтендщикам считать себя «белыми людьми».
Читать дальше →


Поднимаем сложный проект на Django с использованием Docker


Добрый день, коллеги.

Сегодня я расскажу о не совсем простой концепции быстрого (до часа после нескольких тренировок) развёртывания проекта для работы команды, состоящей как минимум из отдельных фронтенд и бэкенд разработчиков.

Исходные данные у нас такие: начинается разработка проекта, в которой планируется «тонкий бэкенд». Т.е. бэк у нас состоит из закешированных страниц (рендерятся любым шаблонизатором), объёмных моделей с сопутствующей логикой (ORM) и REST API, выполняющего роль контроллера. Фактически, View в такой системе редуцировано и вынесено в JS, благо есть разные реакты, ангуляры и прочие вещи, которые позволяют фронтендщикам считать себя «белыми людьми».

Читать дальше →


[recovery mode] Мысли о развёртывании веб-приложений на тестовом сервере


Предисловие


Нижеследующий текст − результат практического опыта и самообразовательных порывов человека, не имеющего систематического образования ни в одной из областей, о которых он (то есть я) берётся рассуждать. Поэтому заумные рассуждения здесь будут перемежаться банальностями. Бейте меня за первые и игнорируйте вторые. Для кого-то и они могут стать откровением.

Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится. Буду ориентироваться на ситуацию, когда деплоить приходится часто, то есть на сервере живёт проект в стадии активной разработки либо несколько проектов на разных стадиях. Проектами занимаются разные разработчики или команды, поэтому проекты нужно изолировать друг от друга. Но сервер внутренний, поэтому такая степень изоляции и автоматизации процессов администрирования, как на серверах под сдачу в аренду, не нужна.

Основной упор я буду делать на применение разных верс


[Перевод] Мега-Учебник Flask, Часть 18: Развертывание на Heroku Cloud


Это восемнадцатая статья в серии, где я описываю свой опыт написания веб-приложения на Python с использованием микрофреймворка Flask.

Цель данного руководства — разработать довольно функциональное приложение-микроблог, которое я за полным отсутствием оригинальности решил назвать microblog.



[Перевод] Мега-Учебник Flask, Часть 17: Развертывание на Linux (и даже на Raspberry Pi!)


Это семнадцатая статья в серии, где я описываю свой опыт написания веб-приложения на Python с использованием микрофреймворка Flask.

Цель данного руководства — разработать довольно функциональное приложение-микроблог, которое я за полным отсутствием оригинальности решил назвать microblog.



[Перевод] Python на колёсах


Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm, который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setu


[Из песочницы] Выкладка python-проектов с помощью pip и wheel

Привет, Хабрахабр!

В этом посте я буду говорить о выкладке Python-проектов: о том как положить на сервер код и все требуемые сторонние модули. Многие из нас сталкивались с проблемой развертки проекта на боевой машине, но на хабре об этом мало пишут; я хочу поделиться своим опытом.



Читать дальше →



Питон в коробке – venv в python 3.3

Наверняка, большинство из тех, кто разрабатывает или деплоит Python приложения, использует виртуальные окружения. В частности через virtualenv, написанный Ian Bicking.

Идея оказалась так хороша и распостранена, что нечно похожее теперь присутствует в Python 3.3 из коробки в виде модуля venv. Он почти такой же, как virtualenv, только немного лучше. Читать дальше →



[Из песочницы] Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Доброе время суток, уважаемые читатели!

Ниже приведена увлекательная(?) история о том как наша организация решала проблему т.н. «деплоймента как у людей». Наш основной язык разработки Python, с примесями разных интересных (и не очень) пакетов (Django, Bottle, Flask, PIL, ZMQ, и т.д.).

Начнём с краткого описания одного из наших приложений:

  • Django 1.4
  • MySQL
  • Celery для крон-имитации и поддержки вспомогательных функций в фоновом режиме
  • Daemon-процесс, основанный на Django management command


Всё это дело работает под связкой gUnicorn и nginx, на ОС CentOS 5.8.

Детали, как принято, ниже.

Читать дальше →


Django Framework / Плавный перезапуск FastCGI-процессов — django_graceful

Из всех способов деплоинга django-проектов мой любимый — FastCGI. Он поддерживается большинством веб-серверов, позволяет внятно разграничить права доступа и имеет массу других преимуществ.

Однако в django его реализация не лишена недостатков. Чтобы запустить FastCGI-сервер нужно выполнить «./manage.py runfcgi» с немаленьким количеством параметров, которые если и можно запомнить, то точно не захочется писать каждый раз руками. А если это происходит в контексте обновления кода проекта на боевом сервере, то команд становится ещё больше. Приходится писать различные wrapper-ы для запуска и перезапуска, которые засоряют проект.