Software ready for the real world still has a virtual last mile to go. After development, testing, continuous integration, and quality assurance, for example, it must be installed on a production server – or perhaps hundreds or even thousands of production servers. When these servers are largely identical, automation of the deployment and subsequent maintenance makes the most sense. Not only does this save time and effort, it also eliminates many of the potential errors of manual deployment.
Define Once, Deploy Many
Deployment management tools offer automation and orchestration capabilities for speedy and reliable deployment over large, decentralized, and cloud-based populations of servers. With increasing frequency of incremental software releases, these tools become even more important for IT operations staff to manage their server bases. By using predefined schemas (also called templates, recipes, or playbooks), administrators can “define once and deploy many.” In addition, popular deployment management tools can be linked into a continuous delivery chain. Software releases can then automatically travel from stage to stage for final, automated deployment.
Sophistication or Simplicity?
There are four products that currently dominate the market for these tools, with a choice of management applications to federate these tools and others for DevOps continuous delivery:
- Chef. This configuration management tool can automatically provision and configure servers. Chef integrates with different cloud platforms including Amazon EC2, Azure, Google Cloud Platform, and Rackspace, and is compatible with OpenStack. The tool is written in Ruby and uses a Ruby DSL (domain specific language) for writing configuration recipes to put resources into declared states.
- Puppet. System configurations are declared in Puppet using Puppet’s own declarative language. A resource abstraction layer lets administrators define the configuration using high-level terms such as users, services, and packages.
- Ansible. Offering configuration management with multi-node deployment, Ansible requires that Python is installed on the servers concerned, then uses SSH (secure shell) to issue instructions. Administrators write reusable descriptions of systems in “human-readable” YAML language.
- Salt. Initially a tool for remote server management, Salt, also known as SaltStack, is a Python-based open source application that now offers infrastructure automation and predictive cloud orchestration.
Federating applications for these deployment management tools and others include:
- Ansible Tower. Provides dashboards, role-based access control, job scheduling, and graphical inventory management. A REST API facilitates integration with other tools in a DevOps continuous delivery chain.
- Foreman. Often used as an all-purpose GUI for automation solutions, although built for integration with tools like Chef and Puppet.
- Atlas. More recently introduced, Atlas offers configuration management, together with visibility into servers, virtual machines, containers, and other infrastructure. A closed-source product, Atlas provides dashboard facilities for also developing applications, as well as deploying and maintaining them.
Which product should you choose? Larger organizations looking for mature, stable products may prefer Chef or Puppet as deployment management tools. Those who prefer speed and simplicity instead may be drawn to Ansible and Salt. As a federating application, Ansible Tower offers ease of integration through its REST API. Foreman, on the other hand has the advantage of being open-source and freely available, compared to Ansible Tower’s commercial licensing.