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.