Managing multiple routers

[baragoon]

What documentation needs updating?:

• README

What needs to be added to the documentation?:

• Example of managing multiple routers.

Hi all, I'm new to the Terraform world and trying to understand how to use this provider to bulk manage a multiple routers.
Do I need to separate each router to the different folder with own main.tf files or it's possible to manage all them via single "project"?
Any examples will be very usefull.

Thank you in advance.

[vaerh]

Hi!
The terraform concept implies that one project is created for one router, as the connection parameters are specified in the provider settings. You should also keep in mind that in case of local storage of a state file, one file is created within one project (folder). Perhaps this behavior can be changed using workspaces, but it is better to check in the documentation.
I would also like to mention terragrant. I haven't used it, but if I'm not mistaken, it allows you to dynamically change provider settings within one project.

[javierbertoli]

I've used a setup like this in the past:

./backends/
./configs/mk1/router.backend.tfvars
./configs/mk1/router.tfvars
./configs/mk2/router.backend.tfvars
./configs/mk2/router.tfvars
backend.tf

The backend files contain the path to the tfstate file:

• ./configs/mk1/router.backend.tfvars

path = "backends/mk1.terraform.tfstate"

• ./configs/mk2/router.backend.tfvars

path = "backends/mk2.terraform.tfstate"

The backend.tf file:

terraform {
  backend "local" {}
}

Then, to config one mk or the other, run:

terraform init -backend-config configs/mk2/router.backend.tfvars -reconfigure -upgrade
terraform plan -refresh -var-file configs/mk2/router.tfvars
terraform apply -var-file configs/mk2/router.tfvars

[tofkamp]

I do it differently. I have made a module which config just one switch according the given parameters. I have one file per switch, with just the config of the provider to the switch (the ip and login). In this file (per switch) I also have the desired config in data objects. I have a list of access ports with their vlan-nr. And a list of trunk ports, with their list of vlans. I might also have a MLAG config to the central core switches.
I call the module with all those parameters, and the module makes sure it creates the required resources.
One lessons I have learned it NOT to call your provider the same as the name of the switch it points to. Our naming convention is calling the switch to the location of the switch (dc-location, rack-nr, switch-nr). When moving a switch to another rack, it gives a lot of trouble if the provider has the same name as the switch. I just call the providers "switch". When moving a switch, I just change the identity parameter in the call to the module.

Downside of this setup is that when you have a lot of switches (>20), it takes a lot of time to determine what has to be changed. A quick fix is not possible anymore. Terraform is not the fastest, and does not parallelizes the requests equal to the number of providers. I have one switch which is a bit cheaper (arm), and it is slow. It cannot handle to much requests at a time, so I set TFE_PARALLELISM=2, which slows it down even more :-(. It would be good if I could config the number of processes per provider, but that is not possible. I solved this by grouping switches to several separate terraform-runs.
If you just have a few switches, it will not be a problem.

[durandguru]

I also use an module to configure stuff. Per switch/router an tfvars file with the specific settings. In the module I read those values and depending on the settings I do stuff, for example vlans one method 1 and for other switch on method 2. In the process on moving stuff to seperate modules, makes it easier to add stuff.

[javierbertoli]

I don't want to hijack the conversation, but I think this might be helpful for newcomers to this provider (as @baragoon). I uploaded a project to make it easier to manage MK devices using the code from this provider. There is lot of room for improvement and probably can be merged or superseded with some other better project/module. I just didn't find one when I started with this 😃

Most of the configurations can be set as variables in the *tfvars files (you can check the examples and some defaults are set in locals.tf when possible.

Any comments/suggestions/PRs are welcome.

Again, hope this helps.

[baragoon]

Thank a lot, guys!
I think I'll go ahead with terragrunt as @vaerh mentioned.
@javierbertoli wow, this is very usefull, forked!

[vaerh]

Friends, thank you for your interest in the project!
Judging by your comments, it looks like the real Unix way. The same result is achieved in different ways.
So if you have interesting code samples that can help others, we can add them to the guides section.

[OJFord]

No just declare the provider twice with different aliases, e.g. I have:

provider "routeros" {
  alias = "router"
  // ...
}

provider "routeros" {
  alias = "modem"
  // ...
}

and then when you use a routeros resource you just specify provider = routeros.modem or whichever one.

If you don't specify an alias that's the default.

Docs here: https://developer.hashicorp.com/terraform/language/providers/configuration#alias-multiple-provider-configurations

[bdowne01]

We're using this great provider to manage a fleet of about 35 routers. Our technique was to create a generic standardized module that takes care of setting up the standard settings every time. Each router's configuration is passed as variables.

I use a map of objects to pass in specifics about each interface. Things like BGP Peer, addresses, etc are attributes of each object in the map.

This creates a configuration that's standardized across the fleet and allows you do to for_each in the standard module to build things like ethernet interfaces and loopbacks. It was a bit of upfront work, but it's glorious once you get it.