7.5 Umgebungseinstellungen
Environment
Im letzten Abschnitt wurde die Konfiguration der Datenbank besprochen. In diesem Abschnitt werden weitere Konfigurationsdateien vorgestellt. Eine Rails-Applikation wird in einer sogenannten Umgebung (engl. environment ) ausgeführt. Standardmäßig sieht Rails drei Umgebungen vor:
- Entwicklungsumgebung (development)
- Produktionsumgebung (production)
- Testumgebung (test)
Konfigurations- dateien
Für jede dieser drei Umgebungen befindet sich eine eigene Konfigurationsdatei (development.rb, production.rb und test.rb) im Verzeichnis config/environments.
Die Konfiguration der Umgebungen zur Laufzeit wird von zwei Dateien bestimmt: Der config/environment.rb, die Einstellungen enthält, die unabhängig von den Umgebungen sind, und der Konfigurationsdatei für die jeweilige Umgebung.
environment.rb
In der environment.rb können Sie Konstanten, die in allen Umgebungen Ihrer Applikation zur Verfügung stehen sollen, definieren.
# Pfad, in dem die hochgeladenen Bilder gespeichert werden. DIRECTORY_IMAGE_UPLOADS = "#{RAILS_ROOT}/public/image_uploads" # Anzahl Hotels, die pro Seite dargestellt werden HOTELS_PER_LIST = 10 # Betreff-Auswahlliste für Kontaktformular # (contactmessages/new) CONTACTMESSAGE_SUBJECTS = %w{Frage Reklamation Lob Kritik}
Subversion-Revision-Nr. |
Wenn Sie die aktuelle Revision-Nr. Ihres Subversion-Repository anzeigen möchten, können Sie sie über nachfolgenden Befehl in einer Konstanten speichern und in der gesamten Applikation verwenden, wo immer Sie möchten: APP_REVISION = IO.popen("svn info").readlines[4] |
Die Konfigurationsdateien der einzelnen Umgebungen sind standardmäßig nicht leer, sondern wie folgt konfiguriert:
Entwicklungsumgebung (development)
development.rb
Die Konfigurationsdatei der Entwicklungsumgebung development.rb im Verzeichnis config/environments ist standardmäßig so konfiguriert, dass die Applikation bei jeder Anfrage neu geladen wird. Das verzögert zwar die Reaktionszeit, hat aber den Vorteil, dass Sie nicht nach jeder Änderung am Code den Server neu starten müssen. Außerdem werden die Fehlermeldungen protokolliert, wenn Sie eine Methode auf einem nil -Objekt aufrufen. Es werden ausführliche Fehlermeldungen mit Codeauszügen angezeigt, und das Caching ist deaktiviert. Innerhalb der Entwicklungsumgebung wird standardmäßig ignoriert, wenn E-Mails aus der Applikation heraus nicht versendet werden können:
# Settings specified here will take precedence over those in # config/environment.rb # In the development environment your application's code is # reloaded on every request. # This slows down response time but is perfect for development # since you don't have to restart the webserver when you make # code changes. config.cache_classes = false # Log error messages when you accidentally call methods # on nil. config.whiny_nils = true # Show full error reports and disable caching config.action_controller.consider_all_requests_local = true config.action_view.debug_rjs = true config.action_controller.perform_caching = false config.action_view.cache_template_extensions = false # Don't care if the mailer can't send config.action_mailer.raise_delivery_errors = false
Wenn Sie die Rails-Applikation lokal mit ruby script/server oder ruby script/console starten, werden die Einstellungen aus der environment.rb im Verzeichnis config und der development.rb im Verzeichnis config/environments geladen.
Produktionsumgebung (production)
production.rb
Standardmäßig ist die Konfigurationsdatei der Produktionsumgebung config/environments/production.rb so konfiguriert, dass die Applikation nicht bei jeder Anfrage neu geladen wird. Das heißt, die Applikation muss bei jeder Code-Änderung neu gestartet werden. Statt ausführlicher Fehlermeldungen werden nur allgemeine Fehlermeldungen ohne Codeauszüge ausgegeben, und das Caching ist aktiviert.
Änderungen an View-Dateien werden nicht mehr erkannt |
Neu in Rails 2.0.2 ist, dass in der Produktionsumgebung (einstellbar durch monoconfig.action_view.cache_template_loading ) nicht bei jedem Zugriff auf die View-Dateien überprüft wird, ob diese sich geändert haben. Durch den verringerten Festplattenzugriff steigt die Performance der Applikation. Um Änderungen an View-Dateien wirksam zu machen, muss daher die Rails-Applikation neu gestartet werden. |
# Settings specified here will take precedence over those in # config/environment.rb # The production environment is meant for finished, "live" # apps. Code is not reloaded between requests config.cache_classes = true # Use a different logger for distributed setups # config.logger = SyslogLogger.new # Full error reports are disabled and caching is turned on config.action_controller.consider_all_requests_local = false config.action_controller.perform_caching = true config.action_view.cache_template_loading = true # Enable serving of images, stylesheets, and javascripts from # an asset server # config.action_controller.asset_host = # "http://assets.example.com" # Disable delivery errors, bad email addresses will be ignored # config.action_mailer.raise_delivery_errors = false
Wenn Sie die Applikation lokal mit ruby script/server -e production oder ruby script/console production starten, werden die Einstellungen aus der config/environment.rb und der production.rb im Verzeichnis config/environments geladen.
Testumgebung (test)
test.rb
Die Testumgebung config/environments/test.rb dient ausschließlich zum Ausführen der Testklassen(siehe Kapitel 6). Sie werden sie nie in einem anderen Kontext benötigen. Während der Ausführung der Tests wird die Datenbank immer wieder verändert und zurückgesetzt.
Standardmäßig ist die Testumgebung so konfiguriert, dass die Applikation nicht bei jeder Anfrage neu geladen wird. Die Fehlermeldungen, wenn eine Methode auf ein nil -Objekt angewendet wird, werden protokolliert. Es werden ausführliche Fehlermeldungen mit Codeauszügen ausgegeben, und das Caching ist deaktiviert. Darüber hinaus ist der Schutz vor CSRF- Angriffen (siehe Kapitel 17) deaktiviert. E-Mails werden nicht real verschickt, sondern in ein Array ausgegeben:
# Settings specified here will take precedence over those in # config/environment.rb # The test environment is used exclusively to run your # application's test suite. # You never need to work with it otherwise. Remember that # your test database is "scratch space" for the test suite # and is wiped and recreated between test runs. # Don't rely on the data there! config.cache_classes = true # Log error messages when you accidentally call methods on # nil. config.whiny_nils = true # Show full error reports and disable caching config.action_controller.consider_all_requests_local = true config.action_controller.perform_caching = false # Disable request forgery protection in test environment config.action_controller.allow_forgery_protection = false # Tell ActionMailer not to deliver emails to the real world. # The :test delivery method accumulates sent emails in the # ActionMailer::Base.deliveries array. config.action_mailer.delivery_method = :test
Zum Ausführen der Testklassen wird die Applikation mit den Einstellungen aus der config/environment.rb und der test.rb im Verzeichnis config/environments geladen.
Eigene Umgebungen anlegen
Die drei gezeigten Umgebungen development, production und test sind die Umgebungen, die standardmäßig von Rails erzeugt werden. Aber selbstverständlich können Sie zusätzlich eigene Umgebungen definieren.
staging
Eine beliebte zusätzliche Umgebung ist z. B. die staging -Umgebung (zu Deutsch: Arbeitsbühne), die dazu dient, die Veröffentlichung der Applikation zu testen.
Um eine eigene Umgebung anzulegen, gehen Sie wie folgt vor:
- Neue Konfigurationsdatei anlegen
Im Verzeichnis config/environments legen Sie eine neue Konfigurationsdatei an, die so heißt wie Ihre Umgebung, z. B. staging.rb. In dieser Datei nehmen Sie Ihre Konfigurationseinstellungen vor. - Eintrag in database.yml hinzufügen
In der Datenbankkonfigurationsdatei config/database.yml definieren Sie einen zusätzlichen Bereich für die neue Umgebung, z.B.:staging: adapter: mysql encoding: utf8 database: demo1_staging username: root password: socket: /opt/local/var/run/mysql5/mysqld.sock
- Datenbank generieren
Die in der database.yml neu definierte Datenbank demo1_staging legen Sie mit dem Befehl rake db:create RAILS_ENV=staging an.
Die Applikation starten Sie lokal mit den Umgebungseinstellungen der staging -Umgebung mit den Befehlen ruby script/server -e staging.
Die Konsole in der staging -Umgebung können Sie mit dem Befehl ruby script/console staging starten.
Clean up your environment
config/initializers
Vor Rails 2.0 wurde auch jede Art von einmaligen Konfigurationen innerhalb der environment.rb definiert. Jetzt können Sie diese Elemente in eigene Dateien im Verzeichnis config/initializers ablegen. Alle Dateien in diesem Verzeichnis werden automatisch geladen. Dadurch soll sichergestellt werden, dass nur die Standardeinstellungen innerhalb der environment.rb definiert werden.
Sie können z. B. eine Datei meine_einstellungen im Verzeichnis config/initializers anlegen, in der Sie u. a. Konstanten speichern (z. B. ADMIN_EMAIL="admin@example.com"). Diese Datei wird beim Start automatisch ausgeführt.
export RAILS_ENV = production
Jetzt wird beim Aufruf von script/server oder script/console die Produktionsumgebung (production) geladen.
Default-Umgebung ändern |
Standardmäßig wird beim Aufruf von ruby script/server oder ruby script/console die Entwicklungsumgebung (development) geladen. Auf UNIX-basierten Systemen können Sie eine Umgebungsvariable setzen, um das zu ändern: export RAILS_ENV = production Jetzt wird beim Aufruf von script/server oder script/console die Produktionsumgebung (production) geladen. |
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.