One of the challenges when you’re starting out with DevOps is getting the lay of the land. There are a lot of tools out there. And when one of the goals of DevOps is continually improving your processes, it’s important for you to understand how those tools might fit in your infrastructure. At the same time, you want to be efficient. You don’t want to add tools that overlap with one another. Or tools that cost more than other effective alternatives. The more you read, the more questions you have. Should you use Docker? What about Chef? How do you stack up Ansible vs Jenkins or Capistrano?
In this post, we’re going to break down the differences between two DevOps technologies, and how they can work for your team. We’ll talk about Ansible and Jenkins, and what makes each of them tick. Then we’ll examine the right use case for each, and even how they might work together.
Jenkins is one of the earliest DevOps tools. I can remember writing scripts for Jenkins build processes almost ten years ago now, and it wasn’t new then.
Like many of the earliest DevOps tools, Jenkins is a tool for running a series of scripts one at a time. If a script completes successfully, the next script is executed until they’ve all finished. If the script fails, it sends a notification to the administrator, and stops trying to run the build process. What makes Jenkins so powerful is that it’s nearly infinitely configurable, and hooks into all sorts of different tools. Since it’s been around so long, you can find a script that’ll enable you to do almost anything you want, once you can get it to work.
When I first started using Jenkins, this was a huge step forward for the team. We could do things like build the software and run unit tests every time someone pushed to GitHub (or at that time, BitBucket). The challenge of working with Jenkins is that it’s a very linear tool. You perform step one, then two, then three, then four. Each of your scripts needs to know exactly what the environment will look like, and how to fail if they find something unexpected. Jenkins is a terrific transitional tool if your servers have traditionally been monitored by system administrators who built a collection of scripts to manage their servers. However, many DevOps teams look for more robust software to manage their deployment processes. Usually, they do this because their deployments are too complicated to manage through Jenkins.
Ansible is a tool developed by RedHat. At its heart, Ansible is a tool to manage deploying services. The primary use case for Ansible is when your application runs on multiple services on a cloud provider like AWS or Red Hat OpenShift. You provide a definition to Ansible about what your environment should look like, and Ansible handles the nitty-gritty of configuring your environment to match your specifications. Ansible is a leader in the Infrastructure As Code space, which is many companies’ first step into the DevOps world.
To many Site Reliability Engineers, the value of a tool like Ansible is indispensable. They rely on tools like Ansible to ensure that their environment always contains the services they expect. I’m sure you’re familiar with the feeling of troubleshooting a deployment gone wrong. Something broke while you were deploying a new version of the software, and you can’t figure out why. Eventually, you’re able to trace it to an error in some obscure log, about a service rejecting a connection attempt on a port you were sure was open.
That’s the kind of problem Ansible is designed to prevent. It’s there to make sure that network port you need open is always open. If it’s not, Ansible won’t let the deployment continue until the port is configured properly. That speeds up deployment times and makes your job easier.
One of the shortcomings of Ansible when it first released was that it was just a deployment system. There’s nothing wrong with that, but like with Jenkins, most DevOps teams prefer well-rounded tools that help them solve multiple problems. That’s why Red Hat developed Ansible Tower, a system for automating repeat tasks. Ansible Tower gives you full visibility into the state of those workflows and integrates nicely with the other pieces of the Ansible ecosystem.
Ansible Tower gives you the tools you need to manage deployments on a conditional basis. For instance, if you don’t want an environment to start up unless all unit tests pass first, Ansible Tower is the tool for you.
On some level, the question of Jenkins or Ansible Tower depends on your existing environment. Do you have a lot of existing scripts that work nicely together? Are they all very straightforward? Jenkins is probably the right tool for your team.
However, if you’re looking for something with more heft, that can handle bigger problems, you might want to check out Ansible and Ansible Tower. As noted, it provides a bevy of options, and the pieces are designed to work in concert with one another. Jenkins lacks a built-in deployment tool, though you can hook it to just about any deployment tool that you want. Ansible and Ansible Tower working together handle both sides of the CI/CD workflow: both the Continuous Integration and the Continuous Delivery.
What’s more, Ansible and Ansible Tower have in-depth, powerful user interfaces. They make it easy to understand the nuts and bolts of how your DevOps process is running. You can, at a glance, understand the current status of all the services your application depends on. That kind of insight makes it easier for you to troubleshoot issues and push your up time toward 100%.
For a long time, it was common to connect Ansible’s deployments into a step in the Jenkins continuous integration process. That worked well for a lot of teams! However, the insights and visibility provided by Ansible and Ansible Tower take you from simply automating your work to preemptively solving problems before they happen. That kind of foresight is a big part of boosting the maturity of your DevOps organization.
At the end of the day, this is the big question when comparing Ansible vs Jenkins. Jenkins remains a venerable tool. It can integrate with just about anything. But often times, those integrations mean doing a lot of manual work. If something breaks, it’ll be up to you to diagnose and fix it. Ansible and Ansible Tower unlock a whole new world of integrations directly into your deployment process. They help you move from a purely reactive process to one that anticipates problems and solves them before they impact someone. That’s one of the longer-term goals for most DevOps teams. Stop putting out fires and start giving your team tools to make better products.
But that kind of power can only take you so far. Yes, Ansible gives you great insight into the state of your environment, and keeps it running smoothly. Your environment isn’t just servers and network connections. Your environment is also the code your team writes and your users need. Ansible can make sure your services are set up correctly, but it can’t peer into your code at all. That’s where a tool like Stackify’s Retrace comes in. Retrace gives you that same kind of powerful insight you need for your environments into the code that runs on them. It not only helps you troubleshoot bugs more quickly, but it helps you identify places where future outages are likely to occur with its code analysis tools and full life cycle application platform monitoring.
Whatever tool you’re using, the goal of DevOps is continuous improvement. That means proactively taking steps to make your environment and your software more robust. How are you going to do that today?
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
