ansible role proxmox
v1.9.0
Installiert und konfiguriert die virtuelle Proxmox -Umgebung 6.x/7.x/8.x auf Debian -Servern.
Mit dieser Rolle können Sie PVE-Installationen und PVE-Cluster (3+ Knoten) auf Debian Buster (10) und Bullseye (11) und Bookworm (12) bereitstellen und verwalten. Sie können Folgendes mit Hilfe dieser Rolle konfigurieren:
datacenter.cfgpve-enterprise Repository-Auswahl ( pve-no-subscription .Wenn Clustering aktiviert ist, ist diese Rolle Folgendes (oder ermöglicht dies):
Für Unterstützung oder wenn Sie zu dieser Rolle beitragen möchten, aber Anleitung wünschen, können Sie sich diesem Discord -Server anschließen: https://discord.gg/cjqr6fg. Bitte beachten Sie, dass dies eine vorübergehende Einladung ist. Sie müssen also darauf warten, dass @lae Ihnen eine Rolle zuordnet, andernfalls entzieht Discord Sie beim Abmelden aus dem Server.
Das Hauptziel für diese Rolle ist es, einen Proxmox -VE -Cluster zu konfigurieren und zu verwalten (siehe Beispiel für Playbook). Diese Rolle kann jedoch verwendet werden, um einzelne Knoten -Proxmox -Server schnell zu installieren.
Ich gehe davon aus, dass Sie bereits Ansible installiert haben. Sie müssen eine externe Maschine zu dem, auf dem Sie Proxmox installieren, verwenden (vor allem aufgrund des Neustarts in der Mitte der Installation, obwohl ich dies möglicherweise später für diesen Anwendungsfall etwas anders bewältigen kann).
Kopieren Sie das folgende Spielbuch in eine Datei wie 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
Installieren Sie diese Rolle und eine Rolle für die Konfiguration von NTP:
ansible-galaxy install lae.proxmox geerlingguy.ntp
Jetzt können Sie die Installation durchführen:
ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER
Wenn Ihr SSH_USER ein Sudo -Passwort hat, übergeben Sie das -K -Flag an den obigen Befehl. Wenn Sie sich auch mit dem Host über Passwort anstelle von Pubkey -Authaut authentifizieren, übergeben Sie das -k -Flag (stellen Sie sicher, dass sshpass installiert ist). Sie können diese Variablen vor dem Ausführen des Befehls festlegen oder einfach ersetzen. Beachten Sie, dass das Komma wichtig ist, wie eine Liste erwartet wird (ansonsten wird versucht, eine Datei mit einer Liste von Hosts zu suchen).
Sobald Sie fertig sind, sollten Sie in der Lage sein, auf Ihre Proxmox -VE -Instanz unter https://$SSH_HOST_FQDN:8006 zugreifen zu können.
Erstellen Sie ein neues Playbook -Verzeichnis. Wir nennen unseren lab-cluster . Unser Spielbuch wird irgendwann so aussehen, aber Ihr muss nicht alle Schritte befolgen:
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
6 directories, 12 files
Das erste, was Sie vielleicht bemerken, ist, dass wir eine Reihe von .key und .pem -Dateien haben. Dies sind private Schlüssel- und SSL -Zertifikate, mit denen diese Rolle die Webschnittstelle für Proxmox über alle Knoten hinweg konfiguriert wird. Diese sind jedoch nicht erforderlich, wenn Sie die signierten Zertifikate von der CA verwenden möchten, die ProxMox intern einstellt. Sie können in der Regel Ansible Vault verwenden, um die privaten Schlüssel zu verschlüsseln, z. B.:
ansible-vault encrypt files/pve01/*.key
Dadurch müssen Sie das Tresorkennwort beim Ausführen des Playbooks übergeben.
Lassen Sie uns zunächst unsere Cluster -Hosts angeben. Unsere inventory kann so aussehen:
[pve01]
lab-node01.local
lab-node02.local
lab-node03.local
Sie könnten mehrere Cluster haben, daher ist es eine gute Idee, eine Gruppe für jeden Cluster zu haben. Lassen Sie uns nun unsere Rollenanforderungen in roles/requirements.yml angeben.
---
- src: geerlingguy.ntp
- src: lae.proxmox
Wir brauchen eine NTP -Rolle, um NTP zu konfigurieren. Daher verwenden wir Jeff Geerlings Rolle, um dies zu tun. Sie würden es nicht benötigen, wenn Sie NTP bereits konfigurieren oder eine andere Methode zum Konfigurieren von NTP haben.
Lassen Sie uns nun einige Gruppenvariablen angeben. Lassen Sie uns zunächst group_vars/all zum Einstellen von NTP-bezogenen Variablen erstellen:
---
ntp_manage_config: true
ntp_servers:
- lab-ntp01.local iburst
- lab-ntp02.local iburst
Ersetzen Sie natürlich diese NTP -Server durch die, die Sie bevorzugen.
Nun zum Fleisch Ihres Spielbuchs, die Gruppenvariablen von pve01 . Erstellen Sie eine Datei group_vars/pve01 , fügen Sie Folgendes hinzu und ändern Sie entsprechend für Ihre Umgebung.
---
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: Operations Team
pve_users:
- name: admin1@pam
email: [email protected]
firstname: Admin
lastname: User 1
groups: [ "ops" ]
- name: admin2@pam
email: [email protected]
firstname: Admin
lastname: User 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 wird auf den Gruppennamen unseres Clusters pve01 eingestellt - es wird verwendet, um sicherzustellen, dass alle Hosts innerhalb dieser Gruppe eine Verbindung zueinander herstellen können und zusammengeklustert werden. Beachten Sie, dass der PVE -Cluster -Name auch auf diesen Gruppennamen festgelegt wird, sofern nicht anders von pve_cluster_clustername angegeben. Das Verlassen dieses undefinierten Verlassens wird standardmäßig proxmox sein.
pve_watchdog hier ermöglicht die Unterstützung von IPMI Watchdog und konfiguriert den HA -Manager von PVE, um ihn zu verwenden. Verwenden Sie None oder lassen Sie dies undefiniert, um den Standard -Proxmox -Softwarebestand zu verwenden. Wenn es auf irgendetwas anderes eingestellt ist, wird erwartet, dass der Wert ein Wachhund -Kernel -Modul ist.
pve_ssl_private_key und pve_ssl_certificate auf die SSL -Zertifikate für PVeCluster verweisen. Hier wird eine Datei-Suche verwendet, um den Inhalt einer Datei im Playbook, files/pve01/lab-node01.key . Wenn Sie es vorziehen, können Sie möglicherweise Hostvariablen anstelle von Dateien verwenden.
pve_cluster_enabled ermöglicht die Rolle, alle Cluster -Verwaltungsaufgaben auszuführen. Dies beinhaltet das Erstellen eines Clusters, wenn es nicht vorhanden ist, oder das Hinzufügen von Knoten zum vorhandenen Cluster. Es gibt Schecks, um sicherzustellen, dass Sie keine Knoten mischen, die bereits in vorhandenen Clustern mit unterschiedlichen Namen enthalten sind.
pve_groups , pve_users und pve_acls genehmigt einige lokale UNIX -Benutzer (sie müssen bereits existieren), um auf PVE zuzugreifen, und gibt ihnen die Administratorrolle als Teil der ops -Gruppe. Lesen Sie den Abschnitt Benutzer- und ACL -Management, um weitere Informationen zu erhalten.
pve_storages ermöglicht das Erstellen verschiedener Speichertypen und konfigurieren sie. Das Backend muss von Proxmox unterstützt werden. Lesen Sie den Abschnitt "Speicherverwaltung", um weitere Informationen zu erhalten.
pve_metric_servers können Sie einen metrischen Server für den PVE -Cluster konfigurieren. Dies ist nützlich, wenn Sie InfluxDB, Graphit oder andere (mit Telegraf) verwenden möchten.
pve_ssh_port können Sie den SSH -Anschluss ändern. Wenn Ihr SSH auf einen anderen Port als den Standard 22 hört, setzen Sie diese Variable bitte. Wenn ein neuer Knoten dem Cluster verbindet, muss der PVE -Cluster einmal über SSH kommunizieren.
pve_manage_ssh (Standard True) können Sie alle Änderungen deaktivieren, die dieses Modul an Ihrer SSH -Serverkonfiguration vornehmen würde. Dies ist nützlich, wenn Sie eine andere Rolle verwenden, um Ihren SSH -Server zu verwalten. Beachten Sie, dass die Einstellung dieser auf False nicht offiziell unterstützt wird. Sie sind alleine, um die Änderungen zu replizieren, die normalerweise in ssh_cluster_config.yml und pve_add_node.yml vorgenommen werden.
interfaces_template ist auf den Pfad einer Vorlage eingestellt, die wir für die Konfiguration des Netzwerks auf diesen Debian -Maschinen verwenden werden. Dies ist nur erforderlich, wenn Sie das Netzwerk von Ansible und nicht manuell oder über jeden Host in PVE verwalten möchten. Sie sollten wahrscheinlich vor dem Durchführen mit Ansible vertraut sein, da Ihre Methode möglicherweise Hostvariablen für die IP -Adressen für jeden Host usw. festlegen kann.
Lassen Sie uns diese Schnittstellenvorlage aus dem Weg richten. Fühlen Sie sich frei, diese Datei zu überspringen (und lassen Sie sie sonst in group_vars/pve01 undefiniert. Hier ist eine, die ich benutze:
# {{ 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
Möglicherweise sind Sie mit der dig Lookup nicht vertraut, aber im Grunde genommen führen wir hier eine Aufzeichnung für jeden Computer (z. ) und dann eine weitere leicht modifizierte Suche nach dem "Clustering" -Netzwerk, das wir für CEPH ("Lab-Node01-CluSternet.Local") verwenden. Natürlich können Ihre möglicherweise völlig anders aussehen, insbesondere wenn Sie Bonding verwenden, drei verschiedene Netzwerke für Management/Corosync, Speicher- und VM -Verkehr usw.
Schließlich schreiben wir unser Spielbuch. site.yml sieht ungefähr so aus:
---
- hosts: all
become: True
roles:
- geerlingguy.ntp
# Leave this out if you're not modifying networking through Ansible
- hosts: pve01
become: True
serial: 1
tasks:
- name: Install bridge-utils
apt:
name: bridge-utils
- name: Configure /etc/network/interfaces
template:
src: "{{ interfaces_template }}"
dest: /etc/network/interfaces
register: _configure_interfaces
- block:
- name: Reboot for networking changes
shell: "sleep 5 && shutdown -r now 'Networking changes found, rebooting'"
async: 1
poll: 0
- name: Wait for server to come back online
wait_for_connection:
delay: 15
when: _configure_interfaces is changed
- hosts: pve01
become: True
roles:
- lae.proxmox
Grundsätzlich führen wir die NTP-Rolle für alle Hosts aus (Sie möchten möglicherweise einige Nicht-Proxmox-Maschinen hinzufügen), die Netzwerk auf pve01 mit unserem separaten Cluster-Netzwerk- und Bridge-Layout konfigurieren, neu starten, um diese Änderungen in Kraft zu setzen, und dann diese Proxmox-Rolle ausführen gegen die Hosts, um einen Cluster einzurichten.
Zu diesem Zeitpunkt ist unser Spielbuch fertig und wir können das Spielbuch ausführen.
Stellen Sie sicher, dass Rollen und Abhängigkeiten installiert sind:
ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython
jmespath ist für einige der Aufgaben mit Clustering erforderlich. dnspython ist nur erforderlich, wenn Sie eine dig -Suche verwenden, die Sie wahrscheinlich nicht sein werden, wenn Sie das Konfigurieren von Networking übersprungen haben. Wir --force hier an ansible-galaxy , damit die Rollen auf ihre neuesten Versionen aktualisiert werden, wenn sie bereits installiert sind.
Führen Sie jetzt das Spielbuch aus:
ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'
Die -e '{"pve_reboot_on_kernel_update": true}' sollte hauptsächlich ausgeführt werden, wenn Sie das erste Mal das Proxmox -Cluster -Setup durchführen, da er den Server neu startet, um in einen PVE -Kernel zu starten. Nachfolgende Läufe sollten dies auslassen, da Sie Server nach dem Ausführen des Clusters nacheinander neu starten möchten.
Um einen bestimmten Benutzer anzugeben, verwenden Sie -u root ( root ersetzen). Wenn Sie Kennwörter angeben müssen, verwenden Sie -k für SSH -Passwort und/oder -K für Sudo -Passwort. Zum Beispiel:
ansible-playbook -i inventory site.yml -K -u admin1
Dadurch wird nach einem Sudo -Passwort gefragt, sich dann beim admin1 -Benutzer anmelden (mithilfe öffentlicher Schlüsselauth - King -k für PW) und das Playbook ausführen.
Das war's! Sie sollten jetzt einen vollständig bereitgestellten Proxmox -Cluster haben. Möglicherweise möchten Sie anschließend einen Ceph -Speicher darauf erstellen (siehe CEPH für weitere Informationen) und andere Aufgaben möglicherweise, aber der schwierige Teil ist größtenteils vollständig.
Dadurch werden Hosts in der Gruppe pve01 als ein Cluster konfiguriert und die Maschinen neu gestartet, falls der Kernel aktualisiert wurde. (Es wird nur empfohlen, dieses Flag während der Installation einzustellen - Neustarts während des Betriebs sollte während eines Wartungszeitraums seriell erfolgen.) Außerdem ermöglicht es den IPMI -Watchdog.
- 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
Über Standardwerte: Einige der Standardwerte werden zur Laufzeit ausgewählt und können sich daher von dem hier aufgeführten Beispiel unterscheiden.
[variable]: [default] #[description/purpose]
pve_group: proxmox # host group that contains the Proxmox hosts to be clustered together
pve_repository_line: "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" # apt-repository configuration - change to enterprise if needed (although TODO further configuration may be needed)
pve_remove_subscription_warning: true # patches the subscription warning messages in proxmox if you are using the community edition
pve_extra_packages: [] # Any extra packages you may want to install, e.g. ngrep
pve_run_system_upgrades: false # Let role perform system upgrades
pve_run_proxmox_upgrades: true # Let role perform Proxmox VE upgrades
pve_check_for_kernel_update: true # Runs a script on the host to check kernel versions
pve_reboot_on_kernel_update: false # If set to true, will automatically reboot the machine on kernel updates
pve_reboot_on_kernel_update_delay: 60 # Number of seconds to wait before and after a reboot process to proceed with next task in cluster mode
pve_remove_old_kernels: true # Currently removes kernel from main Debian repository
# pve_default_kernel_version: # version to pin proxmox-default-kernel to (see https://pve.proxmox.com/wiki/Roadmap#Kernel_6.8)
pve_pcie_passthrough_enabled: false # Set this to true to enable PCIe passthrough.
pve_iommu_passthrough_mode: false # Set this to true to allow VMs to bypass the DMA translation. This might increase performance for IOMMU passthrough.
pve_iommu_unsafe_interrupts: false # Set this to true if your system doesn't support interrupt remapping.
pve_mediated_devices_enabled: false # Set this to true if your device supports gtv-g and you wish to enable split functionality.
pve_pcie_ovmf_enabled: false # Set this to true to enable GPU OVMF PCI passthrough.
pve_pci_device_ids: [] # List of pci device ID's (see https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # List of device drivers to blacklist from the Proxmox host (see https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Set this to true if passing through to Windows machine to prevent VM crashing.
pve_pcie_report_msrs: true # Set this to false to prevent dmesg system from logging msrs crash reports.
pve_watchdog: none # Set this to "ipmi" if you want to configure a hardware watchdog. Proxmox uses a software watchdog (nmi_watchdog) by default.
pve_watchdog_ipmi_action: power_cycle # Can be one of "reset", "power_cycle", and "power_off".
pve_watchdog_ipmi_timeout: 10 # Number of seconds the watchdog should wait
pve_zfs_enabled: no # Specifies whether or not to install and configure ZFS packages
# pve_zfs_options: "" # modprobe parameters to pass to zfs module on boot/modprobe
# pve_zfs_zed_email: "" # Should be set to an email to receive ZFS notifications
pve_zfs_create_volumes: [] # List of ZFS Volumes to create (to use as PVE Storages). See section on Storage Management.
pve_ceph_enabled: false # Specifies wheter or not to install and configure Ceph packages. See below for an example configuration.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bookworm main" # apt-repository configuration. Will be automatically set for 6.x and 7.x (Further information: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Ceph public network
# pve_ceph_cluster_network: "" # Optional, if the ceph cluster network is different from the public network (see https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Host group containing all Ceph nodes
pve_ceph_mon_group: "{{ pve_group }}" # Host group containing all Ceph monitor hosts
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Host group containing all Ceph manager hosts
pve_ceph_mds_group: "{{ pve_group }}" # Host group containing all Ceph metadata server hosts
pve_ceph_osds: [] # List of OSD disks
pve_ceph_pools: [] # List of pools to create
pve_ceph_fs: [] # List of CephFS filesystems to create
pve_ceph_crush_rules: [] # List of CRUSH rules to create
# pve_ssl_private_key: "" # Should be set to the contents of the private key to use for HTTPS
# pve_ssl_certificate: "" # Should be set to the contents of the certificate to use for HTTPS
pve_roles: [] # Added more roles with specific privileges. See section on User Management.
pve_groups: [] # List of group definitions to manage in PVE. See section on User Management.
pve_users: [] # List of user definitions to manage in PVE. See section on User Management.
pve_storages: [] # List of storages to manage in PVE. See section on Storage Management.
pve_metric_servers: [] # List of metric servers to configure in PVE.
pve_datacenter_cfg: {} # Dictionary to configure the PVE datacenter.cfg config file.
pve_domains_cfg: [] # List of realms to use as authentication sources in the PVE domains.cfg config file.
pve_no_log: false # Set this to true in production to prevent leaking of storage credentials in run logs. (may be used in other tasks in the future)
Konfigurieren Sie die folgenden Variablen angemessen, um die Clusterbildung mit dieser Rolle zu ermöglichen:
pve_cluster_enabled: no # Set this to yes to configure hosts to be clustered together
pve_cluster_clustername: "{{ pve_group }}" # Should be set to the name of the PVE cluster
pve_manage_hosts_enabled : yes # Set this to no to NOT configure hosts file (case of using vpn and hosts file is already configured)
Die folgenden Variablen werden verwendet, um Corosync Networking -Informationen bereitzustellen. Diese sind je nach PVE -Version Sie sollten IPv4- oder IPv6 -Adressen sein. Sie können auch die Priorität dieser Schnittstellen so konfigurieren, dass die Schnittstelle den Clusterverkehr verarbeiten sollte (niedrigere Zahlen geben eine höhere Priorität an). Weitere Informationen finden Sie im Kapitel von Cluster Manager in der PVE -Dokumentation.
# pve_cluster_addr0: "{{ defaults to the default interface ipv4 or ipv6 if detected }}"
# pve_cluster_addr1: "another interface's IP address or hostname"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0
Sie können Optionen in der Konfigurationsdatei von DataCenter.cfg festlegen:
pve_datacenter_cfg:
keyboard: en-us
Sie können auch HA -Manager -Gruppen konfigurieren:
pve_cluster_ha_groups: [] # List of HA groups to create in PVE.
In diesem Beispiel wird eine Gruppe "Lab_node01" für Ressourcen erstellt, die dem Labor-Node01-Host zugewiesen sind:
pve_cluster_ha_groups:
- name: lab_node01
comment: "My HA group"
nodes: "lab-node01"
nofailback: 0
restricted: 0
Alle in der DataCenter.cfg -Datei unterstützten Konfigurationsoptionen sind im Abschnitt "ProxMOX Manual Datacenter.cfg" dokumentiert.
Damit das Live -Nachladen von Netzwerkschnittstellen über die PVE -Web -Benutzeroberfläche funktioniert, müssen Sie das ifupdown2 -Paket installieren. Beachten Sie, dass dies ifupdown entfernen wird. Sie können dies mit der Rollenvariablen pve_extra_packages angeben.
Sie können Realms / Domänen als Authentifizierungsquellen in der Konfigurationsdatei domains.cfg festlegen. Wenn diese Datei nicht vorhanden ist, stehen nur die Realms Linux PAM und Proxmox VE authentication server zur Verfügung. Unterstützte Typen sind pam , pve , ad und ldap . Es ist möglich, Benutzer und Gruppen automatisch für LDAP-basierte Realms (LDAP & Microsoft Active Directory) mit sync: true zu synchronisieren. Ein Reich sollte die default: 1 Eigenschaft, um sie als Standard zu markieren:
pve_domains_cfg:
- name: pam
type: pam
attributes:
comment: Linux PAM standard authentication
- name: pve
type: pve
attributes:
comment: Proxmox VE authentication server
- name: ad
type: ad
attributes:
comment: Active Directory authentication
domain: yourdomain.com
server1: dc01.yourdomain.com
default: 1
secure: 1
server2: dc02.yourdomain.com
- name: ldap
type: ldap
sync: true
attributes:
comment: LDAP authentication
base_dn: CN=Users,dc=yourdomain,dc=com
bind_dn: "uid=svc-reader,CN=Users,dc=yourdomain,dc=com"
bind_password: "{{ secret_ldap_svc_reader_password }}"
server1: ldap1.yourdomain.com
user_attr: uid
secure: 1
server2: ldap2.yourdomain.com
Diese Rolle installiert NTP nicht, daher sollten Sie NTP selbst konfigurieren, z. B. mit der Rolle der geerlingguy.ntp wie im Beispiel -Playbook gezeigt.
Wenn das Clustering aktiviert ist, nutzt diese Rolle den json_query -Filter, wodurch die jmespath -Bibliothek auf Ihrem Steuerhost installiert wird. Sie können entweder pip install jmespath oder es über den Paketmanager Ihrer Verteilung installieren, z. B. apt-get install python-jmespath .
Sie können diese Rolle nutzen, um Benutzer und Gruppen innerhalb von Proxmox VE zu verwalten (sowohl in einzelnen Serverbereitstellungen als auch in Cluster -Bereitstellungen). Hier sind einige Beispiele.
pve_groups:
- name: Admins
comment: Administrators of this PVE cluster
- 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: "Temporary user set to expire on 2018年 1月 1日 月曜日 00:00:00 PST"
email: [email protected]
firstname: Test
lastname: User
Siehe Link library/proxmox_user.py und library/proxmox_group.py Link für die Moduldokumentation.
Für die Verwaltung von Rollen und ACLs wird ein ähnliches Modul verwendet, aber der Hauptunterschied besteht darin, dass die meisten Parameter nur Listen akzeptieren (vorbehaltlich der Änderung):
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
Siehe Link library/proxmox_role.py und library/proxmox_acl.py Link für die Moduldokumentation.
Sie können diese Rolle nutzen, um den Speicher innerhalb von Proxmox VE (sowohl in einzelnen Serverbereitstellungen als auch in Cluster -Bereitstellungen) zu verwalten. Derzeit sind die einzigen unterstützten Typen dir , rbd , nfs , cephfs , lvm , lvmthin , zfspool , btrfs , cifs und pbs . Hier sind einige Beispiele.
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 # Optional
- 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
Weitere Informationen finden Sie unter https://pve.proxmox.com/pve-docs/api-viewer/index.html.
Derzeit kann der zfspool -Typ nur für images und rootdir -Inhalte verwendet werden. Wenn Sie die anderen Inhaltstypen in einem ZFS -Volumen speichern möchten, müssen Sie sie mit Typ dir , Path /<POOL>/<VOLUME> angeben und einen Eintrag in pve_zfs_create_volumes hinzufügen. Dieses Beispiel fügt einen iso -Speicher auf einem ZFS -Pool hinzu:
pve_zfs_create_volumes:
- rpool/iso
pve_storages:
- name: iso
type: dir
path: /rpool/iso
content: [ "iso" ]
Weitere Informationen zur Moduldokumentation finden Sie in library/proxmox_storage.py Link.
Dieser Abschnitt könnte etwas mehr Liebe gebrauchen. Wenn Sie diese Rolle aktiv nutzen, um Ihren PVE -CEPH -Cluster zu verwalten, können Sie diesen Abschnitt nicht gründlicher fleischieren und eine Pull -Anfrage öffnen! Siehe Ausgabe Nr. 68.
PVE CEPH -Management mit dieser Rolle ist experimentell. Während Benutzer diese Rolle erfolgreich für die Bereitstellung von PVE CEPH genutzt haben, wird sie in CI nicht vollständig getestet (aufgrund des Mangels an nutzbaren Blockgeräten, die als OSDS in Travis CI verwendet werden können). Bitte geben Sie eine Testumgebung zuerst vor dem Produkt mit Ihrer Konfiguration ein und melden Sie Probleme, wenn Sie auf eine Begegnung stoßen.
Diese Rolle kann das CEPH -Speichersystem auf Ihren Proxmox -Hosts konfigurieren. Die folgenden Definitionen zeigen einige der möglichen Konfigurationen.
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 with everything on the same device
- device: /dev/sdc
# OSD with block.db/WAL on another device
- device: /dev/sdd
block.db: /dev/sdb1
# encrypted OSD with everything on the same device
- device: /dev/sdc
encrypted: true
# encrypted OSD with block.db/WAL on another device
- device: /dev/sdd
block.db: /dev/sdb1
encrypted: true
# Crush rules for different storage classes
# By default 'type' is set to host, you can find valid types at
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# listed under 'TYPES AND BUCKETS'
pve_ceph_crush_rules:
- name: replicated_rule
type: osd # This is an example of how you can override a pre-existing rule
- name: ssd
class: ssd
type: osd
min-size: 2
max-size: 8
- name: hdd
class: hdd
type: host
# 2 Ceph pools for VM disks which will also be defined as Proxmox storages
# Using different CRUSH rules
pve_ceph_pools:
- name: ssd
pgs: 128
rule: ssd
application: rbd
storage: true
# This Ceph pool uses custom size/replication values
- name: hdd
pgs: 32
rule: hdd
application: rbd
storage: true
size: 2
min-size: 1
# This Ceph pool uses custom autoscale mode : "off" | "on" | "warn"> (default = "warn")
- name: vm-storage
pgs: 128
rule: replicated_rule
application: rbd
autoscale_mode: "on"
storage: true
pve_ceph_fs:
# A CephFS filesystem not defined as a Proxmox storage
- name: backup
pgs: 64
rule: hdd
storage: false
mountpoint: /srv/proxmox/backup
pve_ceph_network verwendet standardmäßig den Filter ansible.utils.ipaddr , bei dem die netaddr -Bibliothek von Ihrem Ansible -Controller installiert und verwendbar ist.
pve_ceph_nodes verwendet pve_group . Mit diesem Parameter können Sie angeben, welche Knoten Ceph installieren (z. B. wenn Sie CEPH nicht an allen Knoten installieren möchten).
pve_ceph_osds standardmäßig erstellt unverschlüsselte Ceph -Volumes. Um verschlüsselte Volumes zu verwenden, muss der encrypted Parameter pro Laufwerk auf true eingestellt werden.
Diese Rolle kann so konfiguriert werden, dass PCI -Geräte -Passthrough vom Proxmox -Host zu VMs ermöglicht werden. Diese Funktion ist standardmäßig nicht aktiviert, da nicht alle Motherboards und CPUs diese Funktion unterstützen. Um das Durchgang zu ermöglichen, muss die CPU der Geräte die Hardware-Virtualisierung (VT-D für Intel-basierte Systeme und AMD-V für AMD-basierte Systeme) unterstützen. Siehe Handbücher aller Komponenten, um festzustellen, ob diese Funktion unterstützt wird oder nicht. Die Benennung von Konventionen von Willen variieren, wird jedoch normalerweise als Iommu, VT-D oder AMD-V bezeichnet.
Durch Aktivieren dieser Funktion können spezielle Geräte (z. B. eine GPU- oder USB -Geräte) an die VMs weitergegeben werden. Neben dedizierten Geräten können verschiedene integrierte Geräte wie Intel oder AMDs integrierte GPUs auch an VMs weitergegeben werden.
Einige Geräte können die vermittelte Verwendung nutzen. Vermittelte Geräte können an mehrere VMs weitergegeben werden, um Ressourcen zu teilen, während sie dennoch vom Host -System verwendet werden können. Das Aufteilen von Geräten wird nicht immer unterstützt und sollte validiert werden, bevor Fehler durchgeführt werden, um Fehler zu verhindern. Weitere Informationen finden Sie im Handbuch des Geräts, das Sie durchgeben möchten, um festzustellen, ob das Gerät in der Lage ist, eine vermittelte Nutzung zu erhalten (derzeit unterstützt diese Rolle nur GVT-G; SR-IOV wird derzeit nicht unterstützt und muss nach Abschluss der Rolle manuell aktiviert werden).
Im Folgenden ist eine Beispielkonfiguration, die PCIe Passthrough ermöglicht:
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 ist erforderlich, um jede PCIe -Pass -Through -Funktionalität zu verwenden. Ohne dies fähig werden alle anderen PCIe -verwandten Felder nicht genutzt.
pve_iommu_passthrough_mode -Aktivierung des Iommu -Passthrough -Modus kann die Geräteleistung erhöhen. Durch die Aktivierung dieser Funktion können VMs die Standard-DMA-Übersetzung umgehen, die normalerweise vom Hypervisor durchgeführt wird. Stattdessen befragt VMS DMA direkt an das Hardware -Iommu.
pve_iommu_unsafe_interrupts muss aktiviert werden, damit PCI -Passpheough nicht unterstützt wird, wenn Ihr System das Interrupt -Remapping nicht unterstützt. Überprüfen Sie, ob das Gerät unter Verwendung von dmesg | grep 'remapping' das Interrupt -Remapping unterstützt dmesg | grep 'remapping' . Wenn Sie eine der folgenden Zeilen sehen:
Anschließend wird das System -Interrupt -Remapping unterstützt und Sie müssen keine unsicheren Interrupts aktivieren. Beachten Sie, dass Ihr System durch Aktivieren dieses Wertes instabil werden kann.
pve_mediated_devices_enabled ermöglicht GVT-G-Unterstützung für integrierte Geräte wie Intel IGPUs. Nicht alle Geräte unterstützen GVT-G, daher wird empfohlen, vorher mit Ihrem spezifischen Gerät nachzudenken, um sicherzustellen, dass es zulässig ist.
pve_pcie_ovmf_enabled ermöglicht GPU OVMF PCI Passthrough. Bei Verwendung von OVMF sollten Sie 'OVMF' als BIOS -Option für die VM anstelle von 'Seabios' innerhalb von Proxmox auswählen. In dieser Einstellung wird versucht, Geräte nach Möglichkeit von VGA-Schiedsgerichtsbarkeit zu deaktivieren.
pve_pci_device_ids ist eine Liste von Geräte- und Lieferanten -IDs, die vom Host an VMs weitergegeben werden sollen. Siehe Abschnitt 'GPU Passthrough' auf dem Proxmox -Wiki, um Ihr spezifisches Gerät und Ihre Anbieter -ID zu finden. Bei der Festlegung dieses Wertes muss für jedes neue Element im Array eine 'ID' angeben.
pve_vfio_blacklist_drivers ist eine Liste von Treibern, die vom Host ausgeschlossen/schwarzlistet werden sollen. Dies ist erforderlich, wenn Sie durch ein PCI -Gerät gehen, um zu verhindern, dass der Host das Gerät verwendet, bevor es einem VM zugeordnet werden kann. Bei der Festlegung dieses Wertes muss ein "Name" für jedes neue Element im Array angegeben werden.
pve_pcie_ignore_msrs verhindert einige Windows -Anwendungen wie GeForce Experience, Passmark -Leistungstest und Sisoftware Sandra, die VM zu stürzen. Dieser Wert ist nur erforderlich, wenn PCI -Geräte an Windows -basierte Systeme weitergegeben werden.
pve_pcie_report_msrs kann verwendet werden, um Protokollierungsnachrichten von MSRS -Warnungen zu aktivieren oder zu deaktivieren. Wenn Sie viele Warnmeldungen in Ihrem DMESG -Systemprotokoll sehen, kann dieser Wert verwendet werden, um MSRS -Warnungen zum Schweigen zu bringen.
Sie können metrische Server in Proxmox VE mithilfe der Rollenvariablen pve_metric_servers konfigurieren. Im Folgenden finden Sie eine Beispielkonfiguration für verschiedene Arten von metrischen Servern:
pve_metric_servers :
- id : influxdb1
port : 8086
server : influxdb.example.com
type : influxdb
protocol : http
organization : myorg
bucket : mybucket
token : mytoken
timeout : 30
max_body_size : 25000000
verify_certificate : true
- id : graphite1
port : 2003
server : graphite.example.com
type : graphite
protocol : tcp
path : mygraphitepath
mtu : 1500id : (Erforderlich) Eindeutige Kennung für den metrischen Server.port : (optional) Port des metrischen Servers. Standard ist 8089 .server : (Erforderlich) DNS -Name oder IP -Adresse des metrischen Servers.type : (optional) Art des metrischen Servers. Mögliche Werte: influxdb , graphite . Standard ist influxdb .protocol : (optional) Protokoll zum Senden von Metriken. Mögliche Werte: udp , tcp , http , https . Standard ist udp .disable : (optional) Deaktivieren Sie den metrischen Server. Standard ist false .organization : (optional) Organisationsname. Nur für InfluxDB mit der HTTP V2 -API verfügbar.bucket : (optional) Eimer -Name für InfluxDB. Nur nützlich mit der HTTP V2 -API oder kompatibel.token : (optional) InfluxDB -Zugangs -Token. Erforderlich nur bei Verwendung der HTTP V2 -API.path : (Optional) Graphit Root Path. Nur für Graphit erhältlich.api_path_prefix : (Optional) API -Pfad Präfix, das zwischen <host>:<port>/ und /api2/ eingefügt wurde. Nützlich, wenn der InfluxDB -Dienst hinter einem Reverse -Proxy läuft. Nur für InfluxDB mit der HTTP V2 -API verfügbar.timeout : (optional) Zeitüberschreitung in Sekunden. Nur für InfluxDB mit der HTTP V2 -API oder dem TCP -Socket Graphit erhältlich.max_body_size : (optional) Maximale Körpergröße in Bytes. Nur für InfluxDB mit der HTTP V2 -API verfügbar. Standard ist 25000000 .mtu : (optional) MTU für die UDP -Metrikübertragung.verify_certificate : (optional) Überprüfen Sie das SSL -Zertifikat. Nur für InfluxDB mit HTTPS verfügbar. Proxmox 8.2 führt Linux 6.8 ein, was in einigen Bereitstellungen Probleme verursachen kann. Um dies zu umgehen, können Sie die Kernelversion auf 6,5 festlegen, indem Sie die folgende Rollenvariable hinzufügen:
pve_default_kernel_version : 1.0.1 Dadurch wird ein Pin auf dem proxmox-default-kernel -Paket erstellt, das die von PVE vorgeschlagene Methode ist. Es kann später entfernt werden, indem diese Rollenvariable verunreinigt wird.
Fügen Sie diesen Abschnitt Ihrem ansible.cfg hinzu.
[ssh_connection]
ssh_args = -o ServerAliveInterval=20Referenzproblem
Wenn Sie neue Funktionen entwickeln oder etwas in dieser Rolle beheben, können Sie Ihre Änderungen mit Vagrant testen (derzeit wird nur libvirt unterstützt). Das Spielbuch finden Sie in tests/vagrant (achten Sie darauf, Gruppenvariablen nach Bedarf zu ändern). Testen Sie alle Änderungen in allen unterstützten Versionen von Debian (aktualisieren Sie die Vagrantfile lokal, um debian/bookworm64 , debian/bullseye64 oder debian/buster64 ) zu verwenden, bevor Sie eine PR einreichen.
Sie können auch einen APT-Caching-Proxy (z. B. apt-cacher-ng ) angeben und auf Port 3142 ausgeführt werden) mit der Umgebungsvariablen APT_CACHE_HOST um Paket-Downloads zu beschleunigen, wenn Sie eine lokale in Ihrer Umgebung ausführen. Das Vagarant Playbook erkennt, ob der Caching -Proxy verfügbar ist oder nicht, und verwenden es nur, wenn es aus Ihrem Netzwerk zugänglich ist. Sie können diese Variable in Ihrer Entwicklungsumgebung dauerhaft festlegen, wenn Sie es vorziehen.
Sie können beispielsweise Folgendes ausführen, um die ausführliche Ausgaben ausführlich zu zeigen, einen Caching -Proxy zu verwenden und die VMs zu halten, wenn Sie einen Fehler begegnen (damit Sie sie beheben können und/oder vagrant provision nach der Behebung ausführen können):
APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error
Musee Ullah (@lae, [email protected]) - Hauptentwickler
Fabien Brachere (@fbrachere) - Speicherkonfigurationsunterstützung
Gaudenz Steinlin (@gaundez) - CEPH -Unterstützung usw.
Richard Scott (@Zenntrix) - CEPH -Unterstützung, PVE 7.x -Unterstützung usw.
Thoralf rickert -wendt (@trickert76) - PVE 6.x -Unterstützung usw.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@snipercze)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@Lexxxel) - PVE 8.x Unterstützung usw.
Bruno Travouillon (@btravouillon) - UX -Verbesserungen
Tobias negd (@wu3rstle) - CEPH -Unterstützung
Pendagtp (@pendagtp) - CEPH -Unterstützung
John Marion (@jmariondev)
Foerkede (@foerkede) - ZFS -Speicherunterstützung
Guiffo Joel (@futuriste) - Poolkonfigurationsunterstützung
ADAM DELO (@OL3D) - PCIE Passthrough -Unterstützung Antoine Thys (@thystips) - Support für metrische Server
Vollständige Liste der Mitwirkenden
