The default configuration of Icinga 2 has several includes inside icinga2.conf. One of them is include <itl> followed by include <plugins> and others. This ensures that these objects are compiled by the config compiler and are available as configuration objects e.g. referenced in host/service objects.
These are examples and should help you with the first start with Icinga 2. Originally there was no Director or a Puppet module to manage configuration in a different way. If you are using a different method than the static configuration, it is strongly advised to remove the conf.d inclusion in icinga2.conf.
The node wizard setup CLI commands do that by default, allowing the Director to deploy into an “empty” Icinga. If you keep conf.d enabled and deploy a Host object from the Director which matches the local node name, you will receive duplicated object errors.
That being said, I strongly advise against mixing different configuration sources, unless you exactly know what consequences are involved here. Imho you should use the Director as trust source, and use nothing else.
The ITL objects as external reference are there for user convenience reasons. You can of course drop the include and create everything by hand by yourself. Still the Commands found inside the ITL contain years of best practice, time you save when starting with Icinga.
Not sure what “environment” and “namespace” mean here. The things you need inside the Director to create a host object is a host template, and following the host object(s). Same applies to service templates and objects/apply rules/sets.
It doesn’t hurt to understand the static DSL before diving into the Director though. This helps to understand configuration deployment errors better for instance.
Apply rules generate objects. If you change e.g. the service apply rule name, this generates a different object. Still, you now have two objects with the same purpose - and doubled checks, possible notifications, etc.
Well, with the example I still don’t know where you’re heading. What is the idea behind defining the apply rules externally? Do you have a concrete example for such a rule which cannot be built with the Director?
Cheers,
Michael