Browse Source

docs: references to services from the user guide

keep-around/edee62355558f928bc5f222ad3c931912dde474f
Loïc Dachary 1 year ago
parent
commit
edee623555
No known key found for this signature in database GPG Key ID: F3C139FB4D35D559
  1. 3
      docs/services/index.rst
  2. 93
      docs/services/monitoring.rst
  3. 92
      docs/services/monitoring_architecture.rst
  4. 10
      docs/user-guide.rst

3
docs/services/index.rst

@ -11,8 +11,7 @@ Services
ids
authorized_keys
backup
monitoring_architecture
monitoring_howto
monitoring
weblate
gitlab
mattermost

93
docs/services/monitoring_howto.rst → docs/services/monitoring.rst

@ -227,3 +227,96 @@ using the Ansible variable ``monitoring_host_vars``. Se e.g.
``inventories/common/host_vars/icinga-host/monitoring.yml`` for an example.
Default is empty.
Monitoring architecture
=======================
Icinga2 overview
----------------
Icinga2 is very flexible and doesn't impose monitoring
architecture. So we have to define it. The simplest is to follow the
`master with clients
setup <https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#master-with-clients>`__. It implies:
- getting a master server (including web GUI),
- getting a client for each VM on which you would execute checks.
Icinga2 uses the same software for clients and masters and their
configuration defines if one is master or client. We can use the same
configuration objects for master and clients.
Our master server deployment is defined in `molecule/icinga/roles/icinga2`.
Our client deployment is defined in `molecule/icinga/roles/icinga2_client`.
Executables checks are managed locally on each computer, as
well as required sudo permissions. To deploy them, a common role is defined in
`molecule/icinga/roles/icinga2_common`.
Icinga2 define "zones", which is a way to control information sharing
over the monitoring infrastructure. We define:
- a global zone for the configuration shared among all the cluster;
- a master zone for the master;
- a client zone for each client which the master zone as a parent.
Client dont't know about each other (the master will distribute only
what is required).
Molecule test environment
-------------------------
In `molecule/icinga`, we define a test environment with a master and a client.
A set up for Icinga2 needs master and clients, NginX, Icingaweb2
and Let's Encrypt. Tests are checking that the playbook is well executed.
Apply logic style
-----------------
Icinga2 uses the "`apply logic style
<https://www.icinga.com/docs/icinga2/latest/doc/08-advanced-topics/#advanced-use-of-apply-rules>`__".
All behavior is described using a language (including list and
associative array), as an host attribute (e.g. a list of hardware
block devices, a list of mounted volumes, a list of vhosts and some
associated attributes, a list of process you would like to
check and their associated limits, a list of git repos to be checked,
etc.)
Based on those attributes provided, generic service can be defined.
Here is how one can check all the certificates of all the vhosts which
are declared to use TLS:
::
apply Service ""Check TLS certificate "" for (http_vhost => config in host.vars.http_vhosts) {
import ""generic-service""
check_command = ""http""
vars.http_address = config.http_vhost
command_endpoint = "" ... ""
vars.http_certificate = 21
vars.http_sni = true
vars += config
assign where config.http_ssl == true
}
with n host which contains this declaration:
::
vars.http_vhosts[""Forum""] = {
http_vhost = ""forum.enough.community""
http_ssl = true
}
The main monitoring configuration for enough.community is available in
`molecule/icinga/roles/icinga2/files/services/` and deployed in the
global Icinga zone, thus available to all the cluster.
There are checks for vhosts, DNS zones consistency, DNS views
consistency, attended processes, attended vhosts, attended output IPs,
git repos, mails queues, services banners (ssh, smtp, etc.), upgrades,
running kernels, mailname consistency, volumes, databases, etc.

92
docs/services/monitoring_architecture.rst

@ -1,92 +0,0 @@
Monitoring architecture
=======================
Icinga2 overview
----------------
Icinga2 is very flexible and doesn't impose monitoring
architecture. So we have to define it. The simplest is to follow the
`master with clients
setup <https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#master-with-clients>`__. It implies:
- getting a master server (including web GUI),
- getting a client for each VM on which you would execute checks.
Icinga2 uses the same software for clients and masters and their
configuration defines if one is master or client. We can use the same
configuration objects for master and clients.
Our master server deployment is defined in `molecule/icinga/roles/icinga2`.
Our client deployment is defined in `molecule/icinga/roles/icinga2_client`.
Executables checks are managed locally on each computer, as
well as required sudo permissions. To deploy them, a common role is defined in
`molecule/icinga/roles/icinga2_common`.
Icinga2 define "zones", which is a way to control information sharing
over the monitoring infrastructure. We define:
- a global zone for the configuration shared among all the cluster;
- a master zone for the master;
- a client zone for each client which the master zone as a parent.
Client dont't know about each other (the master will distribute only
what is required).
Molecule test environment
-------------------------
In `molecule/icinga`, we define a test environment with a master and a client.
A set up for Icinga2 needs master and clients, NginX, Icingaweb2
and Let's Encrypt. Tests are checking that the playbook is well executed.
Apply logic style
-----------------
Icinga2 uses the "`apply logic style
<https://www.icinga.com/docs/icinga2/latest/doc/08-advanced-topics/#advanced-use-of-apply-rules>`__".
All behavior is described using a language (including list and
associative array), as an host attribute (e.g. a list of hardware
block devices, a list of mounted volumes, a list of vhosts and some
associated attributes, a list of process you would like to
check and their associated limits, a list of git repos to be checked,
etc.)
Based on those attributes provided, generic service can be defined.
Here is how one can check all the certificates of all the vhosts which
are declared to use TLS:
::
apply Service ""Check TLS certificate "" for (http_vhost => config in host.vars.http_vhosts) {
import ""generic-service""
check_command = ""http""
vars.http_address = config.http_vhost
command_endpoint = "" ... ""
vars.http_certificate = 21
vars.http_sni = true
vars += config
assign where config.http_ssl == true
}
with n host which contains this declaration:
::
vars.http_vhosts[""Forum""] = {
http_vhost = ""forum.enough.community""
http_ssl = true
}
The main monitoring configuration for enough.community is available in
`molecule/icinga/roles/icinga2/files/services/` and deployed in the
global Icinga zone, thus available to all the cluster.
There are checks for vhosts, DNS zones consistency, DNS views
consistency, attended processes, attended vhosts, attended output IPs,
git repos, mails queues, services banners (ssh, smtp, etc.), upgrades,
running kernels, mailname consistency, volumes, databases, etc.

10
docs/user-guide.rst

@ -124,14 +124,14 @@ The following services are available:
* :doc:`bind <services/bind>` for `DNS server <https://www.isc.org/bind/>`__ at ``bind.examples.com``
* ``api``, for :doc:`Enough development <community/contribute>` at ``api.example.com``
* ``chat``, for `instant messaging <https://mattermost.com/>`__ at ``chat.example.com``
* ``cloud``, for `file sharing <https://nextcloud.com/>`__ at ``cloud.example.com``
* :doc:`chat <services/mattermost>`, for `instant messaging <https://mattermost.com/>`__ at ``chat.example.com``
* :doc:`cloud <services/enough>`, for `file sharing <https://nextcloud.com/>`__ at ``cloud.example.com``
* ``forum``, for `discussions and mailing lists <https://www.discourse.org/>`__ at ``forum.example.com``
* ``gitlab``, for `software development <https://gitlab.com/>`__ at ``lab.example.com``
* :doc:`gitlab <services/gitlab>`, for `software development <https://gitlab.com/>`__ at ``lab.example.com``
* ``openvpn``, for `VPN <https://openvpn.net/>`__ at ``openvpn.example.com``
* ``packages``, a `static web service <https://www.nginx.com/>`__ at ``packages.example.com``
* ``pad``, for `collaborative note taking <https://etherpad.org/>`__ at ``pad.example.com``
* ``weblate``, for `online translations <https://weblate.org/>`__ at ``weblate.example.com``
* :doc:`weblate <services/weblate>`, for `online translations <https://weblate.org/>`__ at ``weblate.example.com``
* ``website``, for `static websites <https://gohugo.io/>`__ at ``website.example.com``
* ``wekan``, for `kanban <https://wekan.github.io/>`__ at ``wekan.example.com``
* ``wordpress``, for `blog <https://wordpress.org/>`__ at ``wordpress.example.com``
@ -158,7 +158,7 @@ Services
The following services are always available:
* :doc:`icinga <services/monitor>` for `monitoring <https://icinga.com/>`__ at ``icinga.example.com``.
* :doc:`icinga <services/monitoring>` for `monitoring <https://icinga.com/>`__ at ``icinga.example.com``.
* :doc:`wazuh <services/ids>` for `Intrusion Detection System <https://wazuh.com/>`__ at ``wazuh.example.com``.
* :doc:`postfix <services/postfix>` for `SMTP server <http://www.postfix.org/>`__ at ``postfix.example.com``.
* `security groups <https://docs.openstack.org/nova/train/admin/security-groups.html>`__ for :ref:`firewall <firewall>`.

Loading…
Cancel
Save