Migration existing infrastructure to another provider

Icinga 2
,
1

Hey Icinga experts,

I would like to discuss with about a project I would start: migrate my Icinga2 infrastructure to an another cloud provider.

Right now, my implementation is pretty simple (all virtualized):

  • 2 master
  • 2 satellites
  • 1 MySQL
    1700 hosts, 19000 active checks, 3000 passive checks ( I don’t use the Icinga2 Client, I have my own Windows Service developed internally).
  • Icinga Director for configuration management

I would move to a new Public Cloud Provider, but what’s the best approach in your opinion? Should I install a full new infrastructure into my new provider and then import Director configuration inside? Or Should I “extend” my existing infrastructure to the new provider and then just delete old master and old satellite from Icinga2 configuration?

Honestly, I would prefer to start with a fully fresh infrastructure without communication with old infrastructure. But this is just my novice opinion.

Thanks for your advice :slight_smile:

Kevin

2

the easiest would be to spin up the new environment and then import the director config. That way you can check for errors that may be happening

3

You need to replace your configuration master anyway, so starting with a new host and then importing the configuration seems like the way to go.

You should be able to take your CA to the new hosts, though.

4

Ok thanks both of you. About the importing of the director config. Should I just make a dump of the the mysql database? Is there an export feature integrated to the Director module?

5

It depends on the director version. The latest version comes with the handy basket feature, which helps exporting your config. But be aware of the bug which prevents the export of dependencies: https://github.com/Icinga/icingaweb2-module-director/issues/1739

2 Likes
6

You should have a database dump as a backup, and if nothing else works, use this - with slight adoptions for imported endpoints and the resulting FQDN.

In terms of re-using the CA … I would honestly use a new one, to disallow accidental wrong config, or breaches from the old setup. That’s only true if no migration is planned though.

One thing which should be kept in mind are the plugins - if they’re not installed from packages, do an inventory and collect a list of dependencies required. Best is to have the new infrastructure on the same distribution and version, but who knows if that’s possible.

Cheers,
Michael