> All of the logic that used to live in your cookbooks/playbooks/manifests/etc now lives in a Dockerfile that resides directly in the repository for the application it is designed to build. This means that things are much more organized and the person managing the git repo can also modify and test the automation for the app.
It sounds like the author didn't have experience with larger systems - or maybe did, but my experience contradicts this.
Let's say you have everything you can in the containers. Now you want to deploy test and production environments. How do containers know which environment they're running in? Or specifically, things like what's the database user/password, what queue to connect to, where to find local endpoint for service X?
That still needs to live outside of containers. And at some point etcd and similar solutions have a problem of "what if I don't want to share all the data with all the infrastructure all the time"? Well... you can solve that with a config management service. Edit: just noticed etcd actually gained ACL last year - good for them. But how do you configure/deploy etcd in the first place?
It sounds like the author didn't have experience with larger systems
In actual _large_ systems like Facebook or Google you explicitly keep runtime applicaiton configuration info out of the config management system and use another system entirely to manage that. This lets you easily manage test/deploy, shard services easily, and do rolling deployments with config info updated instantly across the fleet if necessary.
Have a look at ConfigMaps and Secrets in Kubernetes. We use these to run the same container images in staging and production, without additional config mgmt.
> How do containers know which environment they're running in? ... But how do you configure/deploy etcd in the first place?
This is where you wind up installing a platform like Cloud Foundry or OpenShift, or building your own out of lower-level components like Kubernetes or Mesos.
Disclaimer: I work at Pivotal, we provide the majority of engineering effort on Cloud Foundry.
It sounds like the author didn't have experience with larger systems - or maybe did, but my experience contradicts this.
Let's say you have everything you can in the containers. Now you want to deploy test and production environments. How do containers know which environment they're running in? Or specifically, things like what's the database user/password, what queue to connect to, where to find local endpoint for service X?
That still needs to live outside of containers. And at some point etcd and similar solutions have a problem of "what if I don't want to share all the data with all the infrastructure all the time"? Well... you can solve that with a config management service. Edit: just noticed etcd actually gained ACL last year - good for them. But how do you configure/deploy etcd in the first place?