New in Symfony 2.3: Interactive Management of the parameters.yml File
May 7, 2013
•
Published by
Fabien Potencier
Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.
One of the best practice when developing a Symfony application is to make it
configurable via a parameters.yml file. It contains information such as
the database name, the mailer hostname, and custom configuration parameters.
As those parameters can be different on your local machine, your testing
environment, your production servers, and even between developers working on
the same project, it is not recommended to store it in the project repository.
Instead, the repository should contain a paramaters.yml.dist file with
sensible defaults that can be used as a good starting point for everyone.
Then, whenever a developer starts working on the project, the
parameters`.yml file must be created by using the parameters.yml.dist
as a template. That works quite well, but whenever a new value is added to the
template, you must remember to update the main parameter file accordingly.
As of Symfony 2.3, the Standard Edition comes with a new bundle that automates
the tedious work. Whenever you run composer install, a script creates the
parameters.yml file if it does not exist and allows you to customize all
the values interactively. Moreover, if you use the --no-interaction flag,
it will silently fallback to the default values.
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.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
Does this bundle run on each composer install and detect that parameters.yml not sync anymore with .dist (assume that a config key has been added since last commit) and handle the new key? Same with removed keys?
Also, in your post, you're saying storing passwords in parameters.yml is not as good/safe we might think and that Sf provides other ways, could you add a link to more info, refs? I'd be curious to know.
Best
by default, it also removes old keys but this can be disabled
We actually check in parameters.yml. It contains sensible defaults and placeholders for sensitive configuration (e.g. Amazon S3 Credentials, etc.). Then, we have an additional file parameters_local.yml, which contains configuration values that override those in parameters.yml. We achieved this by adding just a couple of lines in AppKernel.php.
This has quite a few advantages:
- We still have a 'template' file which lists all available parameters
- We instantly have an (almost) out-of-the-box preconfigured system with sensible defaults
- While developing, we can add configuration parameters to the system without having to explicitly define them in every dev / test / prod environment (!)
- While we have quite a lot configuration parameters, we can look at an environment's parameters_local.yml file and instantly see what has been customized in that environment.
- We don't need any special / interactive tool for generating our configuration files ;)
Maybe such an approach could be considered as an alternative to the proposed new feature? - or maybe not ^^ Just wanted to share :)
Best regards,
Mike
We also have a similar configuration to avoid repeating default parameters. For instance, you can simply add in your config.yml :
imports:
- { resource: parameters_dist.yml } # versionned file
- { resource: parameters_local.yml, ignore_errors: true } # git-ignored file
`parameters_dist.yml` only contains (all) default parameters like db user/pass = root/root, and parameters_local.yml can overwrite everything. The ignore_errors=true allow us to ignore if file is missing (may be usefull for local env).
This is handy for local/test/staging env, but of course, we almost redefine everything for prod ;)
Is using env variables more secure ? Or what are the secure alternatives for keeping, let's say, db user/password instead of parameters.yml?
What about my second question, the "more secure way to handle sensitive info" ? :)
Best
http://symfony.com/doc/master/cookbook/configuration/external_parameters.html
But I want to know more about
"Symfony provides other ways to do the same in a more secure way." anyone having idea about this one ?
Best regards,
Sanjay
The problem we had was having symfony use these environmental variables. I ended up writing up a bash script which would take the variables and populate the parameters.ini file; however, I wish I had time to make a cleaner solution. I could see having this new script allow you to specify the values while using --no-interaction. But more ideally would be a way to have symfony use the environmental variables in place of the parameters.ini file. Maybe a way of using %ENV.db_username% within parameters.ini