5

In the default folder structure for a Symfony2 project the database and mail server credentials are stored in parameters.yml file inside ProjectRoot/app/config/parameters.yml with these default values:

parameters:
    database_driver: pdo_mysql
    database_host: 127.0.0.1
    database_port: null
    database_name: symfony
    database_user: root
    database_password: null
    mailer_transport: smtp
    mailer_host: 127.0.0.1
    mailer_user: null
    mailer_password: null
    locale: en
    secret: ThisTokenIsNotSoSecretChangeIt

During development we change these parameters to the development database and mail servers. This file is checked into the source code repository.

The problem is when we want to deploy to the production server. We are thinking about automating the deployment process by checking out the project from git and deploy it to the production server.

The thing is that our project manager has to manually update these parameters after each update. The production database and mail servers parameters are confidential and only our project manager knows them.

I need a way to automate this step and suggestion on where to store the production parameters until they are applied?

Songo
  • 6,548
  • 4
  • 48
  • 89
  • "I need a way to automate this step." http://www.phing.info/ – yannis Oct 30 '13 at 12:39
  • @YannisRizos yup, but what should I do exactly with Phing? Do we store the database credentials in a file then copy them? where should that file be? better idea than a file? – Songo Oct 30 '13 at 12:41
  • Most frameworks have the idea of [environments](http://symfony.com/doc/current/cookbook/configuration/environments.html). You can load a [different config](https://gist.github.com/lavoiesl/5769521) for test, production, development, etc... – Mike Oct 30 '13 at 12:42
  • The simplest (and crudest) solution would be to tell phing to replace your local credentials with the production ones, when you're building for production. That said, as @Mike already mentioned, setting up different configurations per environment is also a good idea (see: http://symfony.com/doc/current/cookbook/configuration/environments.html). Mike, you should probably expand that comment to an answer. – yannis Oct 30 '13 at 12:45
  • Related (not a dupe): [Strategy for keeping secret info such as API keys out of source control?](http://programmers.stackexchange.com/q/205606/25936) – yannis Oct 30 '13 at 12:47

2 Answers2

2

Rename parameters.yml to parameters.yml.sample, and ignore parameters.yml in your version control.

For each installation of the app, copy .sample back to the proper location and edit the details as needed.

That way you have a sample file that says what kind of details (mailer, DB, API keys, etc.) each installation needs, and the secrets are never in version control.

Amy B
  • 134
  • 1
  • 6
  • so basically I upload a file with the production parameters to the production server and after each check out I copy it into the project? – Songo Oct 30 '13 at 13:53
  • Yep. Or automate it. – Amy B Oct 30 '13 at 16:16
  • This doesn't answer the last part of the question: I need a way to automate this step and suggestion on where to store the production parameters until they are applied? I only point it out because I'm curious since I'll be dealing with this soon myself. – bstempi Oct 31 '13 at 04:03
  • You can automate your deployment process in a thousand ways -- bash scripts, Ruby scripts, Chef... Where to store the params until they are applied? A secure file on a server that all your production servers can read from? On paper? – Amy B Oct 31 '13 at 08:48
0

For production files you should not be using a file. A much better way that does not interfere with development practices (using the files) is to use ENV variables for your production environment.

Look at the cookbook for reference on this practice:

http://symfony.com/doc/current/cookbook/configuration/external_parameters.html

vpassapera
  • 121
  • 2
  • 1
    What makes you think environment variables are more secure than files with proper permissions? – Mat Sep 07 '15 at 05:33
  • 1. The OP asked how to do it programmatically. I don't know about you, but setting an environment variable programmatically seems a bit more practical than creating a file, and populating it. 2. I'm assuming that by "file with proper permissions" you mean the parameters.yaml file which leads to 3. 3. http://symfony.com/blog/new-in-symfony-2-3-interactive-management-of-the-parameters-yml-file 4. Read the docs. Don't be lazy. That's what "Makes me think that" May I suggest that when talking to another person on stack exchange you use a more respectful tone than the one used in your comment? – vpassapera Sep 09 '15 at 05:51
  • Relevance of link #3, in case you're too lazy to read it: "Please remember that storing password or any other sensitive information in the parameters.yml file is not a good idea, and Symfony provides other ways to do the same in a more secure way." – vpassapera Sep 09 '15 at 05:52
  • Also this: http://symfony.com/doc/current/best_practices/configuration.html#moving-sensitive-options-outside-of-symfony-entirely – vpassapera Sep 09 '15 at 05:54
  • I totally agree with the env vars and thats what we do. the test servers use the parameters.yml file with totally different credentials, then when deployed to the production cluster those servers have env vars set in the apache vhost configs and symfony uses those without any user intervention. simply deploy and run. it works great – Jacqueline Loriault May 10 '17 at 08:47