ARCHIVÉ

Ce projet n'est plus maintenu. Pour des alternatives pour commencer, vous pouvez essayer l'une de ces options :

• Démarrez un essai gratuit sur Elastic Cloud, notre service hébergé.
• Consultez Elastic Cloud sur Kubernetes (ECK) pour lancer la pile via Kubernetes.
• Lisez notre guide sur Exécution de l'Elastic Stack sur Docker.
• Jetez un œil au fournisseur Terraform d'Elastic Stack.

ansible-beats

Ce rôle fournit un moyen générique d'installer les Beats pris en charge par Elastic.

Beats testés

• Filebeat
• MetricBeat (TopBeat en 1.x)
• Packetbeat

Versions testées

• 7.x
• 6.x

Plateformes testées

• Ubuntu 16.04
• Ubuntu 18.04
• Ubuntu 20.04
• Debian 8
• Debian 9
• Debian 10
• CentOS 7
• Amazon Linux 2

Utilisation

Créez votre playbook Ansible avec vos propres tâches et incluez le rôle beats. Vous devez avoir ce dépôt accessible dans le contexte du playbook.

ansible-galaxy install elastic.beats,v7.17.0

Ensuite, créez votre fichier yaml de playbook en ajoutant le rôle beats. L'application du rôle beats entraîne l'installation d'un nœud sur un hôte.

La configuration la plus simple consiste donc en :

  hosts: localhost
  roles:
    - role: elastic.beats
  vars:
    beats_version: 7.17.0
    beat: filebeat
    beat_conf:
      filebeat:
        inputs:
          - type: log
            enabled: true
            paths:
              - /var/log/*.log

Cela installe Filebeat 7.17.0 sur l'hôte 'localhost'.

Remarques :

• La version par défaut des Beats est décrite dans beats_version. Vous pouvez remplacer cette variable dans votre playbook pour installer une autre version. Bien que nous ayons testé ce rôle uniquement avec une version 7.x et une 6.x (respectivement 7.17.0 et 6.8.23 au moment de l'écriture), ce rôle devrait également fonctionner avec d'autres versions dans la plupart des cas.
• Le produit Beat est décrit dans la variable beat. Bien que les Beats actuellement testés soient Filebeat, Metricbeat et Packetbeat, ce rôle devrait également fonctionner avec d'autres membres de The Beats Family dans la plupart des cas.

Tests

Ce playbook utilise Kitchen pour l'intégration continue et les tests locaux.

Exigences

• Ruby
• Bundler
• Docker
• Make

Exécution des tests

Pour converger un hôte Ubuntu 18.04

$ make converge

Pour exécuter les tests

$ make verify

Pour lister tous les différents ensembles de tests

$ make list

L'ensemble de tests par défaut est Ubuntu 18.04. Si vous souhaitez tester un autre ensemble, vous pouvez remplacer cela par la variable PATTERN.

$ make converge PATTERN=standard-centos-7

Le PATTERN est un modèle de cuisine qui peut correspondre à plusieurs ensembles. Pour exécuter tous les tests pour CentOS

$ make converge PATTERN=centos-7

Lorsque vous avez terminé les tests, vous pouvez tout nettoyer avec

$ make destroy-all

Configuration de base des Beats

Tous les paramètres de configuration des Beats sont pris en charge. Cela est réalisé en utilisant un paramètre de carte de configuration beat_conf, qui est sérialisé dans le fichier ${beat}.yml. L'utilisation d'une carte garantit que le playbook Ansible n'a pas besoin d'être mis à jour pour refléter les nouveaux/dépréciés/paramètres de configuration de plugin.

En plus de la carte beat_conf, plusieurs autres paramètres sont pris en charge pour des fonctions supplémentaires, par exemple, l'installation de scripts. Ceux-ci peuvent être trouvés dans le fichier defaults/main.yml du rôle.

Ce qui suit illustre l'application de paramètres de configuration à une instance de Packetbeat.

- name: Exemple de playbook pour installer packetbeat
  hosts: localhost
  roles:
    - { role: beats, beat: "packetbeat",
        beat_conf: {
          "interfaces": {"device":"any"},
          "protocols": {
            "dns": {
              "ports": [53],
              "include_authorities":true
            },
            "http": {
              "ports": [80, 8080, 8000, 5000, 8002]
            },
            "memcache": {
              "ports": [11211]
            },
            "mysql": {
              "ports": [3306]
            },
            "pgsql": {
              "ports": [5432]
            },
            "redis": {
              "ports": [6379]
            },
            "thrift": {
              "ports": [9090]
            },
            "mongodb": {
              "ports": [27017]
            }
          }
        },
        output_conf : {
          "elasticsearch": {
            "hosts": ["localhost:9200"]
          }
        }
    }
  vars:
    use_repository: "true"

Configuration supplémentaire

Les variables prises en charge sont les suivantes :

• beat (OBLIGATOIRE) : Produit Beat. Valeurs prises en charge : "filebeat", "metricbeat" et "packetbeat" (d'autres Beats de The Beats Family devraient fonctionner dans la plupart des cas mais ne sont pas actuellement testés).
• beat_conf (OBLIGATOIRE) : Configuration Beat. Doit être définie comme une carte.
• beats_version (Par défaut 7.17.0) : Version des Beats.
• version_lock (Par défaut false) : Verrouille la version installée si défini sur true, empêchant ainsi d'autres processus de la mettre à jour. Cela n'affectera pas la capacité des rôles à mettre à jour le beat lors des exécutions suivantes (il déverrouille et reverrouille si nécessaire).
• use_repository (Par défaut true) : Utiliser le dépôt Elastic pour yum ou apt si true. Si false, une custom_package_url doit être fournie.
• beats_add_repository (Par défaut {use_repository}) : Installer le dépôt Elastic pour yum ou apt si true. Si false, les dépôts présents seront utilisés. Utile si vous avez déjà des paquets Beats dans votre dépôt.
• start_service (Par défaut true) : Le service sera démarré si true, false sinon.
• restart_on_change (Par défaut true) : Les modifications de configuration ou de versions installées entraîneront un redémarrage si true.
• daemon_args (Applicable à la version 1.x des Beats) : Permet de passer des paramètres d'exécution aux Beats.
• logging_conf (Par défaut {"files":{"rotateeverybytes":10485760}}) : Configuration du logging. Doit être définie comme une carte. La carte est sérialisée dans la section de logging de la configuration du beat.
• shipper_conf (Applicable à la version 1.x des Beats) : Configuration de Shipper. Doit être définie comme une carte. La carte est sérialisée dans la section shipper de la configuration du beat.
• output_conf (Par défaut {"elasticsearch":{"hosts":["localhost:9200"]}}) : Configuration de sortie. La carte est sérialisée dans la section de sortie de la configuration du beat.
• beats_pid_dir (Par défaut /var/run) : Emplacement du fichier pid des Beats.
• beats_conf_dir (Par défaut /etc/{beat}) : Emplacement du répertoire de configuration pour le fichier de configuration des Beats.
• default_ilm_policy (Par défaut non défini) : chemin local vers la politique par défaut si une politique personnalisée est définie.

Accent sur l'ILM

Par défaut, beat créera une politique par défaut définie dans le cadre du déploiement du beat. Vous pouvez remplacer la configuration ILM par défaut en définissant la configuration ILM comme partie de beat_conf. Par exemple :

- role: ansible-beats
  beat: metricbeat
  beat_conf:
    setup:
      ilm:
        policy_file: /etc/filebeat/policies/my-default-metricbeat.json
        overwrite: true
      metricbeat.modules:
        ...
  default_ilm_policy: conf/my-default-metricbeat.json
  become: yes

Cela copiera conf/my-default-filebeat.json dans /etc/filebeat/policies/my-default-filebeat.json. Cette politique sera utilisée comme politique par défaut pour ce beat.

License

Apache 2.0

Limitations

Plusieurs instances du même beat ne peuvent pas être installées sur le même serveur cible.

Questions sur l'utilisation

Nous accueillons les questions sur l'utilisation du rôle. Cependant, afin de garder la liste des problèmes sur GitHub axée sur les "problèmes", nous demandons à la communauté de poser des questions sur https://discuss.elastic.co/c/beats. Cela est surveillé par les mainteneurs.

Les contributions de la communauté sont toujours appréciées et les bienvenues ! Veuillez vous assurer que toutes les contributions incluent des tests si nécessaire.