Дополнения разработки Django [закрываются]

Question

Дополнения разработки Django [закрываются]

Отказ от ответственности: я написал Vagrant! Но поскольку я написал Vagrant, я провожу большую часть своего времени в мире DevOps, который включает в себя программное обеспечение, такое как Docker. Я работаю со многими компаниями, использующими Vagrant, и многие используют Docker, и я вижу, как они взаимодействуют.

Прежде чем говорить слишком много, скажу прямой ответ: в вашем конкретном сценарии (вы работаете один, работаете над Linux, используете Docker в работе), вы можете придерживаться только Docker и упростить вещи. Во многих других сценариях (я обсуждаю далее) это не так просто.

Неправильно сравнивать Вагранта с Докером. В некоторых сценариях они перекрываются, а в подавляющем большинстве - нет. На самом деле, более подходящим сравнением будет Vagrant, а не что-то вроде Boot2Docker (минимальная ОС, которая может запускать Docker). Vagrant на уровень выше Docker с точки зрения абстракций, поэтому в большинстве случаев это несправедливое сравнение.

Vagrant запускает приложения для запуска приложений / сервисов с целью разработки. Это может быть на VirtualBox, VMware. Он может быть удаленным, как AWS, OpenStack. Внутри них, если вы используете контейнеры, Vagrant не заботится об этом, и принимает это: он может, например, автоматически устанавливать, извлекать, собирать и запускать контейнеры Docker. В Vagrant 1.6 Vagrant имеет среды разработки на основе докеров и поддерживает использование Docker с тем же рабочим процессом, что и Vagrant, в Linux, Mac и Windows. Вагрант не пытается заменить Docker здесь, он охватывает практики Docker.

Docker специально запускает Docker-контейнеры. Если вы сравниваете непосредственно с Vagrant: это, в частности, более конкретное (может только запускать Docker-контейнеры), менее гибкое (требует где-то Linux или Linux-хост) решение. Конечно, если вы говорите о производстве или CI, нет никакого сравнения с Vagrant! Vagrant не живет в этих средах, и поэтому следует использовать Docker.

Если ваша организация использует только контейнеры Docker для всех своих проектов и в ней работают только разработчики под Linux, тогда, конечно, Docker может сработать для вас!

В противном случае, я не вижу пользы от попытки использовать Docker в одиночку, поскольку вы теряете многое из того, что может предложить Vagrant, что дает реальные преимущества для бизнеса / производительности:

Обращаясь к конкретным встречным аргументам, которые я слышал в пользу использования Docker вместо Vagrant:

«Это менее подвижные части» - да, это может быть , если вы используете Docker исключительно для каждого проекта. Даже в этом случае он жертвует гибкостью для блокировки Docker. Если вы когда-нибудь решите не использовать Docker для какого-либо проекта, прошлого, настоящего или будущего, у вас будет больше движущихся частей. Если вы использовали Vagrant, у вас есть одна движущаяся часть, которая поддерживает остальные.
"Это быстрее!" - Если у вас есть хост, на котором можно запускать контейнеры Linux, Docker определенно быстрее запускает контейнер, чем любая виртуальная машина для запуска. Но запуск виртуальной машины (или удаленной машины) стоит единовременно. В течение дня большинство пользователей Vagrant никогда не уничтожают свои виртуальные машины. Это странная оптимизация для сред разработки. На производстве, где Docker действительно сияет, я понимаю необходимость быстрого вращения контейнеров вверх / вниз.

Я надеюсь, теперь ясно, что очень трудно, и я считаю, не правильно, сравнивать Докер с Вагрантом. Для сред разработки Vagrant является более абстрактным, более общим. Docker (и различные способы заставить его вести себя как Vagrant) - это особый вариант использования Vagrant, игнорирующий все остальное, что может предложить Vagrant.

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

Надеюсь, это прояснит ситуацию!

5

python django

задан Peter Mortensen 14 January 2012 в 07:36

5 ответов

Другие вопросы по тегам:

python django

Похожие вопросы:

score 1 · Answer 1

Я обнаружил, что django-logging очень помогает при разработке

1

ответ дан 14 December 2019 в 01:15

score 1 · Answer 2

from IPython.Shell import IPShellEmbed
ipshell = IPShellEmbed()

ipshell() # This call anywhere in your program will start IPython.

Таким образом, когда вы находитесь в представлении, вы можете войти в командную строку и изучить его. Все необходимые модели в любом случае будут импортированы и являются простой заменой shell_plus . На мой взгляд, он даже заменяет runserver_plus из django-command-extensions .

(Поскольку я нашел то, что часто использую, это не распространенная идея, я ответил на нее сам .)

score 3 · Answer 3

Я использую django-extensions в каждом проекте. Там много вещей, которые я никогда не использую, но это того стоит только для команд управления shell_plus и runserver_plus .

Shell_plus просто автоматически загружает все ваши модели: значительно экономит время ( РЕДАКТИРОВАТЬ : забыл кое-что не менее важное: он также использует ipython , если он установлен, для завершения табуляции и других удобств). Runserver_plus (требуется Werkzeug) предоставляет интерактивную страницу отладки ошибок 500. Вы можете перейти в консоль AJAX в любой момент трассировки - великолепно.

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

обновление : встроенная оболочка управления Django также теперь использует IPython, если он доступен. И относительно легко создать профиль пользователя IPython для автоматического импорта моделей и всего остального, что вы хотите автоматически импортировать. Я больше не использую django-extension.

score 3 · Answer 4

С одной стороны, я люблю раздражающий django метод render_to .

@render_to('template.html')
def foo(request):
    bar = Bar.objects.all() 
    return {'bar': bar}

# equivalent to
def foo(request):
    bar = Bar.objects.all() 
    return render_to_response('template.html',
                              {'bar': bar},
                              context_instance=RequestContext(request))

Я не использовал ни один из других все же, хотя я смотрел на django-debug-toolbar.

score 0 · Answer 5

Единственный наиболее полезный аддон для разработки Django, который мы используем, - это django-evolution . Это решение для обновления схемы, которое требует значительного количества ручной работы по внесению изменений в существующие модели. Это сэкономило мне бесчисленное количество часов работы.