patternModerate
Are configuration management tools appropriate to use as deployment tools?
Viewed 0 times
aretoolsappropriatemanagementconfigurationdeploymentuse
Problem
Off the back of my answer to the question: How can DevOps help to improve Software Escrow procedures? Tensibai had the question:
What would necessitate Capistrano on top of puppet or chef?
My response was to post a link to Noah Gibbs' article "Do We Need Both Capistrano and Chef?". Personally, I still subscribe to Noah's view that it is most appropriate to:
The fundamental approach that each type of tool uses to complete its task is very different:
-
Configuration Management Tools - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are Chef, Puppet, Ansible, PowerShell DSC, Salt Stack.
-
Deployment Tools - are about delivering versions of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature. Examples of deployment tools are Capistrano, Octopus Deploy, Deployer and Command.io.
I do believe that Configuration Management Tools can do the job of deployment tools and in the case of Immutable Infrastructure they are the most appropriate tool for the job as software versions on the target don't need to be maintained.
Question: Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?
What would necessitate Capistrano on top of puppet or chef?
My response was to post a link to Noah Gibbs' article "Do We Need Both Capistrano and Chef?". Personally, I still subscribe to Noah's view that it is most appropriate to:
- use a specialist deployment tool such as Capistrano for deployments.
- use a specialist configuration management tool such as Chef for configuration management.
The fundamental approach that each type of tool uses to complete its task is very different:
-
Configuration Management Tools - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are Chef, Puppet, Ansible, PowerShell DSC, Salt Stack.
-
Deployment Tools - are about delivering versions of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature. Examples of deployment tools are Capistrano, Octopus Deploy, Deployer and Command.io.
I do believe that Configuration Management Tools can do the job of deployment tools and in the case of Immutable Infrastructure they are the most appropriate tool for the job as software versions on the target don't need to be maintained.
Question: Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?
Solution
In such context the typical advice should be immediately applicable: use the right tool for the job.
But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc.
For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.
Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.
So it really boils down to the exact functionality you want to achieve in your particular process and how well one tool or the other does the job in your context. Subjectivity/preferences/convenience included.
Making this question primarily opinion-based ;)
But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc.
For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.
Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.
So it really boils down to the exact functionality you want to achieve in your particular process and how well one tool or the other does the job in your context. Subjectivity/preferences/convenience included.
Making this question primarily opinion-based ;)
Context
StackExchange DevOps Q#651, answer score: 10
Revisions (0)
No revisions yet.