5 ms·

This article reads as very developer-centric, is my first thought. When comparing Docker and Configuration Management, he uses deploying code and scripts as hi

This article reads as very developer-centric, is my first thought. When comparing Docker and Configuration Management, he uses deploying code and scripts as his comparison, which is far from extensive when thinking through a list of all changes on a system. As a former operations engineer himself, the author didn't touch on a suite of other day to day complexities to consider : how to handle emergency change management and track that (most configuration management tools can revert to baseline if they detect a change they don't expect), keeping systems patched, etc. While not a bad article, I feel like we've talked about just deployment, and quite frankly there are a zillion ways to solve the automation of it.

phildougherty 10y ago
That's fair. This was definitely written with deployments in mind so I can't disagree with your assessment. With that said, I think the real downside of config management, and the real upside of containers really comes down to deployments. There is definitely still a use case for system level changes and patching that are best served by config management. How long until the container based config management? :serious_question:
- Gigablah 10y ago
  It's already possible to use config management tools to manipulate container images. E.g. Ansible 2.0 has a Docker connector. I talked about it a bit here: http://go-talks.appspot.com/github.com/gigablah/talks/20150915/from_source_code_to_containers.slide#23 http://go-talks.appspot.com/github.com/gigablah/talks/201509... Judging from the horrified reactions of my audience though, I guess it's not a popular idea at the moment :p
  - bogomipz 10y ago
    Why were people horrified? I liked the points you made in your slides, specifically patching openssl in containers is a great use case. When will this connector be beta? By the way this connector along with something like "clair" would be a good foundation for vulnerability management system for containers in production: https://github.com/coreos/clair https://github.com/coreos/clair
    - Gigablah 10y ago
      The connector is already out, Ansible 2.0 was released back in January.
- curun1r 10y ago
  > There is definitely still a use case for system level changes and patching that are best served by config management. This is only true for bare-metal deployments where virtualization is not an option, which isn't too common these days. When you have virtualization, deployments can and should be viewed as immutable, which gets rid of the need for any of the config management tooling. If you want to make a system-level change, you update the script that builds the image, CI builds a new copy of the image and you deploy a new, immutable version of your infrastructure. Not having immutable infrastructure components is just opting into a world of pain that's completely unnecessary these days.
bogomipz 10y ago
Agreed. There's lots of developer-centric posts lately that "config management" is dead, "no ops", "serverless" etc and they are sort of shortsighted. Sure it might work in a small greenfield environment but at any kind of scale you will still have a need for config management, servers and someone that pays attention to the ops side of things. The role of config management has changed slightly in the era of micro services and containers but it is still essential.

phildougherty 10y ago

That's fair. This was definitely written with deployments in mind so I can't disagree with your assessment. With that said, I think the real downside of config management, and the real upside of containers really comes down to deployments. There is definitely still a use case for system level changes and patching that are best served by config management. How long until the container based config management? :serious_question:

Gigablah 10y ago
It's already possible to use config management tools to manipulate container images. E.g. Ansible 2.0 has a Docker connector. I talked about it a bit here: http://go-talks.appspot.com/github.com/gigablah/talks/20150915/from_source_code_to_containers.slide#23 http://go-talks.appspot.com/github.com/gigablah/talks/201509... Judging from the horrified reactions of my audience though, I guess it's not a popular idea at the moment :p
- bogomipz 10y ago
  Why were people horrified? I liked the points you made in your slides, specifically patching openssl in containers is a great use case. When will this connector be beta? By the way this connector along with something like "clair" would be a good foundation for vulnerability management system for containers in production: https://github.com/coreos/clair https://github.com/coreos/clair
  - Gigablah 10y ago
    The connector is already out, Ansible 2.0 was released back in January.
curun1r 10y ago
> There is definitely still a use case for system level changes and patching that are best served by config management. This is only true for bare-metal deployments where virtualization is not an option, which isn't too common these days. When you have virtualization, deployments can and should be viewed as immutable, which gets rid of the need for any of the config management tooling. If you want to make a system-level change, you update the script that builds the image, CI builds a new copy of the image and you deploy a new, immutable version of your infrastructure. Not having immutable infrastructure components is just opting into a world of pain that's completely unnecessary these days.

bogomipz 10y ago

Agreed. There's lots of developer-centric posts lately that "config management" is dead, "no ops", "serverless" etc and they are sort of shortsighted. Sure it might work in a small greenfield environment but at any kind of scale you will still have a need for config management, servers and someone that pays attention to the ops side of things. The role of config management has changed slightly in the era of micro services and containers but it is still essential.