У нас есть несколько приложений Python 2.6, работающих на Linux. Некоторые из них являются веб-приложениями Опор, другие являются просто продолжительными процессами, которые мы выполняем от использования командной строки nohup
. Мы также используем virtualenv
, и в разработке и в производстве. Что лучший способ состоит в том, чтобы развернуть эти приложения на рабочем сервере?
В разработке мы просто получаем исходное дерево в любой каталог, настраиваем virtualenv и работаем - достаточно легкий. Мы могли сделать то же в производстве и возможно который действительно является наиболее практическим решением, но это просто чувствует немного неправильное работать svn update
в производстве. Мы также попробовали fab
, но это просто никогда не работает в первый раз. Для каждого приложения что-то еще идет не так, как надо. Это ударяет меня, что целый процесс просто слишком труден, учитывая, что то, чего мы пытаемся достигнуть, существенно очень просто. Вот то, что мы хотим от процесса развертывания.
Это - действительно это! Как трудно это может быть?
Разработка и развертывание кода Python значительно облегчается благодаря setuptools в сочетании с virtualenv и pip.
Самая сложная часть, как я обнаружил, это запуск среды разработки, которая как можно точнее повторяет развернутую установку, и в то же время уважает инструменты и идиомы Pythonic. Но оказалось, что этого очень легко добиться с помощью pip и setuptools, которые вместе позволяют "установить" дерево разработки в среду Python без перемещения файлов. (На самом деле setuptools делает это сам по себе, но pip действует как front end для лучшей обработки зависимостей.)
Другой ключевой вопрос - подготовка чистой среды с известным набором пакетов для обеих сред. Virtualenv Python - просто находка в этом отношении, позволяющая вам настроить полностью индивидуальную среду Python с вашим собственным выбором пакетов, не требуя root-доступа, пакетов ОС (rpm или dpkg), и не будучи ограниченным пакетами и их версиями, которые установлены в вашем дистрибутиве.
Наконец, одним из раздражающих недостатков является сложность создания скриптов командной строки, которые хорошо работают с PYTHON_PATH. С этим довольно элегантно справляется setuptools.
(Чтобы не усложнять ситуацию, здесь даны довольно подробные указания. Не стесняйтесь отклоняться от них по мере необходимости.)
Из рабочего каталога создайте новое виртуальное окружение Python:
$ python /virtualenv.py venv
Вы захотите выполнять большую часть своей работы из этой виртуальной среды. Для этого используйте эту команду (.
- это сокращение для source
):
$ . venv/bin/activate
Установите pip:
$ easy_install pip
Создайте каталоги для каждого устанавливаемого пакета, который вы хотите создать.
Когда ваша древовидная структура готова, вы почти готовы приступить к кодированию. Но сейчас пакеты, зависящие друг от друга, не видят друг друга так, как они будут видеться в развернутой среде. Эта проблема решается с помощью маленькой хитрости, которую предлагает setuptools и которую использует pip. Для каждого пакета, который вы разрабатываете, выполните следующую команду (убедитесь, что вы находитесь в виртуальной среде вашего проекта, как указано в шаге 3 выше):
$ pip install -e pkg1
Эта команда установит pkg1
в вашу виртуальную среду, причем без копирования каких-либо файлов. Она просто добавляет ссылку в каталог site-packages
, указывающую на корень разработки пакета, и создает каталог egg-info в этом корне. Вы также можете сделать это без pip, следующим образом:
$ cd pkg1
$ python setup.py develop
И это обычно работает, но если у вас есть сторонние зависимости (которые должны быть указаны в setup.py, как объясняется здесь в документации по setuptools), pip будет умнее в их поиске.
Одна оговорка: ни setuptools, ни pip не умеют находить зависимости среди ваших собственных пакетов. Если PkgB в каталоге B зависит от PkgA в каталоге A, то pip install -e B
потерпит неудачу, потому что pip не знает, что PkgA можно найти в каталоге A; вместо этого он попытается загрузить PkgA из его онлайн-репозитория. Обходной путь - просто установить каждый пакет после его зависимостей.
На этом этапе вы можете запустить python, загрузить один из ваших модулей и начать с ним возиться. Вы можете редактировать код, и он будет сразу же доступен при следующем импорте.
Наконец, если вы хотите создать инструменты командной строки с вашими пакетами. Не пишите их вручную. В итоге вы получите ужасный беспорядок из хаков PYTHON_PATH, который никогда не будет работать должным образом. Просто прочитайте о автоматическом создании скриптов в документации по setuptools. Это избавит вас от многих проблем.
Когда ваши пакеты готовы к работе, вы можете использовать setup.py для создания пакетов развертывания. Здесь слишком много вариантов, но следующие должны помочь вам начать:
$ cd pkg1
$ python setup.py --help
$ python setup.py --help-commands
Из-за широкой природы вопроса этот ответ будет неполным. Я не рассматривал долго работающие серверы, веб-фреймворки и сам процесс установки (в частности, использование --index-url
в pip install для управления частным репозиторием сторонних и внутренних пакетов и -e vcs+....
, который будет извлекать пакеты из svn, git, hg или bzr). Но я надеюсь, что дал вам достаточно веревки, чтобы связать все это вместе (только не повесьтесь на ней:-).
Я работаю над реализацией этого для наших рабочих проектов. Здесь задействовано несколько разных частей.
Во-первых, мы настраиваем virtualenv.py, используя их возможности начальной загрузки, чтобы добавить ваши собственные пользовательские функции и флаги после создания. Это позволяет нам определять общие типы проектов, а также дает нам единую команду для создания нового виртуального сервера, извлечения проекта из репозитория git и установки любых требований в виртуальный сервер с помощью файлов pip и requirements.txt .
поэтому наши команды выглядят так: python venv.py --no-site-packages -g $ git_proj -t $ tag_num $ venv_dir
http://pypi.python.org/pypi/ virtualenv http://pip.openplans.org/
Теперь мы проводим первоначальную проверку существующего проекта. По мере работы и обновления проекта мы используем команды структуры в каждом проекте для создания выпусков, а затем для их развертывания:
http://docs.fabfile.org/0.9.0/
У меня есть потрясающая команда : make_tag, который проверяет наличие неиспользуемых коммитов, открывает файлы, которым необходимо обновить строки версии, строит и загружает документы sphinx, а затем фиксирует последний тег в репозитории.
Обратной стороной является команда fab deploy, которая через ssh выполняет git co указанного тега, запускает обновление pip для любых новых требований, выполняет любые необходимые миграции базы данных, а затем сбрасывает веб-сервер, если это необходимо. веб-приложение.
Вот пример функции тегов: http://www.google.com/codesearch/p?hl=en#9tLIXCbI4vU/fabfile.py&q=fabfile.py%20git%20tag_new_version&sa = N & cd = 1 & ct = rc & l = 143
Есть масса хороших файлов структуры, которые вы можете просмотреть с помощью поиска по коду Google.Я знаю, что несколько обманул для себя.
Это определенно сложно и состоит из нескольких частей, чтобы все работало гладко. Однако, как только вы его запустите, гибкость и скорость работы просто потрясающие.
Посмотрите на Buildout для воспроизводимых развертываний.
Еще один голос за fabric (еще не пробовал Buildout). Мы успешно используем его уже несколько месяцев.
Если у вас проблемы с тканью, другой вариант - Capistrano. Работает отлично (даже для приложений без rails). Перестал использовать его только потому, что мне кажется странным использовать Ruby для развертывания приложений на Python ;)
Это действительно несложно. Вам нужно играть в основном с buildout и supervisord IMO.
Хотя изучение buildout может занять немного времени, но оно того стоит, учитывая количество боли, которую он уменьшает при повторных настройках.
О nohup: подход nohup не подходит для серьезных развертываний. У меня очень хороший опыт работы с supervisord. Это отличное решение для запуска производственных python-приложений. Его очень легко настроить.
Некоторые конкретные ответы ниже.
Я бы использовал rsync для внешней синхронизации с вашего производственного «основного» сервера на другие и с вашей «бета-тестовой» платформы на производственный «основной» сервер.
rsync имеет преимущество копирования только тех файлов, которые изменились, и копирования только частей файлов, которые изменились частично, и проверки целостности и идентичности содержимого в конце на всех машинах. Обновление, которое выполняется частично и прерывается, можно легко продолжить позже, что сделает ваше развертывание более надежным.
Subversion или Mercurial в этом случае тоже были бы неплохой идеей. У Mercurial есть преимущество в том, что вы можете "тянуть" или "проталкивать" вместо простого обновления из одного центрального источника. Вы можете найти интересные случаи, когда децентрализованная модель (ртутная) работает лучше.
если вы специалист по наращиванию, то вам следует знать о возможности minitage.recipe.scripts создать файл для настройки вашего питона. среда. Исходный код для вашего веб-сервера, и ваша сборка полностью переносима.