Server Umgebung für Webentwickler

[mmrd22]

Hallo liebe Debianer

ich verwalte einen internen Server für Webentwickler und biete momentan folgende Dienste für diese an:

• - Apache (Webserver)

• - PHP

• - Git

• - SSH

Der SSH Dienst ist vor allem zur Authentifizierung über Schlüssel eingerichtet. Soweit so gut. Das Setup funktioniert soweit gut.

Jetzt suche ich eine neue Lösung. Eine Umgebung für Webentwickler zu verwalten ist gar nicht so einfach bei folgenden Vorraussetzungen:

• Webserver

• Datenbank

• Versionskontrolle

• Vorschau

Gibt es für so etwas gute Guidelines oder gar fertige Lösung. Habe kein Problem mir selber etwas zusammen zu basteln, aber weiss zum Beispiel nicht wie ich ein Preview System aufbereite in dem die Entwickler ihr Webprojekt inklusive Datenbank Zugriff testen können.
Wenn Sie überhaupt die Datenbank nicht als Dump in Git integrieren..

Bin dankbar für alle Tipps & Hinweise.

[TRex]

Ganz schön viel Fragen, die hier offen bleiben.

1. Was ist an der aktuellen Lösung problematisch?
2a. Wie deployen die Entwickler ihr Projekt?
2b. Ist das Projekt an irgendwelche Dienste hart gekoppelt?
3. Was meinst du mit Vorschau?

Meine Vorstellung wäre, dass die Kameraden ihre Entwicklungsumgebung nahezu identisch zur Produktionsumgebung aufsetzen, oder zumindest maximal identisch (zB keine Komprimierung der Javascript-Dateien), und das hochgradig automatisiert (Stichwort continuous delivery).

[novalix]

Kurze Antwort: Kommt drauf an.

Persönlich bin ich Anhänger der logischen Trennung verschiedener Instanzen. Ich mache das mit Linux Containern.
Ein dedizierter Datenbank-Container ist Pflicht.
Falls Deine Devs über PHPMyAdmin auf die Datenbanken zugreifen, kann man dafür auch einen eigenen Container einrichten.
Komplexere Projekte (Webshops o.Ä.) bekommen eine Art Staging-Container mit dedizierter Datenbank, der möglichst nah am Live-Server konfiguriert ist.
Die "wilde" Entwicklung findet in anderen Containern statt.
Eine interne Zone mit sauberen Administrationsroutinen um Subdomains zu verwalten, erleichtert die Sache mittelfristig.
PHP V-Hosts laufen bei mir unter fcgid oder php-fpm. Jeder V-Host bekommt seinen eigenen User mit eigener php.ini und Session-Verwaltung.
Das Anlegen läßt sich nach und nach über einfache Skripte und Template-Dateien (php.ini, virt-host.conf, etc.) automatisieren.
Letztlich musst Du aber wissen, welche Anforderungen exakt erfüllt werden müssen.
Da ich "Mädchen für Alles" bin, kann ich mir halt alles so einrichten, wie ich es brauche und mich hinterher bei mir selber darüber beschweren, was das denn nun bitte wieder für ein unmögliches Setup ist. So kann ich jedenfalls nicht arbeiten.

HTH, niels

[mmrd22]

Vielen Dank für die Antworten!

zu TRex:
Es findet wildes Entwickeln am Live-System statt, da intern die Projekte nicht einsehbar sind.
Das heisst, Entwickler bastelt sein Projekt bei sich lokal oder sogar direkt beim Kunden als Subdomain und pusht dann sein Ergebnis auf den Git Server.
Das Problem weiss ich zu lösen -> Erziehung!
Ich darf diese Zugänge nicht freigeben und muss diesen den Workflow über Testserver & Git aufzwingen.

Aber zu 3. ich muss lokal das System so bereitstellen, dass mehrere Entwickler intern das System über einen internen Server wirklich fertigstellen und somit auch einsehen können. Im Moment liegt das Projekt auf dem Git Server und dieser schiebt einen Klone an einen Ort, von welchem der Webserver(Apache) diesen intern einsehbar macht(http://git-server/repo/webprojekt1). Aber leider hab ich noch keine Datenbank integration.

Zu novalix:
Ui, ergibt alles Sinn. An Container hab ich überhaupt nicht gedacht. Ich bin so zu sagen auch das Mädchen für alles und persönlich mit der Momentanen Lösung nicht zufrieden. Daher habe ich viele Freiheiten, solange die Produktion nicht an mir scheitert
Muss mich erst zu Containern ausgiebig informieren. Bisher nur von "Docker" & "LXC" etwas aufgeschnappt.

Benutzt du dann in den Containern überhaupt Git? Bzw. benötigt man überhaupt Git?

[novalix]

Git (oder ein anderes verteiltes SCM) ist sicherlich sehr vorteilhaft, wenn mehrere Entwickler, die damit umgehen können, an einem Projekt arbeiten. Als reines Deployment-Tool ist es aber ein wenig viel Overhead. Da tut's auch FTP
Auch hier ist es davon abhängig wie Ihr konkret arbeitet bzw. arbeiten wollt.
Ein Entwicklungsserver ist in so einem Setup ja auch so etwas wie ein zentrales Repo und irgendjemand sollte dann auch den Hut auf haben, um zu entscheiden, was nach master gemerged wird.
Ansonsten spricht aber nichts dagegen, daß die einzelnen Devs ihre jeweiligen Branches auf dem Rechner testen.