パブリッククラウドおよびPaaS環境で実行する場合、本番環境で保護する必要のあるアプリの秘密はたくさんあります。一般的なものはmysqlユーザーとパスワードのdatabase.ymlエントリですが、他のエントリもあります。あなたのGoogleアプリの秘密、Facebookアプリの秘密、...リストは続きます。これらの本質的に構成パラメーターを保護する明確な方法はありません。誰がアクセスできるかは保証されていないため、これらをファイルに入れたくない場合があります。
Herokuでは、環境変数を介して物事を指定できます。Cloudbees(Java PaaS)では、これらをJavaシステムプロパティとして指定できます。HerokuとCloudbeesの両方に、この構成パラメーターをアップロードするためのコマンドラインユーティリティがありますが、開発と本番の両方でこれを簡単に機能させるためのサポートはありません。
問題は、開発で簡単に開発できるが、開発で本番シークレットを使用できないように、パラメーターをどのように構成するかです。
ENV
理想的には、rubyおよびjruby環境で動作するgemと、開発中の開発設定があり、実際の本番シークレットがまたはからプルされたYMLファイルでシークレットを指定できるPaaSがありますjava.lang.System.getProperty
。
##
# file: config/secure_config.yml
development:
db:
user_id: 'dev_mysql_user'
password: 'my_dev_pwd'
google:
app_id: 'xxxxx' # this is the secret for the dev app so it can be visible
app_secret: 'xxxxx'
# ...
production:
db:
user_id: <%= get_secure_config %>
password: <%= get_secure_config %>
google:
app_id: <%= get_secure_config %>
app_secret: <%= get_secure_config %>
get_secure_configヘルパーがRubyまたはjRubyから、ENV
またはその場合に値を取得する場所。java.lang.System.getProperty
最後に、必要に応じてアプリでそれらを使用できます。たとえば、database.ymlまたはデバイスコードでgoogleを使用して認証します。
# config/database.yml
# ...
production:
adapter: mysql2
username: <%= SecureConfig.db.user_id %>
password: <%= SecureConfig.db.password %>
そして、さらにクールにするために、gemは、構成をPaaSにプッシュできる実行可能ファイルも提供する必要があります。
~/work/myproject> bundle exec secure_config -push_to_heroku
また
~/work/myproject> bundle exec secure_config -push_to_cloudbees