Re: [Rails] Re: Rails 5.2 Custom Credentials — generally accepted way to segregate environments?

Ruby on Rails Friday, June 14, 2019

In the mean time you can add a rake task to the lib folder to rename credentials, or a bash/Ruby script to the bin folder:

Given: development.yml.enc, test.yml.enc, production.yml.enc

lib/tasks/credentials.rake

namespace : credentials do
  namespace :set_env do
    task production: : environment do
      Rake::Task['credentials:set_env'].invoke('production')
    end

    task test: : environment do
      Rake::Task['credentials:set_env'].invoke('test')
    end

    task development: : environment do
      Rake::Task['credentials:set_env'].invoke('development')
    end
  end

  task :set_env, [ :env_name ] => : environment do |_, args|
    File.open(Rails.root.join('config', 'credentials.yml.enc'), 'w') do |f|
      f.write(File.read(Rails.root.join('config', "#{args[:env_name]}.ym.enc")))
    end
  end
end

For something dynamic you could do

namespace : credentials do
  namespace :set_env do
    Dir['config/*.yml.enc'].each do |path|
      f_name = path[/(\w+)\.yml\.enc$/, 1].to_sym
      next if f_name == :credentials

      task f_name => : environment do
        File.open(Rails.root.join('config', 'credentials.yml.enc'), 'w') do |f|
          f.write(File.read(path))
        end
     end
  end
end


On Wed, Jun 12, 2019, 07:09 tech@datatravels.com <tech@datatravels.com> wrote:
I think this solution seems the most Rails 5.2 friendly, but ideally isn't the perfect solution as ideally you could in fact (one day, in Rails 6, say), separate the 3 files themselves, so you could, say, give junior developers access to only development+staging credentials by giving the only the keys for the development + staging master keys (but continuing to check-in all 3 .yml.enc files into source-code. the 3 keys are of course, not checked-in)

But if you have a team where you don't care if all the devs have the same (full) credentials then I like this solution best.

-Jason





On Jun 10, 2019, at 8:40 PM, Sampson Crowley <sampsonsprojects@gmail.com> wrote:

for rails 5, just nest environment specific credentials under a key for said environment

then all you have to do when accessing said config is add the environment to the party that pulls in config, e.g.:

credentials.yml.enc:

main_key:
  development:
    sub_key:
      value_key: 'development'
  production:
    sub_key:
      value_key: 'production'
  test:
    sub_key:
      value_key: 'test'

code:


my_credential = Rails.application.credentials.dig(:main_key, Rails.env.to_sym, :sub_key, :value_key)
```

On Sunday, June 9, 2019 at 7:40:05 PM UTC-6, Jason Fleetwood-Boldt wrote:
In some apps I've worked on Rails 5.1 and prior, environment variables, saved directly into the source code.

In rails 5.2 Custom credentials encourages us to check-in only the encrypted version of our configuration, and keep our master.key keyfile outside of our repository. 

My question is this: Is there a way to segregate by environment? (i.e., development, staging, production?)

seems like the instructions for setting up AWS keys, for example, would have the dev, staging + production all pointing to & using the same AWS bucket, access key, and secret. But it seems like for many services I'd want to have different credentials for different environments. 

I found this SO post that discusses this question, but unfortunately it doesn't present a very good answer IMHO because the there are only two answers: 1) I don't quite understand and 2) a suggestion to basically check all your ENV variables against each of your environments, which seems like it could encourage a messy setup. I much like answer #1 from this SO post, but I don't understand how to implement it practically. 


any tip appreciated. 
Thanks,
Jason

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/01fa12ca-06f5-4246-bead-503af4bf1a5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/C2DFCFDD-69CD-4A7C-A7C3-1898210E9B42%40datatravels.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAM5L8qPewQYZU0qK4%2BmUYx3SU4DFtAzrCdbuQmbL02G6JFdHew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Posted by Ruby on Rails at 12:19 AM

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)