DevOps Digest 502: Flavors of Continuous Delivery, Part 2
As with many other common goals that unite us in our path toward DevOps, there is no one-size-fits-all solution for you to simply plug and go when it comes to Continuous Delivery. In DevOps Digest 501, we covered the pros and cons of using the ever popular server configuration management tools Puppet and Chef. This week, we round out that list with SaltStack and Ansible so that you might go forth and conquer the ins and outs of Continuous Delivery.
Salt’s original raison d’être was to enable the sort of “push” model upon which neither Puppet nor Chef were built. It still retains that “push” focus, but it has subsequently grown into a significant open source software variant as well as one aimed at the enterprise.
Unlike the other tools we’ve considered, it is implemented in Python, which makes it more accessible, due to the language’s popularity. And while Salt’s focus is clearly on “push” mechanics, it offers support for the “pull” model as well and includes something Puppet and Chef don’t: the ability to work without an agent installed.
Running without an agent requires support for remote execution, of course, and that can be a significant security concern. But if you’re already sold on the benefits of remote execution, not having an agent to install on every node can be very useful in a variety of circumstances.
Salt masters can control other Salt masters, and interestingly its agent can control multiple other agents, amusingly called minions in this use case, through a peer-to-peer interface unique to Salt. This lends a somewhat different flavor to Salt. Suffice it to say you’ve got more options for orchestration and control than with many other tools.
Salt’s installation process isn’t smooth, and I found its documentation wanting a bit. Its web interface is underwhelming (We’ve heard the enterprise edition has a nicer UI, although it comes at a cost.) Salt’s support for non-Linux operating systems is not quite where it needs to be. In short, the solution isn’t as mature as Puppet or Chef.
Yet on the other hand, its nicely consistent YAML syntax and Python scripting make it a simpler learning curve, especially for folks already familiar with Linux. And given the growing popularity of Linux distributions for DevOps automation, that’s not a bad thing at all.
In short, if you require the responsiveness of a “push” model and don’t mind a few rough edges, you might want to give Salt a look before as you consider your options. It’s hard to say where Salt is going to be in a decade, but it’s definitely not going away any time soon.
The last tool on our list, Ansible, has a more minimalist focus, and its vernacular is more sports-oriented, given that playbooks are its configuration unit for specifying the details of configuration.
Ansible, like Salt, uses YAML in its playbooks. Its inventory configuration, which describes the nodes it manages, is in the similar but even simpler *.ini file format. In short, much of the information with which you’ll be working in Ansible isn’t going to require knowledge of any particular programming language.
Having said that, however, Ansible does require SSH and the Python interpreter on its nodes, much like Salt’s agent-less operation. You won’t need a computer science degree to get Ansible up and running, but you should expect to spend some time mastering its intricacies.
This is especially true if you’re supporting multiple platforms. Because while Ansible can support multiple platforms, the details of its playbooks and templates, which provide the structure of files to be used for configuration with placeholder values to be replaced at run-time, can be problematic. In short, if you’re trying to support multiple platforms with Ansible, you’re going to be spending some time coming up with a (or embracing an existing) set of best practices.
Perhaps the greatest benefit of Ansible is that your infrastructure management will have a relatively low barrier to entry: you’ll enjoy support for both “push” and “pull” models, and Ansible doesn’t have any notion of an agent. This makes initial setup a comparative breeze. You’ll be sacrificing some of the control other systems offer, but if your needs are relatively few and you prefer to use the simplest tool for the job, then Ansible just might be the right choice.
Ansible is owned by RedHat, and is very popular among RHEL licensees with many servers. There is well-documented support for AWS cloud infrastructure within Ansible, although AWS has an increasingly popular built-in infrastructure management solution of their own — CloudFormation. If your needs involve a lots of RHEL VMs in a hybrid cloud/enterprise data center environment, then Ansible may be the best choice for you.
A Solid Foundation
Our hope is that this has been a good intro, for those who are investigating their options for implementing this category of tools. No matter which of these popular tools you choose, Perforce Helix can help you manage your Puppet scripts, Chef cookbooks, Ansible playbooks, and Salt scripts and data.
In fact, Helix can store far more than just your configuration data. Helix is the only version control system that can reliably store and manage far larger content, such as Docker images and even full virtual machine templates. So regardless of your CD needs, Helix provides a solid foundation on which to build. Integrations are available for all of these tools in various forms.
We’ll be back after the week of 4th of July with to leave you with few final words of wisdom.