n8n vs. Ansible: The Automation Choice

Posted on In Views:

Discover why n8n’s visual workflow design beats Ansible for personal automation

Recently, n8n has been highly popular on the web, one of the reasons is riding on the AI trend, and the other is because n8n has an excellent GUI.

I used to use Ansible as my main workflow management tool, but I took the opportunity to try n8n for a couple of recent requirements, and I decided to give up ansible on the spot and use n8n only for personal use in the future. Why? Let’s check it out.

Before we get into the main topic, let’s talk about why we need a workflow management tool such as ansible or n8n.

When we have a task that we do over and over and over again, we can use a workflow management tool to automate this repeated operation.

There are many possible scenarios for duplication. For example, when we are doing an approval, and we receive a request for an approval, we will look up the data somewhere and then verify the eligibility of a certain place and then approve or disapprove it.

On the other hand, when we are managing many homogeneous systems, such as multiple k8s clusters, what we may do is to switch the kube context and then connect to it to find out the specific pod and then play the command to see the result. If there are 10 clusters, then do it 10 times.

Either way, it’s a duplication that can be automated with a workflow management tool.

What’s good about n8n?

Let’s use the above example to do a demo.

I need to upload a script to all k8s clusters that collects the state of a pod in each cluster. The collected state is stored in a csv file on the pod, so I have to download the results back. Each cluster has to do this cycle once, so here is my workflow.

For those who are familiar with n8n, you can see that I don’t use any special node at all, it’s almost all Execute Command and Code nodes, and then interspersed with some control nodes, such as Loop and If.

This way the whole thing can be automated, I just need to use a n8n built-in form, yes, even the form can be automatically generated by n8n to input parameters and drive the whole process.

The parameters are just the label of the pod, and some file parameters, such as where to upload the script, where to upload the script to, where to download the file, and where to download the file to. If we feel the built-in form is not pretty, we can write our own webpage to do some file dialog, so we don’t need to write the path by hand.

You might say that ansible can do it, and that skilled people write ansible very quickly. In fact, I did start out using ansible. Don’t look at this workflow as simple, but ansible is a playbook of almost a thousand lines, mainly for the following reasons.

Whether you are uploading or downloading, remote or local, you need to determine if the file exists. Determining the existence of a file is not difficult, but passing the status in ansible is quite cumbersome. The state is passed through register, and we have to be careful to avoid repeating keywords, which can lead to hidden problems.

In addition to state passing, another big problem in ansible is the handling of loops. How to make a task fail with a retry, but continue to run after the retry fails, only to record the state so that it can generate a report on the execution. This is also a headache. It can be done, but it’s a bit of a pain in the ass.

Let’s take a look at the two scenarios mentioned above and see what they look like in n8n.

The last two nodes are Execute Command nodes, which are BASH nodes. What they’re trying to do is something like this.

1
2
3
4
5
6
kubectl exec   
--kubeconfig {{ $('Pick one').item.json.kubeconf }}  
{{ $('Pick one').item.json.name }}   
-n {{ $('Pick one').item.json.namespace }}   
-c {{ $('Pick one').item.json.container }}   
-- {{ $('Keep loop items').item.json.command }}

These variables framed in curly brackets are actually the outputs of the previous nodes, and I can specify which node I want to fetch which output from, or even just drag and drop it on the UI.

Another case is loop processing.

After the previous node generates the list of kube context, simply call a Loop node and iterate. Although n8n has its pitfalls in loop handling, for example, you need to have a node to enrich the loop items, otherwise the node after the Loop will not see the fixed constants.

But this is much easier to deal with than ansible.

Why did I abandon ansible?

Troubleshooting was the final straw for me.

When I write a huge ansible playbook and run it with high expectations, it fails. The reason for the failure is when the pod I’ve locked with a label in the previous step just dies, then all the subsequent steps will fail. It doesn’t matter, just let it pick the next pod and start again.

In fact, that’s what I was thinking. But I suddenly realized that I couldn’t change ansible much, because it’s too big and it was written without design, so it’s badly modularized. I didn’t know where to start with a round robin requirement. At that moment, I decided to switch to n8n.

I’m actually a newbie to n8n, I’ve never used it before, so I followed the instructions on the official website and installed it and started writing.

First, I reproduced the full playbook, which took me less than half a day to complete by dragging and dropping it through the UI. Then we came to implement the annoying round robin mechanism. That’s the fallback line you see in the workflow.

I simply used redis to make a counter to keep adding up, but during the Pick one phase I would mod the number of running pods, which simply created a round robin mechanism. It really only took me a few minutes to add this mechanism, which I believe is the biggest advantage of n8n.

How to test such a fast modification can really work, after all, there are not always pods going down, right? In n8n, there is a mechanism called mock output, which requires only one UI click to open and conduct localized tests on the workflow.

Indeed, there is a similar mechanism in ansible, but the workflow has to be well modularized, otherwise it’s hard to do something similar.

Wrap Up

Ansible is a great workflow tool, and I’ve always thought so.

But the premise is that each workflow must know the whole picture, and be well designed and modularized in order to respond to the subsequent needs.

In n8n, we don’t need that kind of design. A fancy UI solves a lot of problems. Take the partial test as an example, n8n is so easy to do partial test, each node can be executed individually, and even the output can be simulated directly.

If the workflow implementation process found that some processes are not taken into account, it is also an easy way to process change in the whole overview.

It can be said, a well-designed UI solves a lot of difficulties and complexity in ansible development, which is also the reason I abandoned ansible. Sometimes we have a quick idea that needs to be validated, and it’s extremely easy to implement a POC and iterate on the requirements on n8n.

However, on ansible, just the preliminary design phase alone will take a lot of time and effort.

Therefore, in the future, I can say as long as it’s a personal requirement, I will always prioritize n8n over ansible, which is what I’ve been using most often in the past.

Thank you for being a part of the community

Before you go:

Originally published on Medium