Reputation: 2313
I have an application written in NodeJS. Every times I push my code with git on my master branch, the code is automatically deployed on my server. Everything’s work fine.
But I had a problem with my config
file which is different between my local server and my distant server.
To resolve this problem, I have excluded to git my config
file and copy it to _config
.
In the _config
file I put all my config server, and when the code is deploy to the server I made automatically a $ cp _config config
in order to take the good config values.
This solution working but I am wondering if it’s the best solution to deploy my config
file and if it’s secure to have it on Bitbucket.
For example, if I want to share my repository with someone I can't because he will see my config.
Is there an another solution to do that ?
If you have any advice, thanks in advance.
Upvotes: 1
Views: 767
Reputation: 2989
On my projects I solve this with three config files.
Default config: This config file contains default configuration. Such configuration should be safe and appropriate for most installations. This may be real config file or some part of source code with default values. This file is committed to Git repository.
Example configuraiton file: This file looks like the third file, but it is not used by an application. I usually give it .example
suffix. This file is committed to Git repo, but does not contain sensitive data.
Local configuration file: Copy of example with local changes, like database password or enable debug mode. This file is not committed to Git repo and it contains sensitive data. It should be listed in your .gitignore
file.
When loading such configuration, I merge the defaults file with local file, so content of local file overrides the defaults, but if something is missing in local file, defaults are used instead. This way I can have minimal local file and most of the configuration is affected by developers' commits.
You may want to have even more config files when a framework is used and your application is installed to many customers. Then you may have framework configuration file, application configuration file, per-customer configuration file and local configuration file. And all files are merged together in this order, and only the last file, the local configuration, is not committed. Of course this involves more repositories, git submodules or something like that.
Upvotes: 0
Reputation: 1236
Your solution works fine, even though it might seems a bit crude to you.
Configuration generally consists of 2 types of data:
Config variables of either of these types can be different on your dev machine compared to your production machine (dev API URL vs prod API URL; dev API password vs prod API password).
The second type of configuration data can be committed in your git repository, and it's probably easiest if you do. You could make 1 file for dev and 1 for production, and for example based on an environment variable load the correct one.
The first type - passwords - should not be committed to git. Not even if you have a private repository. It's just too dangerous. Instead, you could for example use a mechanism like you describe, or you could put the passwords in environment variables which you set on the production environment.
Upvotes: 1
Reputation: 77
Hrm, probably not a complete solution but checkout process environment variables.
I typically have one that I keep privately that I add to gitignore and then I push the sample environment var file
Upvotes: 0