En plus de l'environnement de production et de l'environnement de développement local, il existe généralement plusieurs environnements tels qu'un environnement intermédiaire et un environnement d'assurance qualité. Comment gérer les différentes valeurs de paramètres pour chaque environnement (par exemple, les paramètres de la base de données, les URL et les ID des services liés, etc.) est un point à se soucier lors de l'utilisation d'une application Rails. Dans cet article, je vais vous montrer comment gérer les valeurs de paramètres pour chaque environnement avec yml en utilisant Rails :: Application.config_for préparé par Rails sans augmenter RAILS_ENV.
https://speakerdeck.com/spring_mt/deep-environment-parity-cdnt-2019 En supposant qu'il existe plusieurs environnements, veuillez vous reporter à cette diapositive pour découvrir comment éliminer la différence dans le sens de l'environnement et les associer.
module MyApp
class Application < Rails::Application
config.application= config_for(:application)
end
end
Si vous écrivez comme ceci, il lira /application.yml sous le répertoire de configuration et lira la valeur de paramètre qui correspond à RAILS_ENV.
Rails.configuration.x.application[:hoge]
Après lecture, vous pouvez obtenir la valeur de la clé appelée hoge dans yml en l'appelant comme ci-dessus à l'endroit que vous souhaitez utiliser. Cette fonctionnalité est très pratique et recommandée par Rails, je voudrais donc l'utiliser activement.
Pour utiliser Rails :: Application :: config_for tel quel, augmentez simplement RAILS_ENV. Certes, on dit souvent que config / environnements / staging.rb etc. sont prêts à augmenter les variables d'environnement. Cependant, je ne pense pas que cette méthode soit très bonne. Parce que RAILS_ENV est une variable d'environnement pour changer le comportement du framework appelé Rails, je pense que l'utiliser pour changer la valeur de réglage de l'application comme cette fois n'est pas l'idée de Rails. Parce que je pense.
Étant donné que les informations confidentielles telles que les mots de passe de base de données sont souvent transmises via des variables d'environnement, il est naturel d'utiliser également toutes les valeurs de paramétrage comme variables d'environnement. Cependant, les variables d'environnement seront définies du côté de l'infrastructure, et comme il s'agit d'une valeur de paramètre d'application, vous souhaiterez peut-être la gérer dans le référentiel d'application, évitez donc de la gérer avec des variables d'environnement.
Si vous pouvez ajouter des variables d'environnement avec désinvolture et les gérer correctement dans le référentiel, cette méthode est également bonne. Dans notre projet, nous gérons l'infrastructure à l'aide de CloudFormation, mais étant donné que CloudFormation est géré dans un référentiel séparé et que le calendrier de déploiement est différent, nous avons arrêté de le gérer avec des variables d'environnement.
https://speakerdeck.com/spring_mt/deep-environment-parity-cdnt-2019?slide=47 Faites-le comme si c'était aux pages 47-51 de la diapositive que j'ai présentée plus tôt. Cependant, seule la partie qui utilise le préhook de Entrykit est falsifiée. Je vais vous expliquer en détail pour le moment. Comme mentionné ci-dessus, je veux gérer avec yml pour config_for, alors placez yml avec la structure de répertoire suivante. Le contenu de yml est omis, mais la clé au début de yml doit être la même que RAILS_ENV (développement, test ou production).
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 est une méthode qui peut lire le fichier yml sous config, vous devez donc déplacer yml sous le répertoire stage_settings sous config.
Dans la diapositive présentée plus tôt, il a été réalisé en utilisant le préhook de Entrykit, mais je l'ai changé car je pensais qu'il serait plus facile de le décrire dans config / boot.rb s'il s'agit d'un processus qui est toujours effectué au démarrage de Rails. (Config / boot.rb devrait être le seul endroit pour mettre les choses entre les deux avant de démarrer Rails ...)
# 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.
#↑ est le code généré automatiquement par Rails. Traitement original d'ici
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'))
Décrivez-le comme ça. Une nouvelle variable d'environnement appelée APP_STAGE a été ajoutée, qui est une variable d'environnement pour représenter l'environnement tel que le staging et l'environnement qa.
Désormais, à chaque démarrage, tous les fichiers sous stage_settings seront copiés dans le répertoire config. Afin de décider quel yml utiliser au démarrage, ajoutez-le à .gitignore afin que yml ne soit pas validé directement sous le répertoire config.
La raison en est que certaines personnes de l'équipe développent avec Docker et d'autres pas, et je ne veux pas augmenter les tracas d'avoir à faire cela pour mettre en place un environnement de développement local. Je suis venu avec cela parce que je pensais qu'il y avait une bonne façon de le faire.
--RAILS_ENV n'augmente pas même si vous souhaitez modifier la valeur de paramètre pour chaque environnement --Je veux gérer les valeurs de réglage pour chaque environnement avec yml