Ich würde gerne einen "idealen" Lampenentwicklungsstapel bauen.
Die Idee ist, dass es ein administrierbarer Server ist, den ich steuern kann, und global konfigurierte Dinge wie APC, Memcached, XDebug etc. zur Verfügung stelle. Indem ich Subsets für jedes Projekt hinzufüge, kann ich meinen Benutzern erlauben, ihre zu kontrollieren Umgebungen für verschiedene Projekte.
Im Wesentlichen schlage ich das typische System eines Entwicklers vor, der seinen eigenen Stack auf seiner eigenen Maschine ausführt, aber zentralisiert. Auf diese Weise würde ich hoffen, Probleme wie Probleme mit dem Cross-OS-Code, Inkonsistenzen in der Datenbank, leicht unterschiedliche Installationen, die zu Fehlern führen, zu vermeiden.
Ich bin froh, dies in benutzerdefinierten Builds von der Quelle zu verwalten, aber wenn es möglich ist, wäre es großartig, einen großen Teil davon mit einer Art Paketverwaltung zu verwalten. Wir verwenden normalerweise CentOS, also yum?
Hat schon mal jemand so etwas gebaut? Gibt es etwas Turnkey, das dem ähnlich ist, was ich beschrieben habe? Gibt es irgendwelche nützlichen Anleitungen, die ich lesen sollte, um so etwas zu bauen?
OK, die Art und Weise, wie wir die Entwicklungs-LAMP-Einrichtung bei meinem vorherigen Job ausgeführt haben, war so. Ein einzelner Server, auf dem sowohl MySQL als auch Apache laufen. Jedem Entwickler wird auf dem Server eine IP-Adresse zugewiesen (der Computer führt mehrere IPs auf derselben Schnittstelle aus, alle IPs befinden sich im selben Subnetz), sodass jeder Entwickler über mindestens einen IP-basierten virtuellen Host und so viele namensbasierte verfügen kann Sie wollen (unsere Website verwendet SSL, also benötigten wir separate IPs, watthout SSL, Sie können mit einer einzigen IP und Namen basierten Vhosts). Wir hatten lokalen DNS-Server, der Platzhalter-A-Einträge für jeden Entwickler auf diese Weise lieferte * .john.dev.company IN A 10.1.1.123, wo 10.1.1.123 eine IP-Adresse für John zugewiesen wurde. Auf diese Weise konnte John so viele namensbasierte Vhosts definieren, wie er wollte, und sie würden alle korrekt aufgelöst werden, solange sie alle in john.dev.company enden (wie project1.john.dev.company). Jeder Entwickler hatte seine eigene Apache-Konfigurationsdatei mit ihren virtuellen Hosts darin und wir haben die Anweisung Include verwendet, um alle diese Dateien in die Apache-Hauptkonfiguration zu ziehen. Die Berechtigungen wurden festgelegt, sodass diese Konfigurationsdateien von den jeweiligen Entwicklern bearbeitet werden konnten und jeder Entwickler einen Softlink zu seiner Konfiguration in seinem Home-Verzeichnis hatte. Außerdem durfte jeder Entwickler sudo verwenden, um Apache neu zu starten. Der Nachteil dieses Setups war, dass ein bestimmter Entwickler den gesamten Server zum Absturz brachte, indem er seine Konfigurationsdatei vermasselte. Wir verwendeten eine gemeinsame Datenbank, da alle an einem einzigen Projekt arbeiteten, aber es sollte nicht schwierig sein, mehrere einzelne Datenbanken einzurichten.
Ich nehme das Problem an, ich glaube nicht, dass es alle Ihre Anforderungen abdeckt, aber es ist ziemlich nah dran: