Neben der Produktionsumgebung und der lokalen Entwicklungsumgebung gibt es im Allgemeinen mehrere Umgebungen, z. B. eine Staging-Umgebung und eine QS-Umgebung. Das Verwalten der verschiedenen Einstellungswerte für jede Umgebung (z. B. Datenbankeinstellungen, URLs und IDs verknüpfter Dienste usw.) ist beim Betrieb einer Rails-Anwendung ein wichtiger Punkt. In diesem Artikel werde ich vorstellen, wie Sie die Einstellungswerte für jede Umgebung mit yml mithilfe von Rails :: Application.config_for verwalten, das von Rails bereitgestellt wird, ohne RAILS_ENV zu erhöhen.
https://speakerdeck.com/spring_mt/deep-environment-parity-cdnt-2019 Unter der Annahme, dass es mehrere Umgebungen gibt, lesen Sie bitte auf dieser Folie, wie Sie versuchen, den Unterschied im Umgebungssinn zu beseitigen und sie abzugleichen.
module MyApp
class Application < Rails::Application
config.application= config_for(:application)
end
end
Wenn Sie so schreiben, liest es /application.yml im Konfigurationsverzeichnis und liest den Einstellungswert, der mit RAILS_ENV übereinstimmt.
Rails.configuration.x.application[:hoge]
Nach dem Lesen können Sie den Wert des Schlüssels mit dem Namen hoge in yml abrufen, indem Sie ihn wie oben an der Stelle aufrufen, die Sie verwenden möchten. Diese Funktion ist sehr praktisch und wird von Rails empfohlen, daher möchte ich sie aktiv nutzen.
Um Rails :: Application :: config_for unverändert zu verwenden, erhöhen Sie einfach RAILS_ENV. Sicher wird oft gesagt, dass config / environment / staging.rb usw. bereit sind, Umgebungsvariablen zu erhöhen. Ich denke jedoch nicht, dass diese Methode sehr gut ist. Der Grund dafür ist, dass RAILS_ENV eine Umgebungsvariable zum Ändern des Verhaltens des Frameworks mit dem Namen Rails ist. Daher denke ich, dass die Verwendung des Frameworks zum Ändern des Einstellungswerts der Anwendung wie in dieser Zeit nicht in der Idee von Rails liegt. Weil ich denke.
Da vertrauliche Informationen wie Datenbankkennwörter häufig über Umgebungsvariablen übertragen werden, ist es selbstverständlich, alle Einstellungswerte auch als Umgebungsvariablen zu verwenden. Umgebungsvariablen werden jedoch auf der Infrastrukturseite festgelegt. Da es sich um einen Anwendungseinstellungswert handelt, möchten Sie ihn möglicherweise im Anwendungsrepository verwalten. Vermeiden Sie daher die Verwaltung mit Umgebungsvariablen.
Wenn Sie Umgebungsvariablen beiläufig hinzufügen und im Repository gut verwalten können, ist diese Methode auch gut. In unserem Projekt verwalten wir die Infrastruktur mithilfe von CloudFormation. Da CloudFormation jedoch in einem separaten Repository verwaltet wird und der Zeitpunkt der Bereitstellung unterschiedlich ist, haben wir die Verwaltung mit Umgebungsvariablen eingestellt.
https://speakerdeck.com/spring_mt/deep-environment-parity-cdnt-2019?slide=47 Tun Sie es so, als wäre es auf den Seiten 47-51 der Folie, die ich zuvor vorgestellt habe. Es wird jedoch nur der Teil manipuliert, der den Prehook von Entrykit verwendet. Ich werde es vorerst ausführlich erklären. Wie oben erwähnt, möchte ich mit yml für config_for verwalten, also platziere yml mit der folgenden Verzeichnisstruktur. Der Inhalt von yml wird weggelassen, aber der Schlüssel am Anfang von yml muss mit RAILS_ENV (Entwicklung, Test oder Produktion) identisch sein.
config/stage_settings
├── circleci
│ ├── application.yml
│ ├── database.yml
│ ├── secrets.yml
│ └── sentry.yml
├── local
│ ├── application.yml
│ ├── database.yml
│ ├── secrets.yml
│ └── sentry.yml
├── production
│ ├── application.yml
│ ├── database.yml
│ ├── secrets.yml
│ └── sentry.yml
└── staging
├── application.yml
├── database.yml
├── secrets.yml
└── sentry.yml
Rails :: Application.config_for ist eine Methode, mit der die yml-Datei unter config gelesen werden kann. Sie müssen also yml unter dem Verzeichnis stage_settings unter config verschieben.
In der zuvor vorgestellten Folie wurde dies mit dem Prehook von Entrykit realisiert, aber ich habe es geändert, weil ich dachte, dass es einfacher wäre, es in config / boot.rb zu beschreiben, wenn es sich um einen Prozess handelt, der immer ausgeführt wird, wenn Rails gestartet wird. (Config / boot.rb sollte der einzige Ort sein, an dem Dinge dazwischen gelegt werden können, bevor Rails gestartet wird ...)
# config/boot.rb
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)
require 'bundler/setup' # Set up gems listed in the Gemfile.
require 'bootsnap/setup' # Speed up boot time by caching expensive operations.
#↑ ist der von Rails automatisch generierte Code. Originalverarbeitung von hier
stage = ENV.fetch('APP_STAGE', 'local')
path = File.join('config', 'stage_settings', stage)
raise "#{path} is not a directory." unless File.exist?(path)
FileUtils.cp_r(Dir.glob("#{path}/*"), File.join('config'))
Beschreibe es so. Eine neue Umgebungsvariable mit dem Namen APP_STAGE wurde hinzugefügt. Diese Umgebungsvariable repräsentiert die Umgebung wie Staging und QA-Umgebung.
Jetzt werden bei jedem Start alle Dateien unter stage_settings in das Konfigurationsverzeichnis kopiert. Um zu entscheiden, welche yml beim Start verwendet werden soll, fügen Sie sie zu .gitignore hinzu, damit yml nicht direkt im Konfigurationsverzeichnis festgeschrieben wird.
Der Grund dafür ist, dass einige Mitarbeiter im Team mit Docker entwickeln und andere nicht, und ich möchte den Aufwand nicht erhöhen, dies zu tun, um eine lokale Entwicklungsumgebung einzurichten. Ich habe mir das ausgedacht, weil ich dachte, es gäbe einen guten Weg, dies zu tun.
--RAILS_ENV wird nicht erhöht, selbst wenn Sie den Einstellungswert für jede Umgebung ändern möchten