Merci pour vos reponses. Donc apparemment il est inevitable de creer un fichier .env / .environment / .envrc pour stocker les variables.
J'ai trouve https://github.com/sstephenson/rbenv-vars qui repose sur le meme concept. Comment j'utilise rbenv sur toutes mes plateformes (ubuntu server et macOSX), je trouve que c'est l'option la plus pratique pour moi. J'ai aussi ajoute cette task dans mon capistrano: namespace :deploy do desc "Setup secrets" task :setup_secrets do on roles(:app) do set :secret_key_base, ask_secretly('Secret key base:') set :admin_username, ask_secretly('Admin username:') set :admin_password, ask_secretly('Admin password:') smart_template "rbenv-vars", ".rbenv-vars" end end end def ask_secretly(label, default=nil) require "highline" return proc{ hint = default ? " [#{default}]" : "" answer = HighLine.new.ask("#{label}#{hint} ") {|q| q.echo = false}.to_s answer.empty? ? default : answer } end (smart_template venant de https://github.com/TalkingQuickly/capistrano-3-rails-template) # deploy/shared/rbenv-vars.erb <% fetch(:secret_keys).each do |key| %> <%= key.to_s.upcase %>=<%= fetch(key) %> <% end %> et evidemment set :linked_files, %w{config/database.yml .rbenv-vars} On Tuesday, September 23, 2014 9:24:25 PM UTC+9, Olivier El Mekki wrote: > > Ah nice, je ne connaissais pas, thx. C'est spécifique à runit, cela dit, > et j'utilise openrc, personnellement (le default sur gentoo). > > Quoi qu'il en soit, ça m'est utile de sourcer ces variables dans le > bashrc parce qu'il m'arrive régulièrement de lancer des tasks rake > manuellement ou de lancer un console en production pour inspecter les > données. Ce n'est pas vraiment un problème, parce que cet utilisateur > unix sert uniquement à exécuter les process rails. > > > On Tuesday, September 23, 2014 2:15:06 PM UTC+2, Michael Baudino wrote: >> >> Olivier, juste pour rebondir sur le passage de variables d'environnements >> à un processus sans hijacker .bashrc, il y a l'utilitaire Unix chpst(8) (et >> notamment son option -e). >> >> 2014-09-23 14:06 GMT+02:00 Olivier El Mekki <[email protected]>: >> >>> Hello, >>> >>> J'ai rencontré le même problème, avec les contraintes suivantes : >>> >>> * l'application doit être exécutée par un utilisateur dédié >>> * les variables d'environment doivent être accesibles via cron >>> * elle doivent être accessible par god (démarré en ssh interactif) >>> * elle doivent être accessible par capistrano (utilisant un ssh non >>> interactif) >>> >>> Pour résoudre cela, j'ai créé un fichier `~/.environment` sur le serveur >>> et il est sourcé dans `~/.bashrc` (avant le test sur l'interactivité du >>> terminal pour les fichiers dont les distrib en ajoute un par défaut). >>> >>> Mes tâches cron sont exécutées via `/bin/bash -le "<task>"` (whenever >>> s'en occupe). >>> >>> J'utilise ensuite directement les `ENV['something']` où j'en ai besoin, >>> sans passer par secrets.yml. >>> >>> En bonus, tes dévs te remercieront si tu ajoutes cette recipe >>> capistrano: >>> >>> >>> desc 'Display server environment variables' >>> task :env do >>> run "cat ~/.environment" >>> end >>> >>> À noter que god est problématique, dans ce cas : il faut entièrement le >>> redémarrer >>> (et donc tout ce qu'il monitor) si veux changer une variable d'ENV. >>> >>> >>> On Tuesday, September 23, 2014 1:53:56 PM UTC+2, Matthew Nguyen wrote: >>>> >>>> Bonjour tout le monde, >>>> >>>> J'ai une question de best practice a propos de secrets.yml. >>>> Jusqu'a maintenant, je mettais mon secrets.yml dans le .gitignore, je >>>> l'ajoutais via un script personnalise dans le shared avec capistrano et ca >>>> marchait bien. >>>> >>>> Puis je suis tombe sur la discussion https://github.com/ >>>> rails/rails/pull/13388 >>>> >>>> TL;PL secrets.yml n'est pas cense etre dans le .gitignore et il faut >>>> utiliser ENV. >>>> >>>> Je n'ai trouve nulle part comment utiliser ENV avec capistrano... >>>> Je vois bien en local comment faire (MY_SECRET_KEY=xxxx bin/rails >>>> server -e production) mais comment est-on cense faire en remote ? >>>> >>>> Je vois quelques articles qui proposent de creer un fichier .env qui >>>> stocke les secrets. Mais dans ce cas, pourquoi ne pas directement utiliser >>>> secrets.yml ? Quelle est la difference ? >>>> Comment faites-vous ? >>>> >>>> Cordialement, >>>> Matthew >>>> >>> -- >>> -- >>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >>> de Google Groups. >>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >>> [email protected] >>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> [email protected] >>> --- >>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >>> "Railsfrance". >>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >>> concernant, envoyez un e-mail à l'adresse >>> [email protected]. >>> Pour obtenir davantage d'options, consultez la page >>> https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Michael Baudino >> @michaelbaudino >> +33 (0) 7.61.90.93.62 >> Alpine Lab >> 1 rue de la Martinière >> 69001 Lyon >> > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
