diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-14 13:17:31 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-14 13:17:31 +0000 |
commit | f66ab8dae2f3d0418759f81a3a64dc9517a62449 (patch) | |
tree | fbff2135e7013f196b891bbde54618eb050e4aaf /doc/03-Automation.md | |
parent | Initial commit. (diff) | |
download | icingaweb2-module-director-f66ab8dae2f3d0418759f81a3a64dc9517a62449.tar.xz icingaweb2-module-director-f66ab8dae2f3d0418759f81a3a64dc9517a62449.zip |
Adding upstream version 1.10.2.upstream/1.10.2
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/03-Automation.md')
-rw-r--r-- | doc/03-Automation.md | 134 |
1 files changed, 134 insertions, 0 deletions
diff --git a/doc/03-Automation.md b/doc/03-Automation.md new file mode 100644 index 0000000..ca3d1d3 --- /dev/null +++ b/doc/03-Automation.md @@ -0,0 +1,134 @@ +<a id="Automation"></a>Automation - Configuration management +============================================================ + +Director has been designed to work in distributed environments. In case +you're using tools like Puppet, Ansible, Salt (R)?ex or similar, this +chapter is what you're looking for! + +Generic hints +------------- + +Director keeps all of its configuration in a relational database. So, +all you need to tell him is how it can reach and access that db. In case +you already rolled out Icinga Web 2 you should already be used to handle +resource definitions. + +The Director needs a `database resource`, and your RDBMS must either by +MySQL, MariaDB or PostgreSQL. This is how such a resource could look like +in your `/etc/icingaweb2/resources.ini`: + +```ini +[Director DB] +type = "db" +db = "mysql" +host = "localhost" +dbname = "director" +username = "director" +password = "***" +charset = "utf8" +``` + +Please note that the charset is required and MUST be `utf8`. + +Next you need to tell the Director to use this database resource. Create +its `config.ini` with the only required setting: + +```ini +[db] +resource = "Director DB" +``` + +Hint: `/etc/icingaweb2/modules/director/config.ini` is usually the full +path to this config file. + +#### Schema creation and migrations + +You do not need to manually care about creating the schema and to migrate +it for newer versions. Just `grant` the configured user all permissions on +his database. + +On CLI then please run: + + icingacli director migration run --verbose + +You should run this command after each upgrade, or you could also run it +at a regular interval. Please have a look at... + + icingacli director migration pending --verbose + +...in case you are looking for an idempotent way of managing the schema. +Use `--help` to learn more about those commands. + +If you have any good reason for doing so and feel experienced enough you +can of course also manage the schema on your own. All required files are +to be found in our `schema` directories. + + +Deploy Icinga Director with Puppet +---------------------------------- + +Drop the director source repository to a directory named `director` in +one of your `module_path`'s and enable the module as you did with all the +others. + +Deploy the mentioned database resource and `config.ini`. Director could +now be configured and kick-started via the web frontend. But you are here +for automation, so please read on. + +### Handle schema migrations + +It doesn't matter whether you already have a schema, did a fresh install +or just an upgrade. Migrations are as easy as defining: + + exec { 'Icinga Director DB migration': + path => '/usr/local/bin:/usr/bin:/bin', + command => 'icingacli director migration run', + onlyif => 'icingacli director migration pending', + } + +Hint: please do not travel back in time, schema downgrades are not +supported. + +### Kickstart an empty Director database + +The Director kickstart wizard helps you with setting up a connection to +Icinga2 master node, import its endpoint and zone definition and it also +syncs already configured command definitions. But this wizard is not only +available through the web frontend, you can perfectly trigger it in an +idempotent way with Puppet: + + exec { 'Icinga Director Kickstart': + path => '/usr/local/bin:/usr/bin:/bin', + command => 'icingacli director kickstart run', + onlyif => 'icingacli director kickstart required', + require => Exec['Icinga Director DB migration'], + } + +Nothing will happen so far. Kickstart will not do anything unless you +drop a `kickstart.ini` allowing the CLI kickstart helper to do so: + +```ini +[config] +endpoint = icinga-master +; host = 127.0.0.1 +; port = 5665 +username = director +password = *** +``` + +Usually `/etc/icingaweb2/modules/director/kickstart.ini` should be the +full path to this file. `endpoint` (master certificate name), `username` +and `password` (fitting an already configured `ApiUser`) are required. +`host` can be a resolvable hostname or an IP address. `port` is 5665 per +default in case none is given. And of course your Icinga2 installation +needs to have a corresponding `ApiListener` (look at your enabled +features) listening at the given port. + +You can run the `kickstart` from the CLI if you don't use a tool for +automation. + + icingacli director kickstart run + +You can rerun the kickstart if you have to reimport changed local +config, even when the beforementioned check tells you you don't need to. +Or you could use the import/synchronisation features of Director. |