Назад | Перейти на главную страницу

как мне настроить среду разработки веб-приложений для упрощения перехода в производство?

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

Учитывая, что у меня будет полный / корневой контроль над производственными серверами, следует ли мне вместо этого настроить среду разработки на физическом или виртуальном сервере? Если да, могу ли я просто преобразовать / создать образ / импортировать мою виртуальную машину разработчика VirtualBox / VMware (или P2V) на виртуальную машину в облаке, или мне придется вручную имитировать среду (т.е. установить ту же самую ОС, программное обеспечение, библиотеки , компоненты, патчи и т. д.) машины разработчика (и скопируйте / SVN на сайт и БД)? Если нет, то как лучше всего настроить серверы разработки для облегчения перехода в реальном времени?

Прежде всего, ведите текущий журнал любых изменений, которые вы делаете на своем сервере, это называется Runbook. Некоторые вещи, которые нужно отслеживать вручную:

  1. Уровни версий важных пакетов. Язык, библиотеки и пакеты баз данных.
  2. Расположение всех важных каталогов и путей.
  3. Перечислите все внешние зависимости.

Во-вторых, используйте сценарии для определения всех переменных среды и настройки системы. В противном случае, по крайней мере, ведите записи.

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

В-четвертых, храните резервные копии, сохраняйте действительно очень хорошие резервные копии. Испытайте их.

Остальное очень зависит от вашего развертывания. Настройка на виртуальном или физическом сервере полностью зависит от нагрузки ввода-вывода (ввода-вывода) в вашей сети, на диске и в памяти. Это может быть только количественно определено с течением времени, так что графите столько, сколько сможете.

Прежде всего, делайте вещи модульными и повторяемыми.

(Спасибо @bittrance за комментарий!)

Вот несколько примеров «использования сценария для настройки переменных среды».

Исходя из предположения, что мы говорим о целых машинах (физических или виртуальных) для производственной среды (а не, скажем, Google App Engine), моя лучшая практика:

Приложите дополнительные усилия, чтобы создать надлежащую упаковку для своего программного обеспечения. Например, при разработке Java, нацеленной на RedHat, используйте / напишите инструменты Maven, которые создают пакеты RPM. Для вашей базы данных, для всех изменений и включите их в RPM, и либо сделайте так, чтобы они применялись автоматически, либо создайте небольшой инструмент, который применяет их для вас. По сути, все готово, когда сервер можно установить / обновить с помощью одной команды. Да, это означает включение файлов конфигурации, адаптированных к этой системе.

Это немного лишняя работа, но в конечном итоге она того стоит.

После того, как вы правильно упаковали свое программное обеспечение, вопрос о dev / staging / demo серверов больше не так важен, потому что вы всегда можете создать другой. А с правильными установщиками вы точно знаете, какие изменения нужно сделать на машине, чтобы она работала должным образом.

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

Если вы расскажете нам немного больше о соответствующих инструментах OS / dev, я могу дать вам более конкретные советы.

РЕДАКТИРОВАТЬ: PHP / MySQL. Предполагая, что это ЛАМПА.

Создайте deb / rpm с вашим кодом PHP, который зависит от различных пакетов Apache, mysql, mod_ssl, php, которые вам нужны. Посмотрите на другие пакеты приложений PHP на этой платформе для вдохновения. Как правило, вы не хотите, чтобы пакет зависел от базы данных, потому что база данных может находиться в другом поле.

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

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

EDIT2: Как создать пакет Debian из дерева каталогов.

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

файлы управления / контроль:

Package: coolapp
Version: 1.0.0-2
Architecture: i386
Maintainer: Skunkworks Dept <bittrance@example.com>
Depends: apache2 (>= 2.2.16)
Section: contrib/libs
Priority: optional
Description: My Cool App
 It's going to revolutionize, yo!

файлы управления / файлы:

etc/coolapp/settings.conf

Учитывая эти два, используйте этот сценарий под названием mkdeb:

#!/bin/bash

CONTROLDIR=$1
shift
SOURCEDIR=$1
shift
INCLUDES=$*
BUILD=/var/tmp/mkdeb

CONTROLFILE=$CONTROLDIR/control
PKGNAME=$(grep -E '^Package:' $CONTROLFILE | awk '{ print $2 }')
PKGVERSION=$(grep -E '^Version:' $CONTROLFILE | awk '{ print $2 }')
PKGARCH=$(grep -E '^Architecture:' $CONTROLFILE | awk '{ print $2 }')

FILENAME=$PWD/${PKGNAME}_${PKGVERSION}_${PKGARCH}.deb

rm -rf $BUILD && install -d $BUILD
tar -C $SOURCEDIR -zcf $BUILD/data.tar.gz $INCLUDES
# Proper debian packages have md5 sums for all their files
(cd $SOURCEDIR && find $INCLUDES -type f | xargs md5sum > $BUILD/md5sums)
metadata=
for f in control prerm postrm preinst postinst templates conffiles ; do
    if [ -f $CONTROLDIR/$f ] ; then
        cp $CONTROLDIR/$f $BUILD
        chmod a+x $BUILD/$f
        metadata="$metadata $f"
    fi
done

# Metadata and stuff
tar -C $BUILD -zcf $BUILD/control.tar.gz md5sums $metadata
echo 2.0 > $BUILD/debian-binary
(cd $BUILD && ar rc $FILENAME debian-binary control.tar.gz data.tar.gz)

Вот так:

mkdeb ./controlfiles ./build .

  1. Сохраните основной дистрибутив dev и живите так же. Например, если live будет экземплярами ubuntu 10.10 ec2, то dev должен быть средой ubuntu 10.10, даже если это означает запуск виртуальной машины на вашем (mac) ноутбуке. Еще лучше, чтобы он был таким же, как вживую, чтобы уравновесить даже проблемы с сетевым подключением.

  2. Настройте эти два сервера / среды с помощью инструмента управления конфигурацией (марионетка / шеф-повар), чтобы он самодокументировался и воспроизводился. Они работают так же хорошо, если даже проще, на одном сервере. Вы можете начать с простого кретина с одного гигантского рецепта, в котором есть несколько хаков if-dev / else-live. Сохраните эти рецепты в своей системе контроля версий вместе с кодом.

  3. храните свой код где-нибудь отдельно в системе управления версиями, может быть локальным, как установка trac / svnserve, или может быть размещен как github. Просто отдельно, где-нибудь, что совсем не связано с обслуживанием конечных пользователей. Напишите очень простой сценарий для развертывания вашего приложения из этой системы контроля версий. Это может быть просто сценарий оболочки с 3 или 4 строками bash, соединенными вместе, начните с простого, сохраните его в самом контроле версий и повторяйте по мере необходимости.

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

Использование вашей общей учетной записи для работы разработчиков, вероятно, является наихудшим вариантом, поскольку вряд ли она будет хоть сколько-нибудь близка к той же конфигурации, что и конечный рабочий сервер (ы) e. Я предлагаю настроить локальный компьютер как можно ближе к клону вашей окончательной целевой конфигурации. Что касается физического и виртуального, если виртуальный обеспечивает адекватную производительность для ваших нужд, нет причин переходить на физический.

Если вы создаете локальный клон своей целевой машины, когда придет время, буквально просто вопрос копирования файлов, конечно, гарантируя, что разрешения установлены правильно на целевой машине. Затем сделайте дамп ваших баз данных и загрузите их в целевой объект. Нет ничего проще.