Идеальный стек светильников для нескольких разработчиков? - PullRequest
9 голосов
/ 14 апреля 2010

Я бы хотел создать «идеальный» стек разработки ламп.

  • Двойной сервер (виртуализированный, ESX)
    • Apache / PHP для одной, базы данных (MySQL, PgSQL и т. Д.) Для другой.
  • Пользователь (разработчик) Управляемая мини-среда или экземпляр.
    • Каждый экземпляр разработчика совместно использует конфигурацию верхнего уровня (доступные модули, конфигурацию по умолчанию и т. Д.)
    • Разработчик должен контролировать свои apache и php версию для каждого проекта.
    • Разработчик может изменить второстепенные настройки, т.е. использовать магические кавычки для устаревшего кода.
    • Каждый проект определяет своего поставщика базы данных в своем коде

Идея заключается в том, что я могу управлять этим сервером, способным администрировать, и предоставлять глобально сконфигурированные вещи, такие как APC, Memcached, XDebug и т. Д. Затем, переходя к подмножествам для каждого проекта, я могу позволить своим пользователям быстро контролировать свои среды для различных проектов.

По сути, я предлагаю типичную систему разработчика, использующую свой собственный стек на своей машине, но централизованный. Таким образом, я надеюсь избежать таких проблем, как проблемы с кросс-ОС, несоответствия базы данных, немного отличающиеся установки, приводящие к ошибкам и т. Д.

Я счастлив управлять этим в пользовательских сборках из исходного кода, но если это вообще возможно, было бы здорово, если бы большая его часть управлялась с помощью какого-либо управления пакетами. Мы обычно используем CentOS, так что?

Кто-нибудь когда-либо строил что-то подобное раньше? Есть ли что-то под ключ, похожее на то, что я описал? Есть ли какие-нибудь полезные руководства, которые я должен прочитать, чтобы создать что-то подобное?

Ответы [ 2 ]

3 голосов
/ 23 апреля 2010

Хорошо, то, как мы выполняли настройку LAMP разработки на моей предыдущей работе, было примерно таким. Один сервер работает под управлением MySQL и Apache. Каждому разработчику назначается IP-адрес на сервере (на компьютере запущено несколько IP-адресов на одном и том же интерфейсе, все IP-адреса находятся в одной подсети), поэтому у каждого разработчика может быть как минимум один виртуальный хост на основе IP и столько имен, сколько они хотят (наш веб-сайт использовал SSL, поэтому нам нужны были отдельные IP-адреса, без SSL, вы можете обойтись без одного IP-адреса и имени vhosts). У нас был локальный DNS-сервер, обслуживающий записи подстановочного знака A для каждого разработчика таким образом * .john.dev.company IN A 10.1.1.123, где 10.1.1.123 был IP-адрес, назначенный Джону. Таким образом, Джон мог определить столько имен, основанных на имени, сколько ему нужно, и все они будут правильно разрешены, если все они заканчиваются на john.dev.company (например, project1.john.dev.company). У каждого разработчика был свой конфигурационный файл apache со своими виртуальными хостами, и мы использовали директиву Include, чтобы включить все эти файлы в основную конфигурацию Apache. Разрешения были установлены, поэтому эти файлы конфигурации могли редактироваться соответствующими разработчиками, и у каждого разработчика была мягкая ссылка на их конфигурацию в их домашнем каталоге. Кроме того, каждому разработчику было разрешено использовать sudo для перезапуска Apache. Недостатком этой установки было то, что время от времени конкретный разработчик приводил к сбою всего сервера, испортив его файл конфигурации. Мы использовали общую базу данных, так как все работали над одним проектом, но не должно быть сложным настроить несколько отдельных баз данных.

0 голосов
/ 16 апреля 2010

Мой взгляд на проблему, я не думаю, что она охватывает все ваши требования, но она довольно близка:

  • Наличие сервера CentOS со стеком LAMP (yum install apache2 mysql php и т. Д.) - или 2 сервера: один httpd и один mysqld
  • Для n разработчиков имеется n папок с n виртуальными хостами www.developer-n.com на хосте, на котором работает сервер Apache
  • Каждый разработчик монтирует свою папку сервера (скажем, //192.168.0.1/home/developer-n/www) на локальном компьютере через CIFS в / etc / fstab локальной станции и редактирует файлы. с локальной машины, но запускает их на (уникальном) сервере
  • Каждая мини-среда разработчика настраивается через .htaccess
...