Umgebungen und Geheimnisse: EXP_ENV und settings/override #

Diese Seite richtet sich an Entwickler, die Umgebungen mit APP_ENV umschalten, Geheimnisse in .env.local, in Rails-Credentials oder einem Vault aufbewahren und erwarten, dass sich dev, test und prod unterschiedlich verhalten. Exponential benennt die Umgebung einer Maschine mit einer einzigen Konstante, EXP_ENV, und erlaubt jeder Einstellungsdatei eine Variante dafür (Einstellungen pro Umgebung (EXP_ENV)).

Inhalt #

1. Die Umgebung benennen
2. Einstellungsvarianten
3. Was der Name ändert
4. Geheimnisse
5. Umgebungsvariablen
6. Im Vergleich mit anderen Frameworks

Die Umgebung benennen #

Kopieren Sie config.env.php.example im Stammverzeichnis der Installation nach config.env.php:

<?php
define( 'EXP_ENV', 'test' );

config.env.php wird von den Web-Einstiegspunkten und den Kommandozeilenskripten vor config.php gelesen, und die mitgelieferte .gitignore hält die Datei aus der Versionsverwaltung heraus. Ein Name besteht aus Kleinbuchstaben, Ziffern, - oder _, beginnt mit einem Buchstaben und hat höchstens 32 Zeichen; ein ungültiger Name wird so behandelt, als gäbe es keine Umgebung.

Einstellungsvarianten #

Der Umgebungsname steht direkt nach .ini:

Eine Variante wird in jeder Ebene direkt nach ihrer Standarddatei gelesen und überschreibt nur diese Ebene, sodass eine Siteaccess-Einstellung weiterhin gegen eine Basisvariante gewinnt. Jede Umgebung hat eigene INI-Cache-Dateien. Typische Varianten: der Mail-Transport (file außerhalb der Produktion), die Debug-Ausgabe, Hosts, die Solr-Adresse.

# settings/override/site.ini.test.append.php
<?php /*
[MailSettings]
Transport=file

[DebugSettings]
DebugOutput=enabled
*/ ?>

Was der Name ändert #

Templates lesen den Namen mit {exp_environment()}, PHP mit eZINI::environment() (der Name oder false). Die Administrationsdesigns admin4 und admin4l können die Umgebung als Plakette anzeigen (site.ini [AdminEnvironment] Level=auto). Anders als die dev-Umgebung von Symfony oder DEBUG in Django schaltet der Name von sich aus weder einen Profiler noch eine Debug-Toolbar ein: Diese schalten Sie in der Variantendatei der Umgebung ein.

Geheimnisse #

Niemals im Repository Ihrer Erweiterung, in einer .ini-Datei, die der Webserver ausliefern könnte, in Templates, Job-Nutzdaten, Logs, URLs oder Commit-Nachrichten. Liefern Sie jeden Schlüssel als leeren Wert mit einem Kommentar in der INI-Datei Ihrer Erweiterung aus und brechen Sie mit einer klaren Meldung ab, wenn er leer ist (Umgebungseinstellungen und Geheimnisse).

$key = eZINI::instance( 'expdemo.ini' )->variable( 'ArchiveSettings', 'ApiKey' );
if ( $key === '' )
    throw new RuntimeException( 'expdemo.ini [ArchiveSettings] ApiKey is not set; put it in settings/override/expdemo.ini.append.php' );

Umgebungsvariablen #

Einstellungen werden nicht aus Umgebungsvariablen gelesen, wie es %env(...)%, env() oder os.environ tun. Einige Umgebungsvariablen gibt es für bestimmte Zwecke, zum Beispiel EXP_DEMO_MODE=1 für öffentliche Demos (Umgebungsvariablen). Wenn Ihre Plattform Geheimnisse als Umgebungsvariablen einspeist, lesen Sie sie in Ihrem eigenen Code mit getenv() und dokumentieren Sie das, oder lassen Sie Ihr Deployment sie in settings/override/ schreiben.

Im Vergleich mit anderen Frameworks #

Verwandte Seiten #

• Konfiguration: INI-Dateien
• Einstellungen pro Umgebung (EXP_ENV)
• Sicherheitsstandard
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.