lae.proxmox

Installe et configure l'environnement virtuel Proxmox 6.x/7.x/8.x sur des serveurs Debian.

Ce rôle vous permet de déployer et de gérer des installations PVE en nœud unique ainsi que des clusters PVE (3 nœuds ou plus) sur Debian Buster (10) et Bullseye (11). Avec l'aide de ce rôle, vous pouvez configurer :

• Définitions RBAC PVE (rôles, groupes, utilisateurs et listes de contrôle d'accès)
• Définitions de stockage PVE
• datacenter.cfg
• Certificats HTTPS pour l'interface Web de Proxmox (apportez votre propre)
• Sélection de dépôt PVE (par exemple pve-no-subscription ou pve-enterprise)
• Modules de surveillance (IPMI et NMI) avec la configuration applicable de pve-ha-manager
• Configuration du module ZFS et e-mail de notification ZED

Avec le clustering activé, ce rôle fait (ou vous permet de faire) les actions suivantes :

• S'assurer que tous les hôtes peuvent se connecter les uns aux autres en tant que root via SSH
• Initialiser un nouveau cluster PVE (ou éventuellement adopter un cluster existant)
• Créer ou ajouter de nouveaux nœuds à un cluster PVE
• Installer Ceph sur un cluster PVE
• Créer et gérer des groupes de haute disponibilité

Support/Contributions

Pour le support ou si vous souhaitez contribuer à ce rôle mais avez besoin de conseils, n'hésitez pas à rejoindre ce serveur Discord : https://discord.gg/cjqr6Fg. Veuillez noter qu'il s'agit d'une invitation temporaire, donc vous devrez attendre que @lae vous attribue un rôle, sinon Discord vous retirera du serveur lors de votre déconnexion.

Démarrage rapide

L'objectif principal de ce rôle est de configurer et gérer un cluster Proxmox VE (voir exemple de playbook), cependant, ce rôle peut être utilisé pour installer rapidement des serveurs Proxmox sur un nœud unique.

Je suppose que vous avez déjà Ansible installé. Vous devrez utiliser une machine externe à celle sur laquelle vous installez Proxmox (principalement en raison du redémarrage au milieu de l'installation, bien que je puisse traiter cela différemment pour ce cas d'utilisation plus tard).

Copiez le playbook suivant dans un fichier comme install_proxmox.yml :

    - hosts: all
      become: True
      roles:
        - role: geerlingguy.ntp
          vars:
            ntp_manage_config: true
            ntp_servers:
              - clock.sjc.he.net,
              - clock.fmt.he.net,
              - clock.nyc.he.net
        - role: lae.proxmox
          vars:
            - pve_group: all
            - pve_reboot_on_kernel_update: true

Installez ce rôle et un rôle pour configurer NTP :

    ansible-galaxy install lae.proxmox geerlingguy.ntp

Vous pouvez maintenant procéder à l'installation :

    ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER

Si votre SSH_USER a un mot de passe sudo, passez le drapeau -K à la commande ci-dessus. Si vous vous authentifiez également auprès de l'hôte par mot de passe au lieu de par clé publique, passez le drapeau -k (assurez-vous d'avoir sshpass installé également). Vous pouvez définir ces variables avant d'exécuter la commande ou simplement les remplacer. Veuillez noter que la virgule est importante, car une liste est attendue (sinon, il tentera de rechercher un fichier contenant une liste d'hôtes).

Une fois terminé, vous devriez pouvoir accéder à votre instance Proxmox VE à https://$SSH_HOST_FQDN:8006.

Déploiement d'un cluster PVE 8.x entièrement fonctionnel

Créez un nouveau répertoire de playbook. Nous l'appelons lab-cluster. Notre playbook ressemblera à ceci, mais le vôtre ne doit pas nécessairement suivre toutes les étapes :

lab-cluster/
├── files
│   └── pve01
│       ├── lab-node01.local.key
│       ├── lab-node01.local.pem
│       ├── lab-node02.local.key
│       ├── lab-node02.local.pem
│       ├── lab-node03.local.key
│       └── lab-node03.local.pem
├── group_vars
│   ├── all
│   └── pve01
├── inventory
├── roles
│   └── requirements.yml
├── site.yml
└── templates
    └── interfaces-pve01.j2

La première chose que vous pouvez noter est que nous avons un certain nombre de fichiers .key et .pem. Ce sont des clés privées et des certificats SSL que ce rôle utilisera pour configurer l'interface Web de Proxmox sur tous les nœuds. Ceux-ci ne sont pas nécessaires, cependant, si vous souhaitez continuer à utiliser les certificats signés par l'autorité de certification (CA) que Proxmox configure en interne. Vous pouvez généralement utiliser Ansible Vault pour chiffrer les clés privées, par exemple :

    ansible-vault encrypt files/pve01/*.key

Cela nécessiterait alors de passer le mot de passe Vault lors de l'exécution du playbook.

D'abord, spécifions nos hôtes de cluster. Notre fichier inventory peut ressembler à ceci :

[pve01]
lab-node01.local
lab-node02.local
lab-node03.local

Vous pourriez avoir plusieurs clusters, donc il est conseillé d'avoir un groupe pour chaque cluster. Maintenant, spécifions nos exigences de rôle dans roles/requirements.yml :

---
- src: geerlingguy.ntp
- src: lae.proxmox

Nous avons besoin d'un rôle NTP pour configurer NTP, donc nous utilisons le rôle de Jeff Geerling pour ce faire. Vous n'en auriez pas besoin si vous avez déjà NTP configuré ou si vous avez une autre méthode pour configurer NTP.

Maintenant, définissons quelques variables de groupe. Tout d'abord, créons group_vars/all pour configurer les variables liées à NTP :

---
ntp_manage_config: true
ntp_servers:
  - lab-ntp01.local iburst
  - lab-ntp02.local iburst

Bien sûr, remplacez ces serveurs NTP par ceux de votre choix.

Passons maintenant au cœur de votre playbook, les variables de groupe de pve01. Créez un fichier group_vars/pve01, ajoutez ce qui suit, et modifiez-le en fonction de votre environnement.

---
pve_group: pve01
pve_watchdog: ipmi
pve_ssl_private_key: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.key') }}"
pve_ssl_certificate: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.pem') }}"
pve_cluster_enabled: yes
pve_groups:
  - name: ops
    comment: Équipe des opérations
pve_users:
  - name: admin1@pam
    email: [email protected]
    firstname: Admin
    lastname: Utilisateur 1
    groups: [ "ops" ]
  - name: admin2@pam
    email: [email protected]
    firstname: Admin
    lastname: Utilisateur 2
    groups: [ "ops" ]
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "ops" ]
pve_storages:
  - name: localdir
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /plop
    maxfiles: 4
pve_ssh_port: 22

interfaces_template: "interfaces-{{ pve_group }}.j2"

pve_group est défini sur le nom du groupe de notre cluster, pve01 - il sera utilisé pour s'assurer que tous les hôtes de ce groupe peuvent se connecter les uns aux autres et sont regroupés ensemble. Notez que le nom du cluster PVE sera également défini sur ce nom de groupe, sauf indication contraire par pve_cluster_clustername. Laisser cette valeur non définie reviendra à utiliser proxmox par défaut.

pve_watchdog ici active le support du watchdog IPMI et configure le gestionnaire HA de PVE pour l'utiliser. Laissez ceci non défini si vous ne souhaitez pas le configurer.

pve_ssl_private_key et pve_ssl_certificate pointent vers les certificats SSL pour le cluster PVE. Ici, une recherche de fichier est utilisée pour lire le contenu d'un fichier dans le playbook, par exemple files/pve01/lab-node01.key. Vous pourriez possiblement utiliser des variables d'hôte au lieu de fichiers, si vous préférez.

pve_cluster_enabled active le rôle pour effectuer toutes les tâches de gestion de cluster. Cela inclut la création d'un cluster s'il n'existe pas, ou l'ajout de nœuds au cluster existant. Des vérifications sont effectuées pour s'assurer que vous ne mélangez pas des nœuds qui se trouvent déjà dans des clusters existants avec des noms différents.

pve_groups, pve_users, et pve_acls autorisent certains utilisateurs UNIX locaux (ils doivent déjà exister) à accéder à PVE et leur attribuent le rôle d'administrateur dans le cadre du groupe ops. Consultez la section Gestion des utilisateurs et ACL pour plus d'informations.

pve_storages permet de créer différents types de stockage et de les configurer. Le backend doit être pris en charge par Proxmox. Lire la section Gestion du stockage pour plus d'informations.

pve_ssh_port vous permet de changer le port SSH. Si votre SSH écoute sur un port autre que le port par défaut 22, veuillez définir cette variable. Si un nouveau nœud rejoint le cluster, le cluster PVE doit communiquer une fois via SSH.

pve_manage_ssh (vrai par défaut) vous permet de désactiver toutes les modifications que ce module apporterait à votre configuration de serveur SSH. Cela est utile si vous utilisez un autre rôle pour gérer votre serveur SSH. Notez que définir cela sur faux n'est pas officiellement pris en charge, vous devrez répliquer vous-même les changements normalement effectués dans ssh_cluster_config.yml et pve_add_node.yml.

interfaces_template est défini sur le chemin d'un modèle que nous utiliserons pour configurer le réseau sur ces machines Debian. Cela n'est nécessaire que si vous souhaitez gérer la mise en réseau via Ansible plutôt que manuellement ou via chaque hôte dans PVE. Vous devriez probablement être familiarisé avec Ansible avant de le faire, car votre méthode peut impliquer de définir des variables d'hôte pour les adresses IP de chaque hôte, etc.

Gérons ce modèle d'interface. N'hésitez pas à ignorer ce fichier (et le laisser non défini dans group_vars/pve01). Voici un exemple que j'utilise :

# {{ ansible_managed }}
auto lo
iface lo inet loopback

allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet static
    address {{ lookup('dig', ansible_fqdn) }}
    gateway 10.4.0.1
    netmask 255.255.255.0
    bridge_ports enp2s0f0
    bridge_stp off
    bridge_fd 0

allow-hotplug enp2s0f1
auto enp2s0f1
iface enp2s0f1 inet static
    address {{ lookup('dig', ansible_hostname + "-clusternet.local") }}
    netmask 255.255.255.0

Vous n'êtes peut-être pas familier avec la recherche dig, mais ici nous faisons essentiellement une recherche d'enregistrement A pour chaque machine (par exemple, lab-node01.local) pour la première interface (et la configurons en tant que pont que nous utiliserons pour les interfaces VM), puis une autre recherche légèrement modifiée pour le réseau “clustering” que nous pourrions utiliser pour Ceph ("lab-node01-clusternet.local"). Bien sûr, le vôtre peut avoir un aspect complètement différent, surtout si vous utilisez du bonding, trois réseaux différents pour la gestion/corosync, le stockage et le trafic VM, etc.

Enfin, écrivons notre playbook. site.yml ressemblera à quelque chose comme ceci :

---
- hosts: all
  become: True
  roles:
    - geerlingguy.ntp

# À laisser de côté si vous ne modifiez pas la mise en réseau via Ansible
- hosts: pve01
  become: True
  serial: 1
  tasks:
    - name: Installer bridge-utils
      apt:
        name: bridge-utils

    - name: Configurer /etc/network/interfaces
      template:
        src: "{{ interfaces_template }}"
        dest: /etc/network/interfaces
      register: _configure_interfaces

    - block:
      - name: Redémarrer pour appliquer les changements de réseau
        shell: "sleep 5 && shutdown -r now 'Changements de réseau détectés, redémarrage en cours'"
        async: 1
        poll: 0

      - name: Attendre que le serveur revienne en ligne
        wait_for_connection:
          delay: 15
      when: _configure_interfaces is changed

- hosts: pve01
  become: True
  roles:
    - lae.proxmox

En gros, nous exécutons le rôle NTP sur tous les hôtes (vous voudrez peut-être ajouter quelques machines non-Proxmox), configurons le réseau sur pve01 avec notre réseau de cluster séparé et notre configuration de pont, redémarrons pour que ces changements prennent effet, et ensuite exécutons ce rôle Proxmox contre les hôtes pour configurer un cluster.

À ce stade, notre playbook est prêt et nous pouvons l'exécuter.

Assurez-vous que les rôles et dépendances sont installés :

    ansible-galaxy install -r roles/requirements.yml --force
    pip install jmespath dnspython

jmespath est requis pour certaines tâches impliquant le clustering. dnspython n'est requis que si vous utilisez une recherche dig, ce que vous ne ferez probablement pas si vous avez omis la configuration de mise en réseau. Nous passons --force à ansible-galaxy ici pour que les rôles soient mis à jour vers leurs dernières versions s'ils sont déjà installés.

Maintenant, exécutez le playbook :

    ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'

Le -e '{"pve_reboot_on_kernel_update": true}' doit principalement être exécuté la première fois que vous configurez le cluster Proxmox, car cela redémarrera le serveur pour démarrer avec un kernel PVE. Les exécutions suivantes devraient laisser cela de côté, car vous souhaitez redémarrer séquentiellement les serveurs une fois le cluster en cours d'exécution.

Pour spécifier un utilisateur particulier, utilisez -u root (en remplaçant root), et si vous devez fournir des mots de passe, utilisez -k pour le mot de passe SSH et/ou -K pour le mot de passe sudo. Par exemple :

    ansible-playbook -i inventory site.yml -K -u admin1

Cela demandera un mot de passe sudo, puis se connectera à l'utilisateur admin1 (en utilisant l'authentification par clé publique - ajoutez -k pour le mot de passe) et exécutera le playbook.

C'est tout ! Vous devriez maintenant avoir un cluster Proxmox entièrement déployé. Vous voudrez peut-être créer un stockage Ceph par la suite (voir Ceph pour plus d'informations) et d'autres tâches éventuellement, mais la partie difficile est principalement terminée.

Exemple de Playbook

Ceci configurera les hôtes dans le groupe pve01 comme un cluster, ainsi que redémarrera les machines si le kernel a été mis à jour. (Il est seulement recommandé de définir ce drapeau pendant l'installation - les redémarrages pendant l'exploitation devraient se faire séquentiellement pendant une période de maintenance.) Il activera également le watchdog IPMI.

    - hosts: pve01
      become: True
      roles:
        - role: geerlingguy.ntp
            ntp_manage_config: true
            ntp_servers:
              - clock.sjc.he.net,
              - clock.fmt.he.net,
              - clock.nyc.he.net
        - role: lae.proxmox
            pve_group: pve01
            pve_cluster_enabled: yes
            pve_reboot_on_kernel_update: true
            pve_watchdog: ipmi

Variables de rôle

[variable]: [par défaut] #[description / but]
pve_group: proxmox # groupe d'hôtes contenant les hôtes Proxmox à regrouper
pve_repository_line: "deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription" # configuration du dépôt apt - changer pour enterprise si nécessaire (bien que TODO d'autres configurations peuvent être nécessaires)
pve_remove_subscription_warning: true # corrige les messages d'avertissement de souscription dans proxmox si vous utilisez l'édition communautaire
pve_extra_packages: [] # Tous les packages supplémentaires que vous pourriez vouloir installer, par exemple ngrep
pve_run_system_upgrades: false # Autoriser le rôle à effectuer des mises à jour système
pve_run_proxmox_upgrades: true # Autoriser le rôle à effectuer des mises à jour de Proxmox VE
pve_check_for_kernel_update: true # Exécute un script sur l'hôte pour vérifier les versions du kernel
pve_reboot_on_kernel_update: false # Si défini sur vrai, redémarrera automatiquement la machine lors des mises à jour du kernel
pve_reboot_on_kernel_update_delay: 60 # Nombre de secondes à attendre avant et après un processus de redémarrage pour passer à la tâche suivante en mode cluster
pve_remove_old_kernels: true # Supprime actuellement le kernel du dépôt principal Debian
pve_pcie_passthrough_enabled: false # Définissez ceci sur vrai pour activer le passthrough PCIe.
pve_iommu_passthrough_mode: false # Définissez ceci sur vrai pour permettre aux VM de contourner la translation DMA. Cela pourrait augmenter les performances pour le passthrough IOMMU.
pve_iommu_unsafe_interrupts: false # Définissez ceci sur vrai si votre système ne prend pas en charge le remappage des interruptions.
pve_mediated_devices_enabled: false # Définissez ceci sur vrai si votre appareil prend en charge gtv-g et que vous souhaitez activer la fonctionnalité de partage.
pve_pcie_ovmf_enabled: false # Définissez ceci sur vrai pour activer le passthrough PCI GPU OVMF.
pve_pci_device_ids: [] # Liste des identifiants de dispositifs pci (voir https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # Liste des pilotes de dispositifs à mettre sur liste noire depuis l'hôte Proxmox (voir https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Définissez ceci sur vrai si vous le passez à une machine Windows pour éviter les pannes de VM.
pve_pcie_report_msrs: true # Définissez ceci sur faux pour empêcher le système d'enregistrement des rapports de pannes msrs dans dmesg.
pve_watchdog: none # Définissez ceci sur "ipmi" si vous souhaitez configurer un watchdog matériel. Proxmox utilise par défaut un watchdog logiciel (nmi_watchdog).
pve_watchdog_ipmi_action: power_cycle # Peut être l'un de "reset", "power_cycle", et "power_off".
pve_watchdog_ipmi_timeout: 10 # Nombre de secondes que le watchdog doit attendre
pve_zfs_enabled: no # Spécifie s'il faut ou non installer et configurer les paquets ZFS
# pve_zfs_options: "" # paramètres de modprobe à passer au module zfs au démarrage/modprobe
# pve_zfs_zed_email: "" # Doit être défini sur une adresse e-mail pour recevoir des notifications ZFS
pve_zfs_create_volumes: [] # Liste des volumes ZFS à créer (à utiliser comme Stockages PVE). Voir la section sur la gestion du stockage.
pve_ceph_enabled: false # Spécifie s'il faut ou non installer et configurer les paquets Ceph. Voir ci-dessous pour un exemple de configuration.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bullseye main" # configuration du dépôt apt. Sera automatiquement défini pour 6.x et 7.x (plus d'informations : https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Réseau public Ceph
# pve_ceph_cluster_network: "" # Facultatif, si le réseau de cluster ceph est différent du réseau public (voir https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Groupe d'hôtes contenant tous les nœuds Ceph
pve_ceph_mon_group: "{{ pve_group }}" # Groupe d'hôtes contenant tous les hôtes de surveillance Ceph
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Groupe d'hôtes contenant tous les hôtes de gestion Ceph
pve_ceph_mds_group: "{{ pve_group }}" # Groupe d'hôtes contenant tous les hôtes de serveur de métadonnées Ceph
pve_ceph_osds: [] # Liste des disques OSD
pve_ceph_pools: [] # Liste des pools à créer
pve_ceph_fs: [] # Liste des systèmes de fichiers CephFS à créer
pve_ceph_crush_rules: [] # Liste des règles CRUSH à créer
# pve_ssl_private_key: "" # Doit être défini avec le contenu de la clé privée à utiliser pour HTTPS
# pve_ssl_certificate: "" # Doit être défini avec le contenu du certificat à utiliser pour HTTPS
pve_roles: [] # Ajouter plus de rôles avec des privilèges spécifiques. Voir la section sur la gestion des utilisateurs.
pve_groups: [] # Liste des définitions de groupes à gérer dans PVE. Voir la section sur la gestion des utilisateurs.
pve_users: [] # Liste des définitions d'utilisateurs à gérer dans PVE. Voir la section sur la gestion des utilisateurs.
pve_storages: [] # Liste des stockages à gérer dans PVE. Voir la section sur la gestion du stockage.
pve_datacenter_cfg: {} # Dictionnaire pour configurer le fichier de configuration PVE datacenter.cfg.
pve_domains_cfg: [] # Liste des domaines à utiliser comme sources d'authentification dans le fichier de configuration PVE domains.cfg.
pve_no_log: false # Définissez ceci sur vrai en production pour éviter de divulguer des identifiants de stockage dans les journaux d'exécution. (peut être utilisé dans d'autres tâches à l'avenir)

Pour activer le clustering avec ce rôle, configurez les variables suivantes en conséquence :

pve_cluster_enabled: no # Définissez ceci sur oui pour configurer les hôtes à grouper ensemble
pve_cluster_clustername: "{{ pve_group }}" # Devrait être défini sur le nom du cluster PVE
pve_manage_hosts_enabled : yes # Définissez ceci sur non pour NE PAS configurer le fichier hosts (dans le cas d'utilisation d'un VPN et que le fichier hosts est déjà configuré)

Les variables suivantes sont utilisées pour fournir des informations de mise en réseau à corosync. Celles-ci sont connues sous les noms ring0_addr/ring1_addr ou link0_addr/link1_addr, selon la version de PVE. Elles doivent être des adresses IPv4 ou IPv6. Vous pouvez également configurer la priorité de ces interfaces pour indiquer à corosync quelle interface doit gérer le trafic de cluster (des nombres plus bas indiquent une priorité plus élevée). Pour plus d'informations, consultez le chapitre Gestionnaire de cluster dans la documentation PVE.

# pve_cluster_addr0: "{{ défaut à l'interface ipv4 ou ipv6 par défaut si détectée }}"
# pve_cluster_addr1: "adresse IP ou nom d'hôte d'une autre interface"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0

Vous pouvez définir des options dans le fichier de configuration datacenter.cfg :

pve_datacenter_cfg:
  keyboard: en-us

Vous pouvez également configurer groupes dans le gestionnaire HA :

pve_cluster_ha_groups: [] # Liste des groupes HA à créer dans PVE.

Cet exemple crée un groupe "lab_node01" pour les ressources assignées à l'hôte lab-node01 :

pve_cluster_ha_groups:
  - name: lab_node01
    comment: "Mon groupe HA"
    nodes: "lab-node01"
    nofailback: 0
    restricted: 0

Toutes les options de configuration prises en charge dans le fichier datacenter.cfg sont documentées dans la section manuelle datacenter.cfg.

Pour que le rechargement en direct des interfaces réseau fonctionne via l'interface Web de PVE, vous devez installer le paquet ifupdown2. Notez que cela supprimera ifupdown. Vous pouvez spécifier cela en utilisant la variable de rôle pve_extra_packages.

Vous pouvez définir des royaumes/domaines comme sources d'authentification dans le fichier de configuration domains.cfg. Si ce fichier n'est pas présent, seuls les royaumes Linux PAM et serveur d'authentification Proxmox VE sont disponibles. Les types pris en charge sont pam, pve, ad, et ldap. Il est possible de synchroniser automatiquement les utilisateurs et les groupes pour les royaumes basés sur LDAP (LDAP et Microsoft Active Directory) avec sync: true. Un royaume doit avoir la propriété default: 1 pour être marqué comme le par défaut :

pve_domains_cfg:
  - name: pam
    type: pam
    attributes:
      comment: Authentification standard Linux PAM
  - name: pve
    type: pve
    attributes:
      comment: Serveur d'authentification Proxmox VE
  - name: ad
    type: ad
    attributes:
      comment: Authentification Active Directory
      domain: votre_domaine.com
      server1: dc01.votre_domaine.com
      default: 1
      secure: 1
      server2: dc02.votre_domaine.com
  - name: ldap
    type: ldap
    sync: true
    attributes:
      comment: Authentification LDAP
      base_dn: CN=Users,dc=votre_domaine,dc=com
      bind_dn: "uid=svc-reader,CN=Users,dc=votre_domaine,dc=com"
      bind_password: "{{ secret_ldap_svc_reader_password }}"
      server1: ldap1.votre_domaine.com
      user_attr: uid
      secure: 1
      server2: ldap2.votre_domaine.com

Dépendances

Ce rôle n'installe pas NTP, donc vous devriez configurer NTP vous-même, par exemple avec le rôle geerlingguy.ntp comme montré dans l'exemple de playbook.

Lorsque le clustering est activé, ce rôle utilise le filtre json_query, qui nécessite que la bibliothèque jmespath soit installée sur votre hôte de contrôle. Vous pouvez soit pip install jmespath, soit l'installer via le gestionnaire de paquets de votre distribution, par exemple apt-get install python-jmespath.

Gestion des utilisateurs et des ACL

Vous pouvez utiliser ce rôle pour gérer les utilisateurs et groupes au sein de Proxmox VE (à la fois dans des déploiements de serveur unique et des déploiements de cluster). Voici quelques exemples.

pve_groups:
  - name: Admins
    comment: Administrateurs de ce cluster PVE
  - name: api_users
  - name: test_users
pve_users:
  - name: root@pam
    email: [email protected]
  - name: lae@pam
    email: [email protected]
    firstname: Musee
    lastname: Ullah
    groups: [ "Admins" ]
  - name: pveapi@pve
    password: "Proxmox789"
    groups:
      - api_users
  - name: testapi@pve
    password: "Test456"
    enable: no
    groups:
      - api_users
      - test_users
  - name: tempuser@pam
    expire: 1514793600
    groups: [ "test_users" ]
    comment: "Utilisateur temporaire soumis à expiration le 2018年  1月  1日 月曜日 00:00:00 PST"
    email: [email protected]
    firstname: Test
    lastname: Utilisateur

Référez-vous à library/proxmox_user.py lien et library/proxmox_group.py lien pour la documentation des modules.

Pour gérer les rôles et les ACLs, un module similaire est utilisé, mais la principale différence est que la plupart des paramètres n'acceptent que des listes (sujet à changement) :

pve_roles:
  - name: Monitoring
    privileges:
      - "Sys.Modify"
      - "Sys.Audit"
      - "Datastore.Audit"
      - "VM.Monitor"
      - "VM.Audit"
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "Admins" ]
  - path: /pools/testpool
    roles: [ "PVEAdmin" ]
    users:
      - pveapi@pve
    groups:
      - test_users

Référez-vous à library/proxmox_role.py lien et library/proxmox_acl.py lien pour la documentation des modules.

Gestion de stockage

Vous pouvez utiliser ce rôle pour gérer le stockage au sein de Proxmox VE (à la fois dans des déploiements de serveur unique et des déploiements de cluster). Pour l'instant, les seuls types supportés sont dir, rbd, nfs, cephfs, lvm,lvmthin, zfspool, btrfs, cifs et pbs. Voici quelques exemples.

pve_storages:
  - name: dir1
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /ploup
    disable: no
    maxfiles: 4
  - name: ceph1
    type: rbd
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    username: admin
    pool: rbd
    krbd: yes
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: nfs1
    type: nfs
    content: [ "images", "iso" ]
    server: 192.168.122.2
    export: /data
  - name: lvm1
    type: lvm
    content: [ "images", "rootdir" ]
    vgname: vg1
  - name: lvmthin1
    type: lvmthin
    content: [ "images", "rootdir" ]
    vgname: vg2
    thinpool: data
  - name: cephfs1
    type: cephfs
    content: [ "snippets", "vztmpl", "iso" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: pbs1
    type: pbs
    content: [ "backup" ]
    server: 192.168.122.2
    username: user@pbs
    password: PBSPassword1
    datastore: main
    namespace: Top/something # Facultatif
  - name: zfs1
    type: zfspool
    content: [ "images", "rootdir" ]
    pool: rpool/data
    sparse: true
  - name: btrfs1
    type: btrfs
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    path: /mnt/proxmox_storage
    is_mountpoint: true
  - name: cifs1
    server: cifs-host.domain.tld
    type: cifs
    content: [ "snippets", "vztmpl", "iso" ]
    share: sharename
    subdir: /subdir
    username: user
    password: supersecurepass
    domain: addomain.tld

Référez-vous à https://pve.proxmox.com/pve-docs/api-viewer/index.html pour plus d'informations.

Actuellement, le type zfspool ne peut être utilisé que pour les contenus images et rootdir. Si vous souhaitez stocker d'autres types de contenu sur un volume ZFS, vous devez les spécifier avec le type dir, le chemin /<POOL>/<VOLUME> et ajouter une entrée dans pve_zfs_create_volumes. Cet exemple ajoute un stockage iso sur un pool ZFS :

pve_zfs_create_volumes:
  - rpool/iso
pve_storages:
  - name: iso
    type: dir
    path: /rpool/iso
    content: [ "iso" ]

Référez-vous à library/proxmox_storage.py lien pour la documentation du module.

Configuration de Ceph

Cette section pourrait bénéficier d'un peu plus d'attention. Si vous utilisez activement ce rôle pour gérer votre cluster Ceph PVE, n'hésitez pas à enrichir cette section et à ouvrir une demande de tirage ! Voir le problème #68.

La gestion Ceph PVE avec ce rôle est expérimentale. Bien que les utilisateurs aient réussi à utiliser ce rôle pour déployer PVE Ceph, il n'est pas complètement testé en CI (en raison d'un manque de dispositifs de bloc utilisables à utiliser comme OSD dans Travis CI). Veuillez déployer un environnement de test avec votre configuration avant la production, et signalez tout problème si vous en rencontrez.

Ce rôle peut configurer le système de stockage Ceph sur vos hôtes Proxmox. Les définitions suivantes montrent certaines des configurations possibles.

pve_ceph_enabled: true
pve_ceph_network: '172.10.0.0/24'
pve_ceph_cluster_network: '172.10.1.0/24'
pve_ceph_nodes: "ceph_nodes"
pve_ceph_osds:
  # OSD avec tout sur le même dispositif
  - device: /dev/sdc
  # OSD avec block.db/WAL sur un autre dispositif
  - device: /dev/sdd
    block.db: /dev/sdb1
  # OSD chiffré avec tout sur le même dispositif
  - device: /dev/sdc
    encrypted: true
  # OSD chiffré avec block.db/WAL sur un autre dispositif
  - device: /dev/sdd
    block.db: /dev/sdb1
    encrypted: true
# Règles Crush pour les différentes classes de stockage
# Par défaut, 'type' est défini sur l'hôte, vous pouvez trouver des types valides à
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# listés sous 'TYPES AND BUCKETS'
pve_ceph_crush_rules:
  - name: replicated_rule
    type: osd # Ceci est un exemple de la façon dont vous pouvez remplacer une règle préexistante
  - name: ssd
    class: ssd
    type: osd
    min-size: 2
    max-size: 8
  - name: hdd
    class: hdd
    type: host
# 2 pools Ceph pour les disques VM qui seront également définis comme stockages Proxmox
# Utilisation de règles CRUSH différentes
pve_ceph_pools:
  - name: ssd
    pgs: 128
    rule: ssd
    application: rbd
    storage: true
# Ce pool Ceph utilise des valeurs de taille/réplication personnalisées
  - name: hdd
    pgs: 32
    rule: hdd
    application: rbd
    storage: true
    size: 2
    min-size: 1
# Ce pool Ceph utilise le mode d'auto-échelle personnalisée : "off" | "on" | "warn" (défaut = "warn")
  - name: vm-storage
    pgs: 128
    rule: replicated_rule
    application: rbd
    autoscale_mode: "on"
    storage: true
pve_ceph_fs:
# Un système de fichiers CephFS non défini comme stockage Proxmox
  - name: backup
    pgs: 64
    rule: hdd
    storage: false
    mountpoint: /srv/proxmox/backup

pve_ceph_network utilise par défaut le filtre ansible.utils.ipaddr, qui nécessite que la bibliothèque netaddr soit installée et utilisable par votre contrôleur Ansible.

pve_ceph_nodes utilise par défaut pve_group, ce paramètre permet de spécifier sur quels nœuds installer Ceph (par exemple, si vous ne souhaitez pas installer Ceph sur tous vos nœuds).

pve_ceph_osds crée par défaut des volumes ceph non chiffrés. Pour utiliser des volumes chiffrés, le paramètre encrypted doit être défini pour chaque disque sur true.

Passthrough PCIe

Ce rôle peut être configuré pour permettre le passthrough de dispositifs PCI de l'hôte Proxmox aux VM. Cette fonctionnalité n'est pas activée par défaut car toutes les cartes mères et tous les processeurs ne prennent pas en charge cette fonctionnalité. Pour activer le passthrough, le processeur doit prendre en charge la virtualisation matérielle (VT-d pour les systèmes basés sur Intel et AMD-V pour les systèmes basés sur AMD). Consultez les manuels de tous les composants pour déterminer si cette fonctionnalité est prise en charge ou non. Les conventions de nommage varieront, mais elle est généralement appelée IOMMU, VT-d, ou AMD-V.

En activant cette fonctionnalité, des dispositifs dédiés (tels que GPU ou dispositifs USB) peuvent être passés à des VM. En plus des dispositifs dédiés, divers dispositifs intégrés tels que les GPU intégrés d'Intel ou d'AMD peuvent également être passés à des VM.

Certains dispositifs peuvent tirer parti d'une utilisation médiée. Les dispositifs médiés peuvent être passés à plusieurs VM pour partager des ressources, tout en restant utilisables par le système hôte. Le partage des dispositifs n'est pas toujours pris en charge et doit être validé avant d'être activé pour éviter des erreurs. Consultez le manuel du dispositif que vous souhaitez passer pour déterminer si le dispositif est capable d'utilisation médiée (actuellement, ce rôle ne prend en charge que GVT-g ; SR-IOV n'est pas actuellement pris en charge et doit être activé manuellement après l'achèvement du rôle).

Voici une configuration d'exemple qui active le passthrough PCIe :

pve_pcie_passthrough_enabled: true
pve_iommu_passthrough_mode: true
pve_iommu_unsafe_interrupts: false
pve_mediated_devices_enabled: false
pve_pcie_ovmf_enabled: false
pve_pci_device_ids:
  - id: "10de:1381"
  - id: "10de:0fbc"
pve_vfio_blacklist_drivers:
  - name: "radeon"
  - name: "nouveau"
  - name: "nvidia"
pve_pcie_ignore_msrs: false
pve_pcie_report_msrs: true

pve_pcie_passthrough_enabled est requis pour utiliser toute fonctionnalité de passthrough PCIe. Sans cela activé, tous les autres champs liés au PCIe ne seront pas utilisés.

pve_iommu_passthrough_mode activer le mode de passthrough IOMMU peut augmenter les performances des dispositifs. En activant cette fonctionnalité, elle permet aux VM de contourner la translation DMA par défaut qui serait normalement effectuée par l'hyperviseur. Au lieu de cela, les VM passent les requêtes DMA directement au matériel IOMMU.

pve_iommu_unsafe_interrupts doit être activé pour permettre le passthrough PCI si votre système ne prend pas en charge le remappage des interruptions. Vous pouvez vérifier si le dispositif prend en charge le remappage des interruptions en utilisant dmesg | grep 'remapping'. Si vous voyez l'une des lignes suivantes :

• "AMD-Vi : Remappage des interruptions activé"
• "DMAR-IR : Remappage des IRQs activé en mode x2apic" (le 'x2apic' peut être différent sur des anciens processeurs, mais cela devrait toujours fonctionner)

Alors le remappage des interruptions système est pris en charge et vous n'avez pas besoin d'activer les interruptions non sécurisées. Veuillez noter qu'en activant cette valeur, votre système peut devenir instable.

pve_mediated_devices_enabled active le support GVT-g pour les dispositifs intégrés tels que les GPU iGPU d'Intel. Tous les dispositifs ne prennent pas en charge GVT-g, il est donc recommandé de vérifier auprès de votre dispositif spécifique au préalable pour vous assurer qu'il est autorisé.

pve_pcie_ovmf_enabled active le passthrough PCI GPU OVMF. Lors de l'utilisation d'OVMF, vous devriez sélectionner 'OVMF' comme option de BIOS pour la VM au lieu de 'SeaBIOS' dans Proxmox. Ce paramètre essaiera d'exclure les dispositifs de l'arbitrage VGA si possible.

pve_pci_device_ids est une liste d'identifiants de dispositifs et de fournisseurs que vous souhaitez passer aux VM depuis l'hôte. Consultez la section 'GPU Passthrough' sur le WIKI Proxmox pour trouver vos identifiants de dispositifs et de fournisseurs spécifiques. En définissant cette valeur, il est nécessaire de spécifier un 'id' pour chaque nouvel élément dans le tableau.

pve_vfio_blacklist_drivers est une liste de pilotes à exclure/mettre sur liste noire sur l'hôte. Cela est requis lors du passthrough d'un dispositif PCI pour empêcher l'hôte d'utiliser le dispositif avant qu'il ne puisse être assigné à une VM. En définissant cette valeur, il est requis de spécifier un 'name' pour chaque nouvel élément dans le tableau.

pve_pcie_ignore_msrs empêche certaines applications sous Windows comme GeForce Experience, Passmark Performance Test et SiSoftware Sandra de faire planter la VM. Cette valeur est uniquement requise lors du passthrough de dispositifs PCI vers des systèmes basés sur Windows.

pve_pcie_report_msrs peut être utilisé pour activer ou désactiver la journalisation des messages d'avertissement msrs. Si vous voyez beaucoup de messages d'avertissement dans vos journaux système 'dmesg', cette valeur peut être utilisée pour désactiver ces messages d'avertissement msrs.

Notes pour les développeurs

Lorsque vous développez de nouvelles fonctionnalités ou corrigez quelque chose dans ce rôle, vous pouvez tester vos modifications à l'aide de Vagrant (seul libvirt est pris en charge actuellement). Le playbook peut être trouvé dans tests/vagrant (donc assurez-vous de modifier les variables de groupe selon vos besoins). Assurez-vous de tester tous les changements sur Debian 10 et 11 (mettez à jour le Vagrantfile localement pour utiliser debian/buster64) avant de soumettre une PR.

Vous pouvez également spécifier un proxy de mise en cache apt (par exemple apt-cacher-ng, qui doit fonctionner sur le port 3142) avec la variable d'environnement APT_CACHE_HOST pour accélérer le téléchargement de paquets si vous en avez un fonctionnant localement dans votre environnement. Le playbook vagrant détectera si le proxy de mise en cache est disponible et ne l'utilisera que s'il est accessible depuis votre réseau, vous pourriez donc définir cette variable de manière permanente dans votre environnement de développement si vous le souhaitez.

Par exemple, vous pourriez exécuter ce qui suit pour afficher une sortie plus détaillée/facile à lire, utiliser un proxy de mise en cache et garder les VM en cours d'exécution si vous rencontrez une erreur (afin que vous puissiez résoudre le problème et/ou exécuter vagrant provision après correction) :

    APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error

Contributeurs

Musee Ullah (@lae, lae@lae.is) - Développeur principal
Fabien Brachere (@Fbrachere) - Support de la configuration de stockage
Gaudenz Steinlin (@gaundez) - Support Ceph, etc.
Richard Scott (@zenntrix) - Support Ceph, support PVE 7.x, etc.
Thoralf Rickert-Wendt (@trickert76) - Support PVE 6.x, etc.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@SniperCZE)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - Support PVE 8.x, etc.
Bruno Travouillon (@btravouillon) - Améliorations UX
Tobias Negd (@wu3rstle) - Support Ceph
PendaGTP (@PendaGTP) - Support Ceph
John Marion (@jmariondev)
foerkede (@foerkede) - Support de stockage ZFS
Guiffo Joel (@futuriste) - Support de configuration de pool
Adam Delo (@ol3d) - Support de passthrough PCIe

Liste complète des contributeurs