First of all, I strongly advise against "feature comparisons" blog post for similar software, they're quickly outdated and I'll try to keep this answer generic for a system configuration manager (SCM) and let docker out of the talk for the first part.
What it can brings you:
- Reproduction of configuration from environment to environment
- Versioning of the configuration
- Enforcing the configuration
To get a real life example for a PHP application you'll need:
- an operating system
- a webserver
- php libs
- configuration of your app for external services (smtp, database IP, etc.)
What a SCM can provide is starting from a minimal base OS:
- taking care of installing the webserver (apache/nginx)
- installing PHP (either by package or source)
- installing the necessary libs
- Setting up your site config (vhost in apache)
- Setting up your php.ini with any tweaks needed
- deploying your app from a repository (from git to nexus, wide range of choice)
- Writing your application configuration (here can be the smtp or database server for this environment)
- Starting the webserver
- Eventually running some smoke tests on your app.
Now if someone comes to connect to the machine and do a manual change to any of the configuration, the goal of a SCM is to keep the machine in its desired state, at next run, the change will be detected and the file changed will be put back to its desired state.
This has the advantage of enforcing any change to be put in the desired state description and not be forget between environments. Usually chef or puppet are set up to run on a periodic schedule, default for Chef is 30 minutes.
Now the big difference with docker is that you will do the same thing, installing you middleware, libs, forcing a templatized configuration, etc.
Once in the runtime phase, if there's a breach in your app and an attacker use it to tweak your config or modifying your webserver configuration it can stay unnoticed for a while if it doesn't break the app.
A SCM will revert the changes if you use it properly it will even remove unwanted sites in the sites-enabled directory of apache and thus will raise the complexity for an attacker.
Likewise if your webserer dies, the container will stop and unless you have a system to monitor it an relaunch it you're down. A SCM will notice the service is stopped and restart it at its next run, less immediate than runit but it will correct a rotate script which didn't properly restart the service (like the default apache logrotate conf on Ubuntu which may time out and let your apache stopped)
A SCM may be interesting even to create your docker containers, you know you'll have the same behavior on a centos or ubuntu machine (most community code handle using the proper package names if you go this way) and so it will remove problem of edit to package names in a dockerfile.
The main idea behind a SCM is to manage your infrastructure as you manage your application, code it, version it, test it and be sure it will always behave the same.
If you rely on human procedure for configuration of the middleware/libs/app config you can be sure there will be a step forget during the deploy process once in a while, and spotting this problem can be really hard. With a SCM you prevent this omission.
