Neat.
I will admit, however, that it has never been clear to me what the
security improvement is supposed to be of having a secrets.yml that you
copy to all your servers, but don't put in your version control. If
you're going to have it on possibly multiple production servers, why not
in version control too? It adds another level of management complexity
to do this, and I've never been clear on the benefit.
But I'm clearly in the minority, so there's probably something I'm missing!
On 10/7/14 1:52 PM, Bruno Sutic wrote:
Just in case anyone is still looking for a solution to this, I created a
capistrano-secrets-yml
gem: https://github.com/capistrano-plugins/capistrano-secrets-yml
It handles secrets.yml in the simplest possible way.
On Friday, April 25, 2014 4:56:44 PM UTC+2, Bruno Sutic wrote:
Versions:
* Ruby 2.1.0
* Capistrano 3.2.1
* Rails 4.1 (basic blog app)
Files:
* config/secrets.yml <http://pastie.org/9107297>
I have been playing with rails 4.1 and I wanted to deploy it with
capistrano.
All went smooth till the end - the deployed app had hiccups because
I didn't provide it with SECRET_KEY_BASE environment variable (see
secrets.yml file above).
The problem was easy to manually fix, but I have the question: what
is the best general way to handle secrets.yml in rails 4.1?
I can think of 2 approaches and can't decide which one is right:
1. - put the secrets.yml in version control
- development and test secrets are visible and set in the file
- handle production secrets with environment variables
- set production env vars with capistrano somehow (values also
must not get into version control)
DOWNSIDES:
- too much hassle around env variables?
- development, test secrets still visible in git: problem when
API keys for other services are used (eg S3)
2. - do NOT put secrets.yml in version control
- have all the secrets (both dev,test and prod) inside the
secrets.yml file
- capistrano's job would be only to upload the
config/secrets.yml file
DOWNSIDES:
- server secrets stored in a file (not an issue myb?)
- config is not in the environement according to 12 factor
<http://12factor.net/config>
Looking at the steps above, the approach #2 seems less work and less
chance for a failure.
Any other opinions on this?
Thanks
--
You received this message because you are subscribed to the Google
Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to capistrano+unsubscr...@googlegroups.com
<mailto:capistrano+unsubscr...@googlegroups.com>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/capistrano/4dafc4a2-d612-4f40-bd51-fe499c91ed4b%40googlegroups.com
<https://groups.google.com/d/msgid/capistrano/4dafc4a2-d612-4f40-bd51-fe499c91ed4b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to capistrano+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/capistrano/54343E35.8000306%40jhu.edu.
For more options, visit https://groups.google.com/d/optout.
