OndrejHome.ha-cluster-pacemaker

Aperçu Versions Perspectives

ha-cluster-pacemaker

Rôle pour configurer et étendre un cluster pacemaker de base sur les systèmes CentOS/RHEL 6/7/8/9, AlmaLinux 8/9, Rocky Linux 8/9, Fedora 31/32/33/34/35/36/37/38/39/40 et CentOS 8/9 Stream.

Ce rôle peut configurer les aspects suivants du cluster pacemaker :

  • activer les dépôts système nécessaires
  • installer les paquets requis
  • créer et configurer des utilisateurs et des groupes pour faire tourner le cluster pacemaker
  • configurer le pare-feu
  • générer des éléments dans /etc/hosts
  • autoriser les nœuds du cluster
  • créer ou étendre le cluster (vérifiez allow_cluster_expansion)
    • cluster de "2 ou plusieurs" nœuds
    • cœur unique, rrp ou knet avec jusqu'à 8 liens
    • nœuds distants
    • utiliser des interfaces/IPs routinisées automatiquement ou choisies sur mesure pour le cœur
  • démarrer et activer le cluster au démarrage
  • configurer les dispositifs stonith
    • par défaut, installer et configurer les dispositifs stonith fence_xvm
    • optionnellement configurer fence_kdump
    • optionnellement configurer fence_vmware (SOAP/REST) ou tout autre dispositif stonith fence_*
    • optionnellement configurer fence_aws

Ce rôle prend entièrement en charge le mode --check pour la configuration par défaut et le prend partiellement en charge pour la plupart des autres options.

Lors du signalement d'un problème, veuillez fournir les informations suivantes (si possible) :

  • version d'ansible utilisée
  • système d'exploitation depuis lequel ansible a été exécuté
  • playbook et fichier d'inventaire ayant produit l'erreur (supprimer les informations sensibles si nécessaire)
  • message d'erreur ou description du dysfonctionnement rencontré

Exigences

Ce rôle dépend du rôle ondrejhome.pcs-modules-2.

Ansible 2.8 ou version ultérieure. (REMARQUE : il peut être possible d'utiliser des versions antérieures, en cas de problèmes, essayez de mettre à jour Ansible à la version 2.8 ou supérieure)

RHEL 6/7/8 : On s'attend à ce que les machines soient déjà enregistrées. Par défaut, le rôle activera l'accès au canal 'High Availability' ou 'Resilient storage'. Si cela n'est pas souhaité, vérifiez la variable enable_repos.

RHEL/CentOS 7 : Ce rôle nécessite au moins la version 2.9 de la bibliothèque python-jinja2. Si elle n'est pas présente, vous pouvez rencontrer une erreur décrite dans l'Issue #6. Pour obtenir la version mise à jour de python-jinja2 et ses dépendances, vous pouvez utiliser le dépôt RPM suivant - https://copr.fedorainfracloud.org/coprs/ondrejhome/ansible-deps-el7/ pour CentOS 7 et RHEL 7.

CentOS 8 Stream Testé avec la version 20240129, la version d'ansible recommandée est 2.11.0, qui commence à identifier le système comme 'CentOS' au lieu de 'RedHat' (contrairement à CentOS Linux). Les anciennes versions de CentOS 8 Stream 20201211 ont une version d'ansible minimale utilisable de 2.9.16/2.10.4. La version 2.8.18 ne fonctionnait pas au moment des tests. Cela est lié à Service is in unknown state #71528.

CentOS 9 Stream Testé avec la version 20240129, la version minimale d'ansible recommandée est 2.11.0.

Debian Buster Testé avec la version 20210310 avec la version d'ansible 2.10 et Debian Bullseye Testé avec la version 20220326 avec la version d'ansible 2.12. La partie Debian de ce rôle ne comprend pas la configuration de stonith ni la configuration du pare-feu. Remarque : Ce rôle a été testé de manière limitée sur Debian - toutes les fonctionnalités de ce rôle n'ont pas été testées.

Debian Bookworm Testé avec la version d'ansible 2.14 et Debian Bookworm. La partie Debian de ce rôle ne comprend pas la configuration de stonith ni la configuration du pare-feu. Remarque : Ce rôle a été testé de manière limitée sur Debian - toutes les fonctionnalités de ce rôle n'ont pas été testées.

Les versions d'ansible 2.9.10 et 2.9.11 échoueront avec l'erreur "'hostvars' is undefined" lors de la tentative de configuration des nœuds distants. Cela ne s'applique que lorsqu'il y a au moins un nœud avec cluster_node_is_remote=True. Évitez ces versions d'ansible si vous prévoyez de configurer des nœuds distants avec ce rôle.

Sur CentOS Linux 8, vous devez vous assurer que les dépôts BaseOS et Appstream fonctionnent correctement. Étant donné que CentOS Linux 8 est en phase de fin de vie, ce rôle configurera le dépôt HA pour pointer vers vault.centos.org si la configuration du dépôt (enable_repos : true) est demandée (c'est par défaut).

Les distributions de version pcs-0.11 (AlmaLinux 9, Rocky Linux 9, RHEL 9, Fedora 36/37/38) ne sont prises en charge qu'avec ondrejhome.pcs-modules-2 version 27.0.0 ou ultérieure.

Variables de rôle

  • utilisateur utilisé pour autoriser les nœuds du cluster

    cluster_user: 'hacluster'

  • mot de passe pour l'utilisateur utilisé pour autoriser les nœuds du cluster

    cluster_user_pass: 'testtest'

  • groupe auquel appartient l'utilisateur du cluster (devrait être 'haclient')

    cluster_group: 'haclient'

  • nom du cluster

    cluster_name: 'pacemaker'

  • configuration du pare-feu pour le clustering, REMARQUE dans RHEL/Centos 6, cela remplace le fichier de configuration iptables !

    cluster_firewall: true

  • activer le cluster au démarrage sur les nœuds normaux (pas pacemaker_remote)

    cluster_enable_service: true

  • configurer le cluster avec le dispositif de fencing fence_xvm ? Cela copiera /etc/cluster/fence_xvm.key vers les nœuds et ajoutera des dispositifs de fencing au cluster. REMARQUE : vous devez définir 'vm_name' dans l'inventaire pour chaque nœud du cluster.

    cluster_configure_fence_xvm: true

  • configurer le cluster avec le dispositif de fencing fence_vmware_soap/fence_vmware_rest ? Cela installera le dispositif de fencing fence_vmware_soap/fence_vmware_rest et le configurera. Lorsque cela est activé, vous devez spécifier 3 variables supplémentaires avec des informations sur l'accès au vCenter. REMARQUE : Vous devez également définir 'vm_name' dans l'inventaire pour chaque nœud du cluster en spécifiant le nom ou l'UUID de la VM tel qu'il apparaît sur l'hyperviseur ou dans la sortie de la commande fence_vmware_soap -o list/fence_vmware_rest command.

    cluster_configure_fence_vmware_soap: false
cluster_configure_fence_vmware_rest: false
fence_vmware_ipaddr: ''
fence_vmware_login: ''
fence_vmware_passwd: ''

    Vous pouvez éventuellement modifier les attributs supplémentaires passés à fence_vmware_soap/fence_vmware_rest en utilisant la variable fence_vmware_options. Par défaut, cette variable active le chiffrement mais désactive la validation des certificats.

    fence_vmware_options: 'ssl="1" ssl_insecure="1"'

    REMARQUE : Un seul des dispositifs fence_vmware_soap/fence_vmware_rest peut être configuré car les dispositifs stonith partagent le même nom.

  • configurer le cluster avec le dispositif de fencing fence_kdump ? Cela active le service kdump et définit les dispositifs stonith fence_kdump. REMARQUE : si le service kdump n'est pas démarré, cela ne fonctionnera pas correctement ou pas du tout.

    cluster_configure_fence_kdump: false

  • configurer le cluster avec le dispositif de fencing fence_aws ? Vous devez fournir l'ID de l'instance/région AWS et le profil d'instance capable de démarrer/arrêter des instances pour ce cluster. Lorsque cela est activé, vous devez spécifier la variable fence_aws_region avec des informations sur la région AWS. REMARQUE : Si vous ne configurez pas de profil d'instance, cela ne fonctionnera pas correctement ou pas du tout.

    cluster_configure_fence_aws: false
fence_aws_region: ''

    REMARQUE : Vous devez également définir instance_id dans l'inventaire pour chaque nœud du cluster en spécifiant l'ID de l'instance tel qu'il apparaît dans la console web AWS ou dans la sortie de la commande fence_aws -o list. (man fence_aws)

    Vous pouvez éventuellement modifier les attributs supplémentaires passés à fence_aws en utilisant la variable fence_aws_options.

    fence_aws_options: ''

    REMARQUE : Des exemples d'options appropriées pour certains cas d'utilisation spécifiques peuvent être trouvés dans les documents ci-dessous.
    https://access.redhat.com/articles/4175371#create-stonith
    https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-cluster-resources-1.html

  • Comment mapper les dispositifs de fencing aux nœuds du cluster ? Par défaut, pour chaque nœud du cluster, un dispositif stonith séparé est créé ('un-dispositif-par-nœud'). Certains agents de fencing peuvent cadenasser plusieurs nœuds utilisant le même dispositif stonith ('un-dispositif-par-cluster') et peuvent avoir des problèmes lors de l'utilisation de plusieurs dispositifs en raison des limites de nombre de connexions d'utilisateur identiques. Options disponibles :

    • one-device-per-node - (par défaut) - un dispositif stonith par nœud de cluster est créé
    • one-device-per-cluster - (sur les agents de fencing pris en charge) - un seul dispositif stonith à l'échelle du cluster est créé pour tous les nœuds, agents de fencing pris en charge : fence_vmware_rest, fence_vmware_soap, fence_xvm, fence_kdump
    cluster_configure_stonith_style: 'one-device-per-node'

  • (RHEL/CentOS/AlmaLinux/Rocky) activer les dépôts contenant les paquets nécessaires

    enable_repos: true

  • (RHEL uniquement) activer les dépôts de mise à jour étendue (EUS) contenant les paquets nécessaires

    enable_eus_repos: false

  • (RHEL uniquement) activer les dépôts de service de mise à jour des solutions SAP (E4S) contenant les paquets nécessaires

    enable_e4s_repos: false

  • (RHEL uniquement) activer les dépôts Beta contenant les paquets nécessaires

    enable_beta_repos: false

  • (RHEL uniquement) type de dépôt à activer, notez que les dépôts E4S n'ont que le type 'ha' disponible

    • ha - Haute Disponibilité
    • rs - Stockage Résilient
    repos_type: 'ha'

  • (RHEL uniquement) custom_repository permet d'activer un dépôt nommé arbitrairement. Les noms de dépôt RHEL8 peuvent être trouvés à l'adresse http://downloads.redhat.com/redhat/rhel/rhel-8-beta/rhel-8-beta.repo

    custom_repository: ''

  • (CentOS uniquement) installer les paquets nécessaires depuis le support CD-ROM disponible à /dev/cdrom

    use_local_media: false

  • Activer ou désactiver l'interface Web PCSD. Par défaut, le rôle garde la configuration par défaut, ce qui signifie que l'interface Web PCSD est désactivée sur CentOS/RHEL 6.X et activée sur CentOS/RHEL 7.X. true ou false peuvent être passés à cette variable pour s'assurer que l'interface Web PCSD est activée ou désactivée.

    enable_pcsd_gui: 'nochange'

  • Protocole de transport du cluster. Par défaut, ce rôle utilisera ce qui est par défaut pour le système d'exploitation donné. Pour CentOS/RHEL 6.X, cela signifie 'udp' (multicast UDP) et pour CentOS/RHEL 7.X, cela signifie 'udpu' (unicast UDP). Cette variable accepte les options suivantes : default, udp et udpu.

    cluster_transport: 'default'

  • Autoriser l'ajout de nœuds à un cluster existant lors de son utilisation avec ondrejhome.pcs-modules-2 version 16 ou plus récente.

    allow_cluster_expansion: false

  • Interface réseau du cluster. Si spécifiée, le rôle mappe les hôtes à l'adresse IPv4 principale de cette interface. Par défaut, l'adresse IPv4 à partir de ansible_default_ipv4 ou la première IPv4 à partir de ansible_all_ipv4_addresses est utilisée. Par exemple, pour utiliser l'adresse IPv4 principale de l'interface ens8, utilisez cluster_net_iface: 'ens8'. L'interface doit exister sur tous les nœuds du cluster.

    cluster_net_iface: ''

  • Interface réseau redondante. Si spécifiée, le rôle mettra en place un anneau redondant corosync utilisant l'adresse IPv4 par défaut de cette interface. L'interface doit exister sur tous les nœuds du cluster.

      rrp_interface: ''

    REMARQUE : Vous pouvez définir cette variable soit dans defaults/main.yml, dans ce cas, le même nom d'rrp_interface sera utilisé pour tous les hôtes dans le fichier hosts. Soit vous spécifiez une interface pour chaque hôte présent dans le fichier hosts : cela permet d'utiliser un nom d'interface spécifique pour chaque hôte (dans le cas où ils n'ont pas le même nom d'interface). Notez également qu'au lieu de définir rrp_interface pour un hôte, vous pouvez définir rrp_ip : dans ce cas, cette adresse IP alternative est utilisée pour configurer le RRP corosync (cette IP doit être différente de l'adresse IPv4 par défaut de l'hôte). Cela permet d'utiliser une IP alternative appartenant à la même interface principale.

  • Que faire pour ajouter des hôtes au fichier /etc/hosts. Par défaut, une entrée pour le nom d'hôte donné par cluster_hostname_fact est ajoutée pour chaque hôte dans /etc/hosts. Cela peut être désactivé en définissant cluster_etc_hosts sur false.

    cluster_etc_hosts: true

  • Quel fait ansible utiliser comme nom d'hôte des nœuds du cluster. Par défaut, ce rôle utilise le fait ansible_hostname comme nom d'hôte pour chaque hôte. Dans certains environnements, il peut être utile d'utiliser le nom de domaine complet (FQDN) ansible_fqdn ou le nom de nœud ansible_nodename.

    cluster_hostname_fact: "ansible_hostname"

  • Si le nœud doit être configuré comme un nœud pacemaker distant. Par défaut c'est false, et le nœud sera un membre à part entière du cluster Pacemaker. Les nœuds distants ne sont pas des membres à part entière du cluster et permettent de dépasser la taille maximale du cluster de 32 membres à part entière. Notez que les nœuds distants sont uniquement pris en charge par ce rôle sur EL7 et EL8.

    cluster_node_is_remote: false

  • Liste ordonnée de variables pour détecter l'IP principale du cluster (ring0). La première IPv4 trouvée est utilisée et le reste des IPv4 détectées est ignoré. Dans la plupart des cas, cela ne nécessite pas de changement. Dans certains cas spéciaux, tels que l'absence de porte d'accès par défaut ou si une IPv4 non principale de l'interface donnée doit être utilisée, cela peut être ajusté.

    ring0_ip_ordered_detection_list:
  - "{{ hostvars[inventory_hostname]['ansible_'+cluster_net_iface].ipv4.address|default('') }}"
  - "{{ ansible_default_ipv4.address|default('') }}"
  - "{{ ansible_all_ipv4_addresses[0]|default('') }}"

  • Configurer les propriétés du cluster (non obligatoire)

    cluster_property:
  - name: required
    node: optional
    value: optional

  • Configurer les valeurs par défaut des ressources du cluster (non obligatoire)

    cluster_resource_defaults:
  - name: required
    defaults_type: optional
    value: optional

  • Configurer les ressources du cluster (non obligatoire)

    cluster_resource:
  - name: required
    resource_class: optional
    resource_type: optional
    options: optional
    force_resource_update: optional
    ignored_meta_attributes: optional
    child_name: optional

  • Configurer les contraintes d'ordre du cluster (non obligatoire)

    cluster_constraint_order:
  - resource1: required
    resource1_action: optional
    resource2: required
    resource2_action: optional
    kind: optional
    symmetrical: optional

  • Configurer les contraintes de colocalisation du cluster (non obligatoire)

    cluster_constraint_colocation:
  - resource1: required
    resource1_role: optional
    resource2: required
    resource2_role: optional
    score: optional
    influence: optional

  • Configurer les contraintes de localisation du cluster (non obligatoire)

    basé sur le nœud

    cluster_constraint_location:
  - resource: required
    node_name: required
    score: optional

    basé sur la règle (nécessite ondrejhome.pcs-modules-2 version 30.0.0 ou plus récente)

    cluster_constraint_location:
  - resource: required
    constraint_id: required
    rule: required
    score: optional

Considérations de sécurité

Veuillez envisager de mettre à jour la valeur par défaut de cluster_user_pass.

Pour protéger les valeurs sensibles dans les variables passées à ce rôle, vous pouvez utiliser ansible-vault pour les chiffrer. L'approche recommandée consiste à créer un fichier séparé avec les variables souhaitées et leurs valeurs, à chiffrer l'ensemble du fichier avec ansible-vault encrypt puis à inclure ce fichier dans la section pre_tasks: afin qu'il soit chargé avant l'exécution du rôle. L'exemple ci-dessous illustre tout ce processus.

Créer un fichier encrypted_vars.yaml

    1. Créez un fichier de texte en clair encrypted_vars.yaml avec vos valeurs secrètes souhaitées.
    # cat encrypted_vars.yaml
---
cluster_user_pass: 'cluster-user-pass'
fence_vmware_login: 'vcenter-user'
fence_vmware_passwd: 'vcenter-pass'
    1. Chiffrez le fichier avec ansible-vault.
    # ansible-vault encrypt encrypted_vars.yaml
    1. Vérifiez le nouveau contenu de encrypted_vars.yaml.
    # cat encrypted_vars.yaml
$ANSIBLE_VAULT;1.1;AES256
31306461386430...

Exemple de playbook utilisant des valeurs de encrypted_vars.yaml:

- hosts: cluster
   pre_tasks:
     - include_vars: encrypted_vars.yaml
   roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

REMARQUE: Chiffrer uniquement la valeur de la variable et la placer dans vars: est déconseillé, car cela pourrait entraîner des erreurs telles que argument 1 must be str, not AnsibleVaultEncryptedUnicode. L'approche qui chiffre l'ensemble du fichier semble ne pas être affectée par ce problème.

Defaults des modules Ansible

Bien que ce rôle n'expose pas toutes les options de configuration via des variables, on peut utiliser les module_defaults pour modifier les valeurs par défaut des paramètres que ce rôle n'utilise pas. Voici une liste non exhaustive d'exemples où cela peut être utile.

Exemple module_default A pour définir le temps de jeton de totem à 15 secondes.

- hosts: cluster
  modules_defaults:
    pcs_cluster:
      token: 15000               # par défaut c'est 'null' - dépend de la valeur par défaut du système d'exploitation

Exemple module_default B pour désactiver l'installation des dépendances faibles sur les systèmes EL8+/Fedora.

- hosts: cluster
  modules_defaults:
    yum:
      install_weak_deps: false   # par défaut c'est 'true'

Exemple module_default C pour désactiver l'installation des recommandations de paquets sur les systèmes Debian.

- hosts: cluster
  modules_defaults:
    apt:
      install_recommends: false  # par défaut c'est 'null' - dépend de la configuration du système

REMARQUE : Les module_defaults ne s'appliquent qu'aux options qui ne sont pas spécifiées dans la tâche - vous ne pouvez pas remplacer une valeur définie par une tâche dans ce rôle, seules les valeurs d'options non utilisées peuvent être changées.

Exemple de Playbook

Exemple de playbook A pour créer un cluster nommé 'test-cluster' activé au démarrage, avec fence_xvm et les paramètres du pare-feu. REMARQUE : cluster_name est optionnel et par défaut c'est pacemaker.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

Exemple de playbook B pour créer un cluster nommé 'test-cluster' sans configurer le pare-feu et sans fence_xvm. Pour que le cluster soit correctement autorisé, on s'attend à ce que le pare-feu soit déjà configuré ou désactivé.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_firewall: false, cluster_configure_fence_xvm: false }

Exemple de playbook C pour créer un cluster nommé vmware-cluster avec le dispositif de fencing fence_vmware_soap.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-or-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_soap: true }

Exemple de playbook D pour créer un cluster nommé test-cluster où /etc/hosts n'est pas modifié :

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_etc_hosts: false }

Exemple de playbook E pour créer un cluster nommé vmware-cluster avec un dispositif de fencing fence_vmware_rest unique pour tous les nœuds du cluster.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-or-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_rest: true, cluster_configure_stonith_style: 'one-device-per-cluster' }

Exemple de playbook pour la configuration des ressources.

- hosts: cluster
  vars:
    cluster_property:
      - name: 'maintenance-mode'
        value: 'true'
    cluster_resource:
      - name: 'apache2'
        resource_type: 'systemd:apache2'
        options: 'meta migration-threshold=2 op monitor interval=20s timeout=10s'
      - name: 'cluster_vip'
        resource_type: 'ocf:heartbeat:IPaddr2'
        options: 'ip=192.168.1.150 cidr_netmask=24 meta migration-threshold=2 op monitor interval=20'
    cluster_constraint_colocation:
      - resource1: 'cluster_vip'
        resource2: 'apache2'
        score: 'INFINITY'
    cluster_resource_defaults:
      - name: 'failure-timeout'
        value: '30'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'apache-cluster'}

Exemple de fichier d'inventaire pour les systèmes CentOS/RHEL/Fedora créant des clusters de base.

[cluster-centos7]
192.168.22.21 vm_name=fastvm-centos-7.8-21
192.168.22.22 vm_name=fastvm-centos-7.8-22
[cluster-fedora32]
192.168.22.23 vm_name=fastvm-fedora32-23
192.168.22.24 vm_name=fastvm-fedora32-24
[cluster-rhel8]
192.168.22.25 vm_name=fastvm-rhel-8.0-25
192.168.22.26 vm_name=fastvm-rhel-8.0-26

Exemple de fichier d'inventaire pour un cluster utilisant RRP interconnecté sur une interface personnalisée et/ou en utilisant une IP personnalisée pour RRP.

[cluster-centos7-rrp]
192.168.22.27 vm_name=fastvm-centos-7.6-21 rrp_interface=ens6
192.168.22.28 vm_name=fastvm-centos-7.6-22 rrp_ip=192.168.22.29

Exemple de fichier d'inventaire avec deux membres à part entière et deux nœuds distants :

[cluster]
192.168.22.21 vm_name=fastvm-centos-7.6-21
192.168.22.22 vm_name=fastvm-centos-7.6-22
192.168.22.23 vm_name=fastvm-centos-7.6-23 cluster_node_is_remote=True
192.168.22.24 vm_name=fastvm-centos-7.6-24 cluster_node_is_remote=True

Exemple de fichier d'inventaire avec fence_aws :

[cluster]
172.31.0.1	instance_id="i-acbdefg1234567890"
172.31.0.2	instance_id="i-acbdefg0987654321"

Anciens exemples vidéo de fonctionnement du rôle avec les paramètres par défaut pour :

Licence

GPLv3

Informations sur l'auteur

Pour contacter l'auteur, vous pouvez utiliser l'email ondrej-xa2iel8u@famera.cz ou créer une issue sur github pour demander une fonctionnalité.

À propos du projet

pacemaker basic cluster role with fencing configuration (xvm, kdump, custom)

role clustering pacemaker
Installer
ansible-galaxy install OndrejHome.ha-cluster-pacemaker
GitHub référentiel
44 étoiles
29 forks
0 problèmes ouverts
Licence
gpl-3.0
Téléchargements
2.5k
Propriétaire