Mon projet rails personnels utilise quelques API pour lesquelles je stocke les clés / secrets de l'API dans config / environment / production.yml et development.yml sous forme de variables globales. Je veux maintenant pousser ce projet à github pour que les autres puissent l'utiliser, mais je ne veux pas qu'ils aient ces données sensibles. Je ne veux pas non plus que ce fichier soit dans .gitignore, car il est requis pour que l'application s'exécute. J'ai envisagé de les placer quelque part dans la base de données, mais j'espère trouver une meilleure solution.
Réponses
Trop de publicités?
TLDR: Utiliser des variables d'environnement!
Je pense que @Bryce du commentaire propose une réponse, qui je vais juste rincer. Il semble une approche Heroku recommande est d'utiliser des variables d'environnement pour stocker des informations sensibles (API clé de chaînes, de la base de données des mots de passe). Si l'enquête de votre code et de voir où vous avez des données sensibles. Ensuite, créez des variables d'environnement (dans votre .bashrc fichier par exemple) qui stockent les sensivite valeurs de données. Par exemple pour votre base de données:
export MYAPP_DEV_DB_DATABASE=myapp_dev
export MYAPP_DEV_DB_USER=username
export MYAPP_DEV_DB_PW=secret
Maintenant, dans votre zone locale, vous venez de consulter les variables d'environnement à chaque fois que vous avez besoin de la nature sensible des données. Par exemple, dans la base de données.yml :
development:
adapter: mysql2
encoding: utf8
reconnect: false
database: <%= ENV["MYAPP_DEV_DB_DATABASE"] %>
pool: 5
username: <%= ENV["MYAPP_DEV_DB_USER"] %>
password: <%= ENV["MYAPP_DEV_DB_PW"] %>
socket: /var/run/mysqld/mysqld.sock
Je pense que la base de données.yml obtient analysé seulement à l'application de l'initialisation ou de redémarrer, donc il ne devrait pas influer sur les performances. Donc, ce serait le résoudre pour votre développement local et pour faire de votre dépôt public. Dépouillé de données sensibles, vous pouvez maintenant utiliser le même référentiel pour le public comme vous le faites en privé. Il résout également le problème si vous êtes sur un VPS. Juste ssh et configurer les variables d'environnement de votre production d'accueil que vous avez fait dans le développement de votre zone.
En attendant, si votre production de configuration implique une mains d'un déploiement où vous ne pouvez pas ssh vers le serveur de production, comme Heroku est fait, vous avez besoin de regarder comment faire pour configurer à distance les variables d'environnement. Pour Heroku c'est fait avec heroku config:add. Donc, par le même article, si vous aviez S3 intégré dans votre application, et les données sensibles en provenance des variables d'environnement:
AWS::S3::Base.establish_connection!(
:access_key_id => ENV['S3_KEY'],
:secret_access_key => ENV['S3_SECRET']
)
Juste Heroku créer des variables d'environnement pour elle:
heroku config:add S3_KEY=8N022N81 S3_SECRET=9s83159d3+583493190
Un autre pro de cette solution est qu'elle est indépendante de la langue, et pas seulement des Rails. Fonctionne pour n'importe quelle application, car ils peuvent tous d'acquérir les variables d'environnement.
Daniel Kehoe
Points
4296
Comment à ce sujet...
Créer un nouveau projet et de vérifier dans GitHub avec des valeurs d'espace réservé dans la production.yml et de développement.yml fichiers.
La mise à jour .gitignore à la production.yml et de développement.yml.
Remplacez l'espace réservé valeurs avec vos secrets.
Maintenant, vous pouvez vérifier votre code sur GitHub sans compromettre vos secrets.
Et n'importe qui peut cloner votre dépôt sans étapes supplémentaires pour créer des fichiers manquants (il va juste remplacer la valeur de l'espace réservé comme vous l'avez fait).
Le fait d'atteindre vos objectifs?
Bryce
Points
1620
Ils sont probablement mieux le mettre dans les initialiseurs (config/initializers/api.yaml) mais je pense que ce que vous avez cuit est bien en place. Ajouter les clés de votre .gitignore fichier et de l'exécuter git rm config/environments/production.yml pour supprimer les données sensibles de votre repo. Fair warning, il va supprimer ce fichier afin de sauvegarder d'abord.
Ensuite, il suffit de créer un fichier config/environments/production.yml.fichier de l'exemple suivant à votre fichier, avec les détails pertinents, mais avec les données sensibles laissées de côté. Quand vous sortez de la production, il suffit de copier le fichier sans le .exemple et les remplacer par les données appropriées.
dre-hh
Points
1858
Rails 4.1 a maintenant une convention pour cela. Vous stocker ce genre de choses dans le secret.yml. De sorte que vous ne finissent pas avec certaines ENV appels dispersés à travers Votre application.
Ce fichier yaml est comme la base de données.yml erb analysé, de sorte que vous êtes capable de les utiliser ENV appelle ici. Dans ce cas vous pouvez le mettre sous contrôle de version, il serait alors servir comme d'une documentation qui l'ENV vars doit être utilisé. Mais vous pouvez aussi exlcude de contrôle de version et entreposer des secrets là. Dans ce cas, vous mettrais quelques secrets.yml.par défaut ou dans le public de pensions de titres à des fins de documentation.
development:
s3_secret: 'foo'
production:
s3_secret: <%= ENV['S3_SECRET']%>
Que vous pouvez accéder à ce genre de choses, en vertu de
Rails.application.secrets.s3_secret
Ses discuté en détail au début de cet Épisode
tybro0103
Points
13198
Utiliser des variables d'environnement.
En Ruby, ils sont accessibles comme suit:
ENV['S3_SECRET']
Deux raisons:
- Les valeurs ne se feront pas dans le contrôle de source.
- "données sensibles", aka les mots de passe ont tendance à changer par l'environnement de base de toute façon. par exemple, vous devriez être en utilisant différents S3 informations d'identification pour le développement et la production.
Est-ce une meilleure pratique?
Oui: http://12factor.net/config
Comment puis-je les utiliser localement?
contremaître et dotenv sont à la fois facile. Ou, modifier votre shell.
Comment puis-je les utiliser dans la production?
En grande partie, ça dépend. Mais pour les Rails, dotenv est une victoire facile.
Quid de la plate-forme en tant que service?
Tout PaaS devrait vous donner un moyen de les définir. Heroku par exemple: https://devcenter.heroku.com/articles/config-vars
N'est-ce pas le rendre plus compliquée à mettre en place un nouveau développeur pour le projet?
Peut-être, mais ça en vaut la peine. Vous pouvez toujours vérifier une .env.exemple de fichier dans le contrôle de source avec des exemples de données. Ajouter une note à ce sujet à votre projet readme.
