On 05.07.2013 13:37, Jakov Sosic wrote:
Let's imagine there is a daemon named foobard, which has it's
configuration snippets in /etc/foobar.d/*.conf
Applications are deployed via some tool other than puppet, for example
Jenkins or Capistrano, and developers want to be able to
also push system configs for specific deamon(s) via their deployment system.
Now, this poses a problem for me, because I'm used to manage
configuration files via puppet. How do you guys solve this kind of issues?
Any input is appreciated.
One of the big arguments for puppet is the unifying aspect of devs and
ops to use the same tool/language/process, which improves cooperation,
agility and quality of the work. This indicates that your application
deployment should be integrated into your puppet manifests and those
manifests should be integrated into the application development/release
Another big point in puppet's favor is that it doesn't want to be the
be-all-end-all. If there's a tool that is better suited to a task (the
prime example being package managers) then *please* use that. This
indicates that if capistrano is a good match for your organization's
application deployment (especially in the area of orchestration across
nodes and rollback it leaves puppet in the dust), then you should
leverage those capabilities.
You write "this poses a problem for me, because I'm used to manage
configuration files via puppet." While that may just be lost in
translation, it does sound like your problem is of a much more personal
and a less technical level. In that case you really need to get rid of
the us-against-them attitude and find solutions that enable the
organization as a whole to repeatably deliver more value faster while
reducing the associated risks.
Also, CM aside, there is a standing security issue. Deployment is run
via unprivileged account, which now has to be able somehow inject
potentially malicious configuration files into /etc.
This is a non-issue as the deployment process will always be able to
push the changes it needs into the system. So a subversion (no pun
intended) of the deployment process will always be a death knell,
independent of the used tool. So either the devs have the need and right
to modify those configuration files, or they don't. If they have the
need and right, then they also share the responsibility for the system.