Идеальная стопка лампы мультиразработчика?

Я хотел бы создать 'идеальную' стопку разработки лампы.

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

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

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

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

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

9
задан jhogendorn 13 April 2010 в 15:33
поделиться

2 ответа

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

  • Иметь сервер 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 локальной станции и редактирует файлы с локального компьютера, но запускает их на (уникальном) сервере
  • Каждый разработчик mini -среда настраивается через .htaccess
0
ответ дан 3 November 2019 в 08:19
поделиться

Хорошо, на моей предыдущей работе мы выполняли установку 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. Обратной стороной этой настройки было то, что время от времени конкретный разработчик мог вывести из строя весь сервер, испортив свой файл конфигурации. Мы использовали общую базу данных, поскольку все работали над одним проектом, но настроить несколько отдельных баз данных не составит труда.

3
ответ дан 3 November 2019 в 08:19
поделиться
Другие вопросы по тегам:

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