Статья описывает один из способов развертывания Django-проектов, в связке Nginx + uWSGI на Unix-подобных операционных системах. Тестирование, а так же дальнейшая рабочая эксплуатация производилась на FreeBSD, однако на Linux процесс будет схож, за исключением некоторых незначительных моментов.

Хочу поделиться опытом настройки сервера для django-проектов. Так вышло, что мне часто приходится настраивать с нуля VPS-сервера для запуска на них django-сайтов. Как-то мне в голову пришла идея записать пошагово процесс настройки. Оказалось, что “по бумажке” выполнять эти рутинные операции гораздо проще и быстрее — все нюансы записаны, трудно что-то упустить. Дальше больше — я превратил инструкцию в самостоятельный shell-скрипт — запустил и сервер готов. Я думаю, некоторым python-разработчикам, особенно начинающим, будет полезно ознакомиться с содержимым скрипта. С некоторыми доработками вы, возможно, захотите использовать его в своей практике.

Сегодня появилась приятная новость о том, что отныне uWSGI сервер поддерживает PHP. Нет, на уровне GGI он поддерживал и раньше, но это не идёт ни в какое сравнение с поддержкой на уровне ядра самого uWSGI.

Некоторое время назад озадачился поиском способа развертывания проектов Django, к которому предъявлялись два требования:

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

По второму пункту мой выбор склонился в пользу Nginx + uWSGI. По первому же, из рассмотренных мною вариантов больше всего понравились обвязки для uWSGI в Debian.

Чтобы управлять доступом можно использовать различные решения gitosys, gitolite, mercurial-server, но эти решения работают через SSH, что не всегда удобно (должен быть ключ). В добавок не хватает гибкости у подобных решений.

Основные требования:

• доступ по логину/паролю (HTTPS)
• контроль прав на чтение/запись
• публичный/приватный репозиторий
• управления всем через веб интерфейс
• все данные (информация о проекте и пользователях) должны храниться в базе (MySQL)

Для решения этой задачи сделал следующую систему…

Под катом много букв, но не беспокойтесь — вы всех их знаете.

Всем наверно известен замечательный OpenSource проект Trac, позволяющий организовать рабочий процесс при разработке программного обеспечения. Однако его развертывание и настройка является не простой задачей. Информация в интернете разрозненная и часто уже устаревшая. В этом я смог сам убедиться настраивая Trac интегрированный с Gitolite на связке Nginx+UWSGI.

После небольшой увертюры с бубном у меня родился этот документ являющийся практически пошаговой инструкцией по развертыванию проекта Trac. Надеюсь это пригодится кому-нибудь еще.

Задача: развернуть несколько django-проектов, использующих разные версии django и разные версии питона на одном сервере.

Инструкция приводится для ОС Ubuntu 12.04.

Перед вами руководство по настройке production окружения для Django. Здесь будут описаны необходимые шаги по настройке Django, uWSGI и nginx. Руководство охватывает все три компонента — полный стек серверного ПО для веб-приложений.

Подразумевается, что вы используете Unix-подобную операционную систему и менеджер пакетов, эквивалентный aptitude. Найти эквивалент aptitude почти для любой операционной системы, в том числе и для Mac OS X, для вас не составит никакого труда.

Руководство написно для версий Django 1.4 или выше. Если вы используете более раннюю версию, то вам придется самостоятельно найти wsgi модуль для нее. Также вы заметите, что файловая структура проекта будет немного отличаться от представленной здесь.

Общая идея

Веб-сервер может по запросу отдавать пользователям файлы из своей файловой системы, однако он не может напрямую работать с Djangо приложениями. Веб-серверу нужен интерфейс, который будет запускать Django приложение, передавать ему запрос от пользователя и возвращать ответ.

Для выполнения этих задач был разработан Web Server Gateway Interface — WSGI — стандарт взаимодействия Python программ и веб-сервра.

uWSGI — одна из реализаций WSGI. В этом руководстве мы установим и настроим uWSGI для создания Unix сокета и взаимодействия с веб-сервером по протоколу WSGI.

Введение

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

Исторически сложилось, что скрипты на PHP запускаются при каждом HTTP-запросе. Запускаясь, скрипт проводит какую-то инициализацию (например, устанавливает соединение с СУБД), после чего анализирует запрос и формирует ответ. Однако, всем прекрасно известно, что в мире Python и Ruby принят другой подход: веб-приложения на этих языках загружаются в память единовременно вместе с веб-сервером (или сервером приложений). Взаимодействие сервера приложений со скриптом осуществляется при помощи стандартных интерфейсов WSGI и Rack. Такой подход, безусловно, не лишён недостатков, главный из которых, пожалуй, связан с резким ростом накладных расходов при размещении большого числа сайтов на одном сервере, однако, обладает и важным преимуществом: инициализация производится лишь однократно, затем скрипт лишь отвечает на входящие HTTP-запросы.

«В жизни каждого Django-разработчика наступает момент, когда он решительно рвет со своим прошлым, лишенным функционального тестирования!»

Об этом и поговорим.

Когда проектируешь масштабируемые системы, где приходится обращаться ко множеству внешних компонентов, например, использование стороннего API, отправка почты или конвертация видео, лучшим способом реализации является асинхронная модель с системой очередей, которая является связующим звеном для взаимодействия всех компонентов системы.

Самой популярной системой очередей в Python является Celery, она обладает широким набором возможностей по управлению задачами. К сожалению, системы на базе Celery сложно поддерживать в работоспособном состоянии, и когда что-то идёт не так, то найти проблему бывает весьма не просто. Можете спросить любого девопса об опыте работы с Celery, но будьте готовы услышать не очень приятные слова.

К счастью, есть альтернативное решение — uWSGI Spooler, и в этой статье я расскажу о нём подробнее.

Возможно, вы уже слышали про компанию Booking.com, что они много экспериментируют и часто деплоятся без тестирования. И еще, что есть один большой репозиторий на 4 Гб, в нем 4 миллиона строчек перлового кода, и вообще монолитная архитектура.

В то же самое время Booking.com меняется. Нельзя сказать, что это кардинальное скачкообразное изменение, но медленное и уверенное преображение. Меняется стек, постепенно внедряется Java в тех местах, где это актуально. В том числе термин сервис-ориентированная архитектура (SOA) слышится все чаще и чаще во внутренних дискуссиях.

Далее рассказ Ивана Круглова (@vian) об этих изменениях с точки зрения взаимодействия внутренних компонентов на Highload Junior ++ 2017. Попав в западню циклически зависимых воркеров пришлось качественно разобраться, что к чему, и какими средствами можно все это исправить.

Данная статья является переводом статьи Кевина Голдберга «An Introduction to Python WSGI Servers: Part 1» blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 с небольшими дополнениями от переводчика

Краткая история серверов WSGI Python

WSGI-серверы появились потому, что веб-серверы в то время не умели взаимодействовать с приложениями, написанными на языке Python. WSGI (произносится как «whiz-gee» с твердым «g») был разработан Филиппом Дж. Эби (вместе с Ян Бикинг и др.) В начале 2000-х годов. Модуль Apache, известный как mod_python, разработанный Григорием Трубецким в конце 90-х годов, на тот момент обрабатывал большую часть Python-приложений. Однако mod_python не был официальной спецификацией. Он был просто создан, чтобы разработчики могли запускать код Python на сервере. К сожалению, такой подход был небезопасным и разработчики начали искать новое решение.

WSGI(Web-Server Gateway Interface) является потомком CGI(Common Gateway Interface). Когда веб начал развиваться, CGI разрастался из-за поддержки огромного количества языков и из-за отсутствия других решений. Однако, такое решение было медленным и ограниченным. WSGI был разработан как интерфейс для маршрутизации запросов от веб-серверов(Apache, Nginx и т.д.) на веб-приложения.

Данная статья является переводом статьи Кевина Голдберга «A Performance Analysis of Python WSGI Servers: Part 2» dzone.com/articles/a-performance-analysis-of-python-wsgi-servers-part с небольшими дополнениями от переводчика.

Введение

В первой части этой серии Вы познакомились с WSGI и с шестью наиболее популярными по мнению автора WSGI-серверами. В этой части Вам будет показан результат анализа производительности этих серверов. С этой целью была создана специальная тестовая песочница.

На прошлой неделе был опубликован перевод статьи двухлетней давности Анализ производительности WSGI-серверов: Часть вторая, где незаслужено был обделен славой uWSGI.

Необходимо срочно перепроверить тесты!

На днях состоялся Moscow Python Meetup #66 — сообщество продолжает обсуждать актуальные инструменты, которые усиливают язык и адаптируют его к разным окружениям. В том числе на митапе прозвучал и мой доклад. Меня зовут Наиль, я делаю Яндекс.Коннект.



Рассказ, который я подготовил, был посвящён uWSGI. Это многофункциональный сервер веб-приложений, а каждое современное приложение сопровождается метриками. Я постарался показать, как возможности uWSGI способны помочь в сборе метрик.

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

Доброго времени суток, хабровчане!

Появилось свободное время, и возникло желание сделать небольшую веб-приложение. Идея есть (получать данные с метеодатчика, хранить в БД и потом делать что-то интересное), свободный сервер на centos тоже. Туториалов по настройке вроде бы тоже… Но на момент написания ни одного полностью рабочего не нашлось. Если вы тоже хотите развернуть приложение на сервере CentOS 7.4 используя связку python3.*, uwsgi и nginx, добро пожаловать под кат.