Draft
Conversation
53e22d1 to
d3fd7cd
Compare
d3fd7cd to
c59f39d
Compare
Member
Author
|
Since we've talked about this @mkayontour, I now have a working playbook example (I hope). The comments should explain everything in here. Also, there are no fancy variables on my hosts. They simply belong to either group - name: Test PR
become: true
# serial 1 because master needs to be running before it can accept PKI requests
# So, we go through master/satellites layer by layer, starting with master 1 (then master 2), then satellites underneath master(s), then satellites under those satellites, etc.
serial: 1
hosts:
- ansible-ubuntu24 # master 1
- ansible-ubuntu22 # master 2
- ansible-debian12 # satellite
vars:
# Needed in my env because my FQDNs are bad
icinga2_config_host: "{{ inventory_hostname }}"
icinga2_constants:
# We generally need a ticket on master 1
TicketSalt: "{{ 'some-secret' if inventory_hostname == 'ansible-ubuntu24' else '' }}"
NodeName: "{{ inventory_hostname }}"
# All you got to define is that you want the API feature + some extras
# zones, endpoints, and ca host/port will be gathered and used (through 'icinga2_zone_hierarchy')
# First master will always be ca host
icinga2_features:
- name: api
# again, my FQDNs are bad
cert_name: "{{ inventory_hostname }}"
accept_config: true
accept_commands: true
# Define all global zones
icinga2_global_zones:
- "director"
- "global-templates"
# Define the hierarchy of the environment
# Each key is either an 'inventory_hostname' or an Ansible group name
# Indents mean that zones are underneath the prior zone
# Multiple keys within the same (top) key are satellites at the same level of depth (different zones, same parent zone)
icinga2_zone_hierarchy:
master:
sat:
roles:
- netways.icinga.repos
- netways.icinga.icinga2 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is currently still work in progress.
This PR will introduce a simple variable (nested dictionary) to define the zone hierarchy.
The corresponding action plugin creates the zones and endpoints for each host according to the variable.
Each host will only know those zones and endpoints it has to know.
Example:
From this, the plugin will create zones and endpoints based on available variables.
It only returns information. Using the information is still up to the role!
Feedback
There is still a need for a proper way to define variables which will be used for the endpoints
hostattribute.2 hosts could have the same parent but in different networks (2 firewall zones for example).
We must be able to provide some kind of mapping to tell a given host the correct address when it wants to access its parent.
If B wants to access A, it needs IP-1.
If C wants to access A, it needs IP-2.
This mapping must be defined somewhere.
As a fallback, we can always use
inventory_hostname.