Sollte der server/Datenbank-config-Dateien, einschließlich Kennwörter, gespeichert in source control?

Gibt es nicht nur eine "silver bullet" Antwort hier, und es würde alles stark davon abhängen details.

Erste von allen, halte ich für die beste Praxis zu trennen, alle source Codes von der Konfiguration in separaten repository. Also, der Quellcode bleibt source code, aber die installation oder Bereitstellung (mit Konfiguration, Passwörter, etc) ist das was ganz anderes. Auf diese Weise werden Sie fest separaten Entwickler zu den Aufgaben von Systemadministratoren' Aufgaben können und letztlich bauen 2 verschiedene teams dabei, was Sie gut sind.

Wenn man getrennte source-code-repository + Bereitstellung repository am besten, als Nächstes Wetten, erwägt Optionen für die Bereitstellung. Am besten so wie ich das sehe ist hier, mithilfe der Bereitstellungs-Verfahren typisch für eine gewählte Betriebssystem (d.h. Gebäude der autonomen Pakete für eine gewählte OS die Art und Weise, dass OS die Betreuer tun).

Zum Beispiel, Red Hat-oder Debian-packaging-Verfahren bedeuten in der Regel greifen einen tarball von software von externen Seite (das wäre dann exportieren von Quellen aus Ihrem source-code VCS), Auspacken, zusammenstellen und vorbereiten der Pakete für die Bereitstellung bereit. Bereitstellung selbst sollte im Idealfall bedeuten, nur tun, eine schnelle & einfache Befehl, der die Pakete installieren, wie rpm -U package.rpm, dpkg --install package.deb oder apt-get dist-upgrade (gegeben, dass Ihr Paket gehen, um ein repository, in dem apt-get wäre in der Lage, Sie zu finden).

Offensichtlich, um es zu bekommen auf diese Weise arbeiten, werden Sie zu liefern haben alle Konfigurations-Dateien für alle Komponenten einer Anlage in einem voll funktionsfähigen Zustand, inklusive aller Adressen und Anmeldeinformationen.

Bekommen, kurz, wir betrachten eine typische "kleine service" - situation: eine PHP-Anwendung bereitgestellt, über n Anwendungsservern mit apache /mod_php, Zugriff auf m MySQL-Server. Alle diese Server (oder virtuelle Container, das spielt eigentlich keine Rolle) befinden sich in einem geschützten privaten Netzwerk. Um dieses Beispiel zu vereinfachen, nehmen wir an, dass alle echten internet-Konnektivität wird angeführt von einem cluster von k http-Beschleuniger /reverse proxies (wie nginx /lighttpd /apache), die sehr leichte Konfiguration (nur interne IPs weiterleiten zu können).

Was haben wir mit Ihnen verbunden zu sein und voll arbeiten?

• MySQL-Server: einrichten, IPs/Hostnamen, einrichten der Datenbanken, bieten Anmeldungen & Passwörter
• PHP-Anwendung: einrichten von IPs/Hostnamen, Konfigurationsdatei erstellen, die erwähnen, MySQL-Server IPs, logins, Passwörter & Datenbanken

Beachten Sie, dass es 2 verschiedene "Arten" von Informationen hier: IPs/Hostnamen ist etwas fester, würden Sie wahrscheinlich wollen, weisen Sie Sie ein für alle mal. Anmeldungen & Passwörter (und sogar Datenbank-Namen), auf der anderen Seite, sind nur für connectivity-Zwecke hier - um sicherzustellen, dass für MySQL, dass es wirklich unsere PHP-Anwendung eine Verbindung zu es. Also, meine Empfehlungen hier wären-splitting-diese 2 "Arten":

• "Dauerhafte" Informationen, wie IP-Adressen, die gespeichert werden soll in einigen VCS (anders als die source-code VCS)
• "Transiente" Daten, wie Passwörter zwischen 2 Anwendungen sollte nie gespeichert werden, sondern wird bei der Generierung von deployment-Paketen.

Den letzten und schwierigsten Frage bleibt hier: erstellen von deployment packages? Es sind mehrere Techniken verfügbar, die 2 wichtigsten Arten sind:

• Exportierten Quellcode von VCS1 + "permanente" Konfiguration von " VCS2 + building script von VCS3 = Pakete
• Source-code ist in VCS1; " VCS2 ist ein verteiltes version control (z.B. git oder hg), die im wesentlichen enthält "Abspaltungen" von VCS1 + Konfigurationsinformationen + building-Skripts generieren kann . Mir persönlich gefällt dieser Ansatz besser, es ist viel kürzer und letztlich einfacher zu bedienen, aber die Lernkurve ist vielleicht ein bisschen steiler, vor allem für die admin-Jungs, die müssen master git oder hg für Sie.

Für ein Beispiel vor, ich würde erstellen Sie Pakete wie:

• my-application-php - das würde davon abhängen, mod_php, apache und würden generierten Datei wie /etc/my-php-application/config.inc.php, die auch die MySQL-Datenbank IPs/Hostnamen und login /Passwort generiert, wie md5(current source code revision + salt). Dieses Paket installiert werden würde, auf jeden n application Server. Idealerweise sollte es in der Lage sein, die Installation auf einem sauber installierten Betriebssystem und stellen Sie eine voll funktionsfähige Anwendung, die cluster-Knoten ohne manuelle Tätigkeit.
• my-application-mysql - das würde davon abhängen, MySQL-server und umfassen würde, die post-install-Skript, dass:
  • startet den MySQL-server und stellt sicher, wird es beginnen, automatisch auf OS starten
  • verbindet zum MySQL-server
  • überprüft, ob die benötigte Datenbank existiert
  • wenn keine - erstellt die Datenbank, startet es mit Inhalt und erstellt login mit Passwort (das gleiche logins & Kennwörter generiert /etc/my-php-application/config.inc.php mit md5-Algorithmus)
  • wenn ja - eine Verbindung zur Datenbank herstellt, gilt Migrationen, um es zu bringen bis zu der neuen version, tötet alle, die älter logins /Passwörter und stellt das neue login/Passwort-paar (wieder, generiert mithilfe von md5(revision + Salz) - Methode)

Schließlich sollte es bringen, den nutzen eines Upgrades für Ihre Bereitstellung Verwendung von einfachen Befehl wie generate-packages && ssh-all apt-get dist-upgrade. Auch müssen Sie nicht speichern, inter-Anwendungen, die Passwörter überall und Sie regeneriert bei jedem update.

Dieses relativ einfache Beispiel zeigt eine Menge von Methoden, die Sie einsetzen können, hier, aber, schließlich, es ' s bis zu Ihnen zu entscheiden, welche Lösung besser ist hier und das ist overkill. Wenn Sie weitere Informationen hier oder als eine separate Frage, ich werde gerne versuchen, in details zu erhalten.

Passwörter sollten nicht gespeichert werden, in die Quellcodeverwaltung ein. An alle. Je. Sehen Wie Sie zu halten Geheimnisse geheim

Passwörter, Servernamen passiert, etc. sind Teil des deployment-Konfiguration erfolgt durch den server-administrator. Es ist wichtig zu dokumentieren, dieses Verfahren und legen Sie die dokumentierte Prozedur unter Kontrolle.

Alternativ können Sie die deployment-Konfiguration kann durchgeführt werden, indem ein Skript, dass die sysadmin-würde Sie ausführen, um die Konfiguration durchgeführt, und während der script-Ausführung, so fragt der sysadmin die erforderlichen Informationen zu geben. Wieder dieses Skript gehalten werden muss, um in der Versionskontrolle.

Alles andere, abgesehen von server-Konfigurations - muss werden in der Quellcodeverwaltung.

Speicherung der server-Konfiguration im source-control ist allgemein eine schlechte Idee, weil es wird in der Weise von Bereitstellungen und kann dazu führen, kleine Katastrophen (z.B. wenn jemand nicht bewusst ist, dass Ihre test-version, bereitgestellt von der Quelle Kontrolle ist die Kommunikation mit einem live-Dienst).

Immer diese Konfigurations-Dateien außerhalb des webroot-Verzeichnisses.

Vertrauenswürdige verbindungen kann eine option sein, so dass bekannte IP-Adressen eine Verbindung zu services durch Konfiguration des Dienstes..

• Bei der Ausführung auf Windows-integrierte Authentifizierung verwenden. Finden Sie Die Sicherung Der Daten Zugriff
• MySQL so konfigurieren kann, dass verbindungen von localhost und nicht erfordern ein Passwort. Sehen Schritt 7: Sicherung der MySQL-Server auf Windows
• PostgreSQL können Sie ~/.pgpass.

Ich denke, diese Frage ist mehr über die Informationen, die Eigenverantwortung, Vertrauen und Organisation. Sollten Sie sich Fragen, was Teil Ihres Unternehmens würden Sie Vertrauen, um halten Sie Ihre system-Passwörter sicher vor Offenlegung und Missbrauch?

Ich habe in Organisationen, in denen Sie gehalten wurden durch die Verantwortlichen für das business. In anderen haben Sie delegiert wurde, an das operations-team, das auch im Besitz der Prozesse rund um die Erstellung und Nutzung usw.

Das wichtigste ist, dass es klar definiert ist, die in Ihrer Organisation, die Zugriff auf system-Passwörter. Danach können Sie entscheiden, auf entsprechende technische Lösungen für den Schutz der Passwörter.

In meinem Subversion-repos für die PHP-Konfigurations-Dateien, die enthalten Passwörter werden überprüft, in wie config.php.sample mit hinweisen auf das, was bereitgestellt werden muss und Skripte angewiesen erfordern eine config.php an der gleichen Stelle.

Repository konfiguriert ist, zu ignorieren config.php für das Verzeichnis zu vermeiden, "zufälligen", fügt oder check-ins.

Probleme mit Passwörtern im Quellcode:

• schwer zu unterscheiden von einer Implementierung zu einer anderen (will ich nicht ändern müssen, um source-code in der Produktion)
• erhöhte Wahrscheinlichkeit des versehentlichen beschädigen von Produktions-Datenbank, wenn dabei die Entwicklung
• Frage der Sicherheit (in den meisten Geschäften gibt es keinen Grund für code/Entwickler wissen, prod Passwörter)
• geänderte Passwort erfordert eine Umschichtung

Was ich gefunden habe funktioniert am besten mit einem config überprüft, die verwendet Mischung sane defaults und Platzhalter für die Bereitstellung bestimmter Daten. Unsere apps immer nach einem system-config die es erlaubt das überschreiben von Variablen. Dies ermöglicht die Herstellung der Maschine zu haben, eine config-geeignet für es-Bereitstellung.

Hinweis: Wenn ich die Funktion als admin-ich Schaffe es immer configs getrennt von code (aus gutem Grund).

Ohne eine richtige build-Prozess, ich bin mit dieser Strategie (für PHP-apps):

1. Einen Ordner /etc/companyname

2. In es, Platz zwei Dateien:

   <?php //env.php
   return 'prod'; 

   <?php //appname-prod.php
   return array(
     'db' => array( /* credentials */ ),
     /* other host-specific conf data */
   ); 

3. Machen beide Dateien lesbar nur durch Ihre PHP-Prozess

Nun Ihre app config-Datei wird so etwas wie:

<?php //config.php
$env = (require "/etc/companyname/env.php");
$creds = (require "/etc/companyname/appname-{$env}.php");

In diesem Ort, die Umgebung definiert die Anmeldeinformationen verwendet, und Sie können verschieben von code zwischen vorkonfigurierte Umgebungen (und die Kontrolle über einige Optionen, mit $env). Dies, natürlich, kann man mit server-Umgebungs-Variablen, aber das a) ist einfacher, um das setup und b) nicht aussetzen Anmeldeinformationen zu jedem Skript auf dem server (wird nicht zeigen, bis in eine streunende debugging-junk wie phpinfo()).

Für das Lesen zu vereinfachen, die außerhalb von PHP können Sie den credential-Dateien, JSON-oder etwas, und nur die kleinen Leistungseinbruch (APC wird nicht cache lassen).