Terraform (opentofu) or ansible for provisioning?

RouterOS General
1

Hello,

Could you tell me which is currently more commonly used to configure MikroTik network gear: Terraform or Ansible?

Both have well-established community support.

https://registry.terraform.io/providers/terraform-routeros/routeros/latest

https://docs.ansible.com/projects/ansible/latest/network/user_guide/platform_routeros.html

2

Unfortunately the Mikrotik cli syntax evolves (or less charitably: is changed for no reason) very frequently. Additionally, the configuration is not at all declarative and changes are applied as you go. These make these tools less than useful, so people attempt their use from time to time, but I don't know of anyone who seriously uses them.

It's a shame, really...

3

https://registry.terraform.io/providers/terraform-routeros/routeros/latest shows a lot of activities and according to the stats widely used, so there must somebody

4

I really didn't mean to discourage you.

I just don't really see how something as simple as changing the router's ip and network from 192.168.88.1/24 to 192.168.80.1/24 would be accomplished using it.

5

you won't :wink:

that has to be figured out

that what google tolds me, basically using a temporary third IP, what makes sense

Safe IP Migration Playbook

This playbook handles the "chicken-and-egg" dilemma of network automation: it ensures you do not lock yourself out while changing the management IP address.

yaml

---
- name: Migrate MikroTik IP address and network from .88.1 to .80.1
  hosts: mikrotik_routers
  gather_facts: false
  vars:
    # NetBox dynamic inventory automatically provides the NEW IP via {{ ansible_host }}
    new_ip: "{{ ansible_host }}/24" 
    old_ip: "192.168.88.1/24"
    interface_name: "bridge" # Change to your specific interface name (e.g., ether1)

  tasks:
    - name: 1. Add new IP address to the interface (temporary dual-stack)
      community.routeros.command:
        commands:
          - /ip address add address={{ new_ip }} interface={{ interface_name }}
      # We explicitly connect to the old IP first, as NetBox already holds the new one
      delegate_to: "192.168.88.1"

    - name: 2. Switch Ansible host configuration to the new IP address
      set_fact:
        ansible_host: "192.168.80.1"

    - name: 3. Wait briefly for routing tables and ARP caches to update
      ansible.builtin.pause:
        seconds: 5

    - name: 4. Remove old IP address using the new connection path
      community.routeros.command:
        commands:
          - /ip address remove [find address="{{ old_ip }}" interface="{{ interface_name }}"]

Verwende Code mit Vorsicht.

How this works under the hood:

  • Task 1: Ansible establishes a session via the old IP (192.168.88.1) and provisions the new .80.1 subnet. The RouterOS interface now answers to both networks simultaneously.
  • Task 2 & 3: Ansible programmatically tears down the connection to the old IP, swaps its internal target variable, and pauses to let the operating system update its routing tables.
  • Task 4: Ansible establishes a fresh SSH session via 192.168.80.1 and safely purges the old configuration without risking a lockout.
6

It looks like the Ansible module is really just a fancy way of RPC/API use. The only thing it provides is executing commands. The Terraform implementation seems to have an idea about RouterOS entities - interfaces, bridge, wifi, ...

Which is pretty surprising, because how are you going to write idempotent Ansible tasks with that? Like "make sure this IP address is on this interface"? You will never achieve a "green" run unless you use "changed_when: never". But then your runs will always be "green".

Although I am way more familiar with Ansible, I would try Terraform if I was in your position.

7

This is not using the referenced terraform provider. This is simply a playbook issuing mikrotik cli commands - of course this is totally fine, but at this point you're just configuring the device manually.

The playbook btw won't work. How would the computer on which it is running reach the router on the new address?

8

haven't gone into the details (as this is not the prupose of the this thread)

thx so I start diving into this, Mikrotik automation using Terraform : r/mikrotik and How do you automate your Mikrotik devices configuration? Script? Terraform? : r/mikrotik are a good place

maybe it a is better interface for many who are used to work with the terminal and script (snipplets). The knowledge is with the user

9

That's because that play is Ansible, not Terraform.

10

Well ... no. The idea of Ansible is that your plays describe a state that is to be provisioned. And Ansible is supposed to have knowledge of all the artefacts involved.

For example in the case of a Linux of BSD package you state "package NginX - present". Ansible is supposed to know how the package management on the target platform works and install it if not yet present - flagging the task as "yellow" in the final report. And on repeated invocations recognise that the package is installed already, and not do anything but flag the task as "green" in the final report. The same on each subsequent invocation.

At some point all your tasks are to be flagged as "green" and you can run Ansible again and again and again and it would not that everything is already done according to specs and not do anything but report "all green".

That's what idempotency means.

If you use Ansible to execute commands on whatever platform, you cannot implement that. But you are holding it wrong :wink:

Kind regards,
Patrick