Публикации с меткой «admin»

Чем меньше рутины мы привносим в свою работу, тем больше она может приносить удовольствия.

Сегодня я расскажу про автоматизированный деплойтинг в python. Это значит одной командой я могу залить на все продакшен сервера файлы, обновить на нем необходимые компоненты и перегрузить веб сервер, и наблюдать за этим откинувшись на кресле и попивать кофеек.

Я Вам расскажу про Fabric(На момент написания статьи 0.9.1 — бала последняя стабильная версия), наиболее подходящий для этого инструмент, который делает все описанное и даже больше через ssh.

Про установку рассказывать особо нечего, pip отлично справляется с этим.

В корень своего проекта я кладу fabfile.py, в этом файле и будут храниться все процедуры для работы с Fabric. Ниже приведу небольшой пример скрипта, который будет архивировать наш проект, заливать его на сервер и там разархивировать.

Если у Вас все получилось, а я очень надеюсь, что с этим хостом и именем пользователя не у кого кроме меня получиться ничего не может (так что поменяйте свою строку конекта во второй строке), то вы можете увидеть что-то сильно напоминающее вот это:

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

Кому лень вводить пароли могу добавить после второй сроки
env.password = ‘oh_its_my_real_password’

либо сгенерить себе файл с ссш ключом и путь к нему положить в
env.key_filename — в отличие и пароля тут может быть передан массив ключей

Но и этот код можно сократить. У Fabric есть contrib libs, одна из них project. Тут подробно каждую я описывать не буду, просто покажу пример с одной из них, дабы просто показать, что они есть

как видите наш код сократился до одной команды, не считая команду для тестирования Django проекта, ведь если какая-то команда возвратит ошибочный статус, то выполнения прекратится, а значит если тесты не проходят загрузка не начинается. Дополнительный параметр capture говорит о том, что необходимо скрывать выходные данные команды, мы эту опцию отключаем.

Вот основные команды, которые Вам необходимо знать, чтоб свободно пользоваться Fabric

put — копировать файл с локальной машины на удаленную. Доп параметр mode — устанавливает права на файл, см chmod
get — копировать файл с удаленной на локальную
local — выполнить команду на локальной машине. Доп параметр capture — скрывать выходные данные, по умолчанию False
run — выполнить команду на удаленной машине
sudo — выполнить команду на удаленной машине через судо. Доп параметр user — указываем имя пользователя, под которым необходимо запустить команду

Обратите внимание, что у нас есть команда sudo, а значит при необходимости, мы можем и сервак зарелоадить и вообще сделать любые админ вещи, главное, чтоб пользователь был в судоерсах.

Для деплойтинга на несколько серверов, причем различной конфигурации, и роли – у Fabric тоже кое-что припасено.

в этом примере заливка файлов будет идти сразу на 2 вебовых сервака. Как видите вы можете запланировать у себя роли отдельных серверов под БД, под медиа файл и т.д.

кроме как декоратаром роль можно указывать и при запуске процедуры

Иногда в момент или во время запуска необходимо передать данные скрипту.

В момент запуска это делается через аргументы самой функции

к примеру если у вас

то эти 2 аргумента можно передать как

Либо спросить что-то во время работы функции у пользователя функцией
prompt(text, key=None, default='', validate=None)

Задает вопрос пользователю с текстом text, если пользователь не вводит данные, то возвращает значение из default, предварительно отчищая его функцией validate, и возвращает как результат этой функции, если не передан key, иначе кладет значение в env[key]

А теперь примеры функций деплойтинга из реальной жизни, которые вы можете написать и у себя в проекте:

bounce_wsgi_procs — зарелоадить wsgi через touch в него
deploy_media — загружаем только медиа файлы
migrate — запускаем скрипт миграции через South
update_repositories - обновляем репозитарии
update_dependencies — устанавливаем зависимости
reload_nginx — перегружаем nginx
deploy — полная установка, последовательный запуск всех этих функций.

Подводя итоги могу сказать, что Fabric должна стать musthave tool в разработке.

Привет всем, в кои-то веки сподобился написать о Django.

Причём не общий пост, а решение конкретной мелкой задачки.

Итак, задача: Нужно ограничить количество записей в InlineModelAdmin.

Решение: По историческим причинам, иерархия классов в Django сильно различается для ModelAdmin и InlineModelAdmin:

Model <-(has)<- ModelAdmin ->(has)-> queryset

, но

Model <-(has)<- InlineModelAdmin ->(has)->
-> formset = BaseInlineFormSet ->(has)-> get_queryset

Итого:

class MyBaseInlineFormSet(BaseInlineFormSet):
    def get_queryset(self):
        sup = super(MyBaseInlineFormSet, self).get_queryset()
        return sup.order_by('-id')[:5]

reg_inline(A, B, formset = MyBaseInlineFormSet, extra = 5)

Где reg_inline это упрощенный способ сделать site.register с помощью моего http://github.com/buriy/django-superadmin

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

В версии 1.1 джангонавтам привалило счастье - групповые операции. Удаление кучки объектов теперь есть прямо из коробки. При этом, как обычно это бывает в django, использовать новый механизм легко и приятно - написание простенького action укладывается в две-три строчки. Больше того, action может не только как-то молча обрабатывать группу объектов, но и возвращать HttpResponse, в котором пользователь может проделать дополнительные действия.

Документация в качестве примера предлагает возвращать HttpResponseRedirect и передавать список обрабатываемых объектов в виде GET-параметра полноценной view для последующей самостоятельной работы. Однако, ничего не мешает использовать наш action в качестве view-функции.

Допустим у нас есть магазин, в котором товары разбиты по категориям:

class Category(models.Model):
    name = models.CharField(u'Наименование', max_length=100)

    def __unicode__(self):
        return self.name

class Product(models.Model):
    category = models.ForeignKey(Category, verbose_name=u'Категория')
    name = models.CharField(u'Наименование', max_length=100)
    price = models.DecimalField(u'Цена', max_digits=15, decimal_places=2)

Время от времени пользователю хочется перенести пачку товаров из одной категории в другую (к примеру разбили «Молоко» на «Молоко настоящее»/«Молочные продукты» и надо раскидать товары согласно указаниям санэпидстанции и угрызениям своей совести). Чтобы человек не мучался, выставляя каждому такому товару новую категорию, мы и напишем нехитрый action.

class CategoryForm(forms.Form):
    category = forms.ModelChoiceField(queryset=Category.objects.all())

class ProductAdmin(admin.ModelAdmin):
    list_display = ('name', 'price', 'category',)
    actions = ['set_category_action']

    def set_category_action(self, request, queryset):
        if 'do_action' in request.POST:
            form = CategoryForm(request.POST)
            if form.is_valid():
                queryset.update(category=form.cleaned_data['category'])
                # Ничего не возвращаем, это вернет нас на список товаров
                return
        else:
            form = CategoryForm()
        return render_to_response(
            'admin/shop/set_category.html',
            {'title': u'Укажите категорию, в которую надо переместить товары',
             'objects': queryset,
             'form': form},
            context_instance=RequestContext(request))
    set_category_action.short_description = u'Переместить в категорию'

Поддерживающий это дело set_category.html прост. Через hidden-поля action и _selected_action мы заставляем админку опять вызвать наш action, но на этот раз в POST попадают две дополнительные переменные: do_action (флажок, что мы пришли из формы) и category (та категория, которую надо назначить).

{% extends "admin/base_site.html" %}

{% block content %}

    <form action="" method="post">

        <input type="hidden" name="action" value="set_category_action">
        <input type="hidden" name="do_action" value="yes">

        <div>
            {{ form.category }}
            <input type="submit" class="default" style="float: none" value="Переместить">
            {{ form.category.errors }}
        </div>

        <h2>Товары для перемещения</h2>

        <ul>
            {% for object in objects %}
                <li>
                    <a href="{{ object.pk }}/">{{ object.name }}</a> - {{ object.category }}
                    <input type="hidden" name="_selected_action" value="{{ object.pk }}">
                </li>
            {% endfor %}
        </ul>

    </form>

{% endblock %}

Вот таким простым образом мы избавились от необходимости писать лишний view, самостоятельно выдергивать в нем список объектов, придумывать url и делать редирект на change list.

Практически в каждом django-проекте рано или поздно встает вопрос о генерировании превьюшек для картинок.  Одним из наиболее простых и удобных решений для этого является sorl.thumbnail.  Это приложение позволяет генерировать превьюшки либо прямо в шаблоне через тег {% thumbnail %}, либо используя в моделях специальное поле ImageWithThumbnailsField.  В подавляющем большинстве случаев этого достаточно, но иногда возникает необходимость получить превьюшку в python-коде прямо по месту, без переделывания моделей.

К примеру может захотеться видеть совсем маленькие, нигде больше не используемые превьюшки в списке объектов в админке. Делается это на удивление просто.

class PatternAdmin(admin.ModelAdmin):
    list_display = ('icon', '__unicode__',)
    list_display_links = ('__unicode__',)

    def icon(self, obj):
        from sorl.thumbnail.main import DjangoThumbnail
        thumbnail = DjangoThumbnail(obj.photo, (60, 60))
        return u'<img src="%s" border="0" alt="" width="%s" height="%s" />' % \
                            (thumbnail.absolute_url,
                             thumbnail.width(), thumbnail.height())
    icon.short_description = u'Фото'
    icon.allow_tags = True

В результате получаем вот такой список объектов: