Spinnaker and Ansible often get lumped together as automation tools. Teams can automate deployment workflows with Ansible. Spinnaker also automates deployments, so why use both? People mistakenly think that using one makes use of the other unnecessary. Ansible automates applications and IT infrastructure supporting configuration management, application deployment, and continuous delivery, while Spinnaker focuses on enterprise-grade application deployment.
You may be thinking that Spinnaker’s features are simply a subset of Ansible’s, but this is not the case. Each tool targets different use cases in completely different ways. Odds are that you will combine the two to build powerful deployment pipelines.
This post examines the automation behind continuous delivery, and how Spinnaker and Ansible fit into this role.
Automating Infrastructure and Deployments
Every software organization is using some form of automation. I will break this down into two different categories for this post.
First, there is infrastructure automation. This includes infrastructure as code and configuration management—effectively, what a particular environment package configuration and topology looks like. Example uses are creating cloud load balancers, auto-scaling groups, and applying some configuration management to those instances. Tools such as Ansible, Chef, SaltStack, Puppet, and Terraform come to mind here.
Second, there is deployment automation. This process may be immutable by baking an AMI and rolling out to a new auto-scaling group behind a load balancer. It can also be a mutable process of SSHing into all servers, pulling the correct commit from SCM, and restarting the application servers. Tools such Capistrano, Fabric, Octopus Deploy, and Spinnaker occupy this space.
Organizations of all sizes need to succeed with both DevOps and continuous delivery. Generally speaking, Ansible fits better into infrastructure automation and configuration management, and Spinnaker works better for application deployments. However, the lines are blurred when you consider that tools like Ansible can also do what Spinnaker does—just not as well.
Ansible can be used to manage immutable and mutable infrastructure. It is well-suited for both, but it is typically used for mutable infrastructure. Spinnaker’s deployment strategies are a key differentiator between it and Ansible, and a selling point in its own right.
Deployment strategies, such as canaries, provide reliable and robust processes for all applications. On top of that, Spinnaker supports multiple cloud providers while leveraging immutable infrastructure. A common Spinnaker deployment goes like this: pull down the latest artifact (e.g., JAR, source code, or Docker image), bake that into an immutable machine image, and then push that out to infrastructure according to the deployment strategy. The following image helps us visualize Spinnaker’s deployment strategies.
The same process may be implemented as an Ansible playbook, but it will be at a lower abstraction level and not cloud-provider agnostic. Ansible has a blog post and example playbooks to help you coordinate this process.
This is a complex example. CloudFormation creates AWS auto-scaling groups and ELBs. An Ansible playbook builds a new AMI and deploys the CloudFormation stack with updated auto-scaling group parameters. This example leverages the rolling update feature in AWS to update EC2 instances in an auto-scaling group to a new AMI. The example also includes playbooks to coordinate red/black deployments.
However functional this Ansible example is, it is more complicated than switching a radio button in a UI, is nowhere near as robust or battle-tested, and is not directly portable to other cloud providers. Implementing more complex deployment strategies—like canaries—is a complicated affair and will devolve into a mix of programming inside Ansible playbooks. This is where you will start to rub against inherent limits in the tooling. After all, that is not what Ansible was designed for.
Spinnaker is simply better suited to the task of deploying applications. Organizations do not just need to deploy applications—they also need to manage infrastructure and glue processes together. This is why combining Ansible and Spinnaker creates a powerful, wholistic automation solution.
Ansible for Infrastructure, Spinnaker for Deployments
Ansible excels at configuration management, infrastructure automation, and simple application deployment scenarios. Spinnaker is an enterprise-grade deployment manager. It makes sense to use them to complement each other. Here is how that can work in practice.
Spinnaker is a running service that requires compute and networking. In other words, someone must do the work to spin up machines to run Spinnaker. This requires infrastructure and deployment automation: automation to create Spinnaker infrastructure and to configure/update Spinnaker code accordingly. Ansible works well here and it can also help in other ways. Or teams can get around this completely by opting for a managed Spinnaker solution.
Spinnaker deployment pipelines begin by baking an image with Packer. This is where Ansible’s configuration management features are valuable. Packer includes an Ansible provisioner, which is a major step up from Bash scripts. Using Ansible adds elegance and flexibility to different stages in any deployment pipeline. Other configuration management tools like Chef or Puppet may be used here, but Ansible is the easiest to set up and use in this scenario.
Spinnaker can deploy applications to multiple cloud providers, but it requires some infrastructure beforehand such as AWS VPCs and subnets. Ansible’s configuration management and infrastructure automation features are a natural fit here. Teams can automate infrastructure prep work with Ansible so that Spinnaker is ready for deployments.
This could even be taken one step further. Teams can add another task to the Ansible playbook that creates a new Spinnaker pipeline using the Spinnaker API; this way, more of the repeatable process is automated. Creative engineers may find even more ways to glue separate processes and systems together with Ansible. It is surprisingly useful in that way.
The point is that Ansible and Spinnaker do not negate each other, so you do not have to choose between one or the other. Instead, you should leverage both to build robust deployment pipelines for infrastructure and applications.
IT teams must address infrastructure automation, configuration management, and deployment management to succeed in the marketplace. They need to choose their tools carefully with a focus on how well they fit the current requirements and how they may scale up as things change.
Ansible is the Swiss Army knife of IT automation. It is the Jack of all trades. But, like all other Jacks of all trades, it simply cannot do everything as well as the purpose-built tools. This does not mean that it is not useful. But we need to acknowledge its weak spots and look to overcome them with purpose-built tools. Spinnaker is a perfect candidate for replacing home-grown Ansible deployment playbooks. Ansible’s other features complement Spinnaker and fill other automation gaps.
The goal here is not to find one tool that does it all, but to mix them together in a way that provides the best, wholistic automation solution across those three areas. All in all, Ansible plus Spinnaker has a strong value proposition that technical decision makers should consider.