Рестарт supervisorctl во время деплоя

Проект, над которым сейчас работаю, развернут на базе Gunicorn + NGINX + Supervisor. Этот вариант деплоя требует перезапуска проекта с правами суперпользователя после обновления исходников.


supervisorctl restart myproject

Это несколько неудобно, так как обновление проекта производится под выделенной учетной записью myproject, а потом приходится логиниться в root. Проблема решается добавлением пользователя myproject в /etc/sudoers, но аккуратно, руководствуясь принципом предоставления необходимого минимума привилегий.


myproject ALL = (root) NOPASSWD:/usr/bin/supervisorctl restart myproject

Настройка Django для отправки почты с mail.ru

Рабочие для меня настройки в settings.py получились такими:


EMAIL_HOST = 'smtp.mail.ru'
EMAIL_PORT = 2525
EMAIL_HOST_USER = 'site@mysite.ru'
EMAIL_HOST_PASSWORD = 'xxx'
EMAIL_USE_TLS = True
DEFAULT_FROM_EMAIL = 'site@mysite.ru'
SERVER_EMAIL = 'site@mysite.ru'

Внимание! Отправка почты на порт, указанный в их официальном хелпе (465, http://help.mail.ru/mail-help/mailer/popsmtp), глухо падала по таймауту.

Также немногим ранее выяснилось, что хостер locum.ru не позволяет коннектиться к внешним SMTP на 25 порту, так как данный порт прокинут на их собственный SMTP сервер.

Доступ к Django дев-серверу из локальной сети

Понадобилось мне произвести отладку сайта на реальном Android устройстве. Самый простой способ — попытаться открыть сайт по Wi-Fi сети, которую раздает роутер и к которой подключен мой ноутбук. С наскоку доступа к сайту по адресу вида 192.168.1.3:8000 получить не удалось. Тут нужно уточнить, что я обычно поднимаю дев-сервер на домене вида mysite.dev, который прописываю в /etc/hosts строкой 127.0.0.1 mysite.dev. Это дает возможность запоминать в браузере пароли при переключении между разными проектами и некоторые другие мелкие плюшки. То есть, фактически, в моем случае manage.py runserver поднимает веб-сервер на 127.0.0.1:8000, который доступен только с самой машины.

Для доступа же из вне дев-сервер нужно запускать так:


python manage.py runserver 192.168.1.3:8000

Или для одновременного доступа откуда угодно:


python manage.py runserver 0.0.0.0:8000

Настройка Django для отправки почты с Джино

Рабочие для меня настройки в settings.py получились такими:


EMAIL_HOST = 'smtp.jino.ru'
EMAIL_PORT = 587
EMAIL_HOST_USER = 'site@mysite.ru'
EMAIL_HOST_PASSWORD = 'xxx'
EMAIL_USE_TLS = True
DEFAULT_FROM_EMAIL = 'site@mysite.ru'
SERVER_EMAIL = 'site@mysite.ru'

Прежде чем пробовать подключится по SMTP, необходимо убедится, что платная услуга поддержки SMTP на аккаунте подключена и активирован доступ по SMTP в настройках ящика.

Резолвинг URL в Django-CMS

Довольно много времени потратил на решение проблемы с резолвингом URL в приложении, подключенном через apphook к Django-CMS. При том, что резолвинг в Django-консоли и при варианте подключения приложения напрямую к Django работал как надо. А вот Django-CMS URL-ы генерировать отказывалась и при прямом запросе страницы внутри приложения выдавала ошибку 404.

Разгадка крылась в пояснениях к релизу 2.4 — необходимо было добавить middleware ‘django.middleware.locale.LocaleMiddleware’ в settings проекта. Все это отголоски изменения работы с мультиязычностью в Django-CMS.

Актуально для Django-CMS 2.4.2 и Django>=1.4.

Установка дополнительных пакетов Ubuntu для разработки на Django

Python

sudo apt-get install python-dev python-pip
sudo -H pip install -U pip
sudo -H pip install -U virtualenv

MySQL

sudo apt-get install mysql-server python-mysqldb libmysqlclient-dev

PostgreSQL

sudo apt-get install libpq-dev postgresql postgresql-server-dev-all postgresql-contrib 

PostGIS

sudo apt-get install libgdal-dev postgresql-x.x-postgis-x.x postgresql-x.x-postgis-scripts

Pillow (PIL)

sudo apt-get install libjpeg-dev libpng-dev libwebp-dev libtiff-dev zlib1g-dev python-imaging

lxml

sudo apt-get install python-lxml libxml2 libxml2-dev libxslt-dev

Memcached

sudo apt-get install memcached libmemcached-dev

Redis

sudo apt-get install redis-server python-redis

bcrypt

sudo apt-get install bcrypt libffi-dev

Эффективное использование Django QuerySet

Эта статья перевод. Оригинал: Using Django querysets effectively.

Системы объектно-реляционного отображения (ORM) делают взаимодействие с базой данных SQL намного легче, но имеют репутацию неэффективных и значительно более медленных решений, чем «сырые» SQL запросы.
Эффективное использование ORM подразумевает некоторое понимание того, как система строит запросы к базе данных. В этой статье я опишу способы эффективного использования Django ORM системы для средних и огромных наборов данных.
Читать далее Эффективное использование Django QuerySet

Интеграция South в существующий Django-проект

Последовательность действий описана в документации.

1. Добавляем 'south' в INSTALLED_APPS.

2. Запускаем ./manage.py syncdb как обычно при установке нового приложения. С этого момента South переопределяет команду syncdb, заменяя ее своей реализацией. У syncd теперь подменяется вывод в консоль, а применяется она только к приложениям, не имеющим миграций.

3a. Запускаем ./manage.py convert_to_south myapp. convert_to_south является псевдонимом последовательности двух команд ./manage.py schemamigration myapp --initial и ./manage.py migrate myapp --fake.

3b. Тут следует обратить внимание на то, что convert_to_south отработает корректно только на вашей машине. На всех остальных машинах, после того как туда будут скопированы сценарии миграции, необходимо выполнить ./manage.py migrate 0001 myapp --fake перед накатыванием миграций.

Django: обновить только одно поле объекта модели

Иногда по каким-то причинам не хочется вызывать метод save() объекта модели. Например, если этот метод переопределен и в нем реализована тяжелая логика, а надо обновить только одно поле счетчика просмотров. В таком случае можно воспользоваться методом update() класса QuerySet с фильтрацией по первичному ключу.

Пример:

entry = get_object_or_404(Entry, slug=slug) 
Entry.objects.filter(pk=entry.pk).update(view_count=F('view_count') + 1)

Ошибка …’myapp_tags’ is not a valid tag library: Template library myapp_tags not found, tried…

Стоит проверить, что:
— в директории templatetags есть файл __init_.py
— приложение добавлено в INSTALLED_APPS
— если шаблонный тег приложения myapp вызывается из шаблона приложения otherapp, то в INSTALLED_APPS ‘myapp’ должно быть левее (выше) ‘otherapp’
— установлены все зависимости, необходимые в myapp_tags.py
— убедиться, что возможно импортировать сам myapp_tags.py


python manage.py shell
>>> from myapp.templatetags import myapp_tags

— сервер перезагружен после последнего изменения кода