Pile de lampe multi-développeur idéale?

Question

Je voudrais construire une pile de développement de lampe «idéale».

• double Server (virtualisé, ESX)
  • Apache/PHP sur une, les bases de données (MySQL, PgSQL, etc.) sur l'autre.
• Utilisateur (développeur) Mini environnements gérables, ou instance.
  • Chaque instance de développeur partage la configuration de haut niveau (modules disponibles et configuration par défaut, etc.)
  • Un développeur doit avoir le contrôle sur leur version de php et apache pour chaque projet.
  • Un développeur peut être en mesure de modifier des paramètres mineurs, c.-à-d. Des guillemets pour le code existant.
  • Chaque projet déterminera son fournisseur de base de données dans son code

L'idée est qu'il est un serveur Administrer-mesure que je peux contrôler, et de fournir les choses globalement configurées comme APC, Memcached, XDebug etc. Ensuite, en passant à des sous-ensembles pour chaque projet, je peux permettre à mes utilisateurs de contrôler rapidement leurs environnements pour divers projets. Essentiellement, je propose le système typique d'un développeur exécutant sa propre pile sur sa propre machine, mais centralisée. De cette façon, j'espère éviter des problèmes comme les problèmes de code de Cross OS, les incohérences de base de données, les installations légèrement différentes produisant des bugs, etc. être génial d'avoir une grande partie de celui-ci géré avec une sorte de gestion des paquets. Nous utilisons généralement CentOS, alors miam?

Est-ce que quelqu'un a déjà construit quelque chose comme ça avant? Y a-t-il quelque chose de clé en main qui ressemble à ce que j'ai décrit? Y a-t-il des guides utiles que je devrais lire pour construire quelque chose comme ça?

Answer 1

Mon point de vue sur la question, je ne pense pas qu'il couvre tous vos besoins, mais il est assez proche:

• Avoir un serveur CentOS avec pile LAMP (yum install apache2 mysql php, etc.) - ou 2 serveurs un httpd et un mysqld
• Pour n développeurs ont n dossiers avec n hôtes virtuels www.developer-n.com sur l'hôte qui a exécuté le serveur Apache
• Chaque développeur monte son dossier serveur (par exemple //192.168 .0.1/home/developer-n/www) sur la machine locale via CIFS dans/etc/fstab de la station locale et édite les fichiers depuis local la machine fonctionne encore les sur le serveur (unique)
• Chaque mini-environnement de développement est peaufiné par .htaccess

Answer 2

OK, la façon dont nous avons été le développement de la configuration en cours d'exécution à mon LAMP emploi précédent, était comme ça. Un seul serveur exécutant MySQL et Apache.Chaque développeur reçoit une adresse IP sur le serveur (la machine exécute plusieurs IP sur la même interface, toutes les IP sont sur le même sous-réseau), de sorte que chaque développeur peut avoir au moins un hôte virtuel IP et autant de noms basés sur ils veulent (notre site web utilise SSL, donc nous avions besoin d'adresses IP séparées, wigthout SSL, vous pouvez vous en sortir avec une adresse IP unique et des noms basés sur vhosts). De cette manière, le serveur DNS local desservait les enregistrements génériques A * .john.dev.company IN A 10.1.1.123, où 10.1.1.123 était l'adresse IP attribuée à John. De cette façon, John pouvait définir autant de vhosts basés sur les noms qu'il le souhaitait et ils seraient tous résolus correctement tant qu'ils se termineraient tous dans john.dev.company (comme project1.john.dev.company). Chaque développeur avait son propre fichier de configuration apache avec ses hôtes virtuels et nous avons utilisé la directive Include pour extraire tous ces fichiers dans la configuration principale d'Apache. Les autorisations étaient définies, donc ces fichiers de configuration seraient éditables par les développeurs respectifs et chaque développeur avait un lien logiciel vers leur config dans leur répertoire personnel. De plus, chaque développeur était autorisé à utiliser sudo pour redémarrer Apache. L'inconvénient de cette configuration était que de temps en temps un développeur particulier planterait tout le serveur en vissant leur fichier de configuration. Nous avons utilisé une base de données commune, puisque tout le monde travaillait sur un seul projet, mais il ne devrait pas être difficile de configurer plusieurs bases de données individuelles.