Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Config management, as it currently stands with Puppet/Chef etc./ ideally has no place _in_ containers iff the issue of how applications are deployed there can be solved in a suitably generic and straight forward way. A container becomes and immutable item - logs get shipped off container, config comes from service discovery, failing containers get taken out of service.

There is a need for shims like confd, though perhaps we'll see configuration information libraries emerge that can go straight to a service discovery/config lookup endpoint such as etcd or zookeeper.

All of the config management tools have some sort of overhead and all affect the ability for a container (bar its data in the case of databases) to be immutable.

Building the container should be as simple as installing the package for the given app into whatever container systems is being used, be it Docker, a more bare bones container, or something that comes from the standarisation effort.

The base 'OS' in the container then becomes irrelevant, as the base OS is really the containing, host OS, with the containers just containing the apps and not additional overhead.

In terms of where configuration management fits, it potentially is at the orchestration level, but that said there are already other, more specialised tools emerging in that space too.



Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: