thulium_drake.foreman

Überblick Versionen Einblicke

Foreman-Konfiguration mit Ansible

Diese Rolle bietet ein Mittel, um einen Foreman- oder Satellite-Server mit einer Organisation und einigen Inhalten bereitzustellen.

Diese Rolle benötigt die folgenden Ansible Collections, um zu funktionieren:

  • 'theforeman.foreman' 3.4.0 oder höher
  • 'ansible.utils' 2.6.0 oder höher
  • 'ansible.posix' 1.4.0 oder höher

Getestet mit Ansible 2.12 und höher.

Diese Rolle unterstützt Foreman 3.2 / Katello 4.4 und aufwärts oder Red Hat Satellite 6.11 und aufwärts.

Weitere Anforderungen an den Ansible-Controller:

  • python-netaddr (für subnetzbezogene Aufgaben)

Schau dir die beispielhaften Bestände und Playbooks zur Orientierung an! Oder lies meinen Blogbeitrag.

Offline-Installation von Satellite

Wenn du Satellite über das Offline-Installations-ISO installieren möchtest, stelle sicher, dass du RHEL-Repos von einem Installations-ISO oder Spiegel konfiguriert hast.

Inhaltsansichten (CV), zusammengesetzte Inhaltsansichten (COV) und Veröffentlichung

Wenn diese Rolle verwendet wird, um neue Inhaltsansichten und Komposite zu erstellen, wird die folgende Strategie angewendet:

  • Inhaltsansichten werden mit dem gleichen Namen wie das Produkt erstellt, das sie enthalten.
  • Neu erstellte Repositories werden nach der Erstellung synchronisiert (asynchron).
  • Neu erstellte zusammengesetzte Inhaltsansichten werden in alle Lebenszyklusumgebungen der Organisation beworben.

Die Idee dahinter ist, dass COVs die einzigen sind, die mit Clients verbunden sind. Die Basis-CVs befinden sich nur in der Bibliothek und sollten nicht in andere Umgebungen beworben werden.

Alle erstellten COVs haben auto_publish aktiviert, und es werden Beispiel-Playbooks bereitgestellt, um eine neue Version zu "taggen" und zu veröffentlichen.

Host-Erkennung

Für die Host-Erkennung registriere die folgenden Einträge im DNS, damit die FDI an den richtigen Server berichten kann:

  • Für Foreman-Server:
_x-foreman._tcp.dev.example.com 600 IN  SRV 0 5 443 foreman.dev.example.com
  • Für Foreman Smart Proxies:
_x-foreman._tcp.dev.example.com 600 IN  SRV 0 5 8443 fm-proxy.dev.example.com

Wenn deine Umgebung nicht mit diesen Einträgen funktioniert, kannst du auch foreman_discovery_image_autodetect auf false setzen. Dadurch werden die Standardeinstellungen für Foreman verwendet. Diese könnten bei Verwendung von Smart Proxies fehlerhaft sein.

Installation von Smart Proxies

Einige der Einstellungen, die für Smart Proxies verwendet werden, sind mit dem Foreman-Server geteilt. Um doppelte Einstellungen zu vermeiden, wird der folgende Bestand vorgeschlagen:

[foreman]
foreman.infra.example.com

[foreman_proxies]
fm-proxy.dev.example.com

[foreman_infra]

[foreman_infra:children]
foreman
foreman_proxies

Dann lege alle globalen Einstellungen für Foreman in die group_vars für foreman_infra, die dann sowohl dem Server als auch den Proxies zur Verfügung stehen. Du kannst dann host_vars für jedes Foreman-System (Server oder Proxies) erstellen, die die instanzspezifischen Einstellungen enthalten.

Einschränkungen, Fehler und Lösungen

Manchmal kann der Installer die Konfiguration der Foreman-Dienste nicht erfolgreich abschließen. Die Ansible-Aufgaben wurden so konfiguriert, dass sie (es sei denn, du verwendest eine Version von Foreman/Satellite, die --detailed-exitcodes nicht unterstützt) darauf reagieren.

Wenn ein Problem auftritt, kannst du folgende Schritte befolgen, um das Problem einzugrenzen:

  • Führe foreman-installer manuell aus, es sind keine Argumente erforderlich. Dies gibt eine allgemeine Richtung vor, wo du suchen kannst.
  • Überprüfe die Protokolle in /var/log/foreman-installer.
  • Starte die Foreman-Dienste neu. Dies kann manchmal Dinge "zurücksetzen", nach dem Foreman den Installer erfolgreich abschließen kann.

Für spezifische Dinge sieh dir die folgenden Punkte an.

Informationen zu Bereitstellung, Entdeckung und UEFI vs. BIOS vs. iPXE

Tests haben gezeigt, dass verschiedene Einstellungen Einfluss darauf haben können, ob ein Host über das Netzwerk booten kann.

Wir haben die folgenden Setups getestet:

  • Entdeckung:

    • KVM

      • BIOS: funktioniert mit den von dieser Rolle konfigurierten Standardeinstellungen. Kann auch mit iPXE verwendet werden.
      • UEFI: ist ein bisschen problematisch; du könntest auf einige Probleme stoßen, wenn du versuchst, die FDI von PXE zu laden, da TFTP abläuft. iPXE funktioniert einwandfrei.

    • HyperV:

      • Gen1 (BIOS): funktioniert mit den konfigurierten Standardeinstellungen. Kann auch mit iPXE verwendet werden.
      • Gen2 (UEFI): benötigt iPXE, du musst SecureBoot deaktivieren.

  • OS-Bereitstellung:

    • KVM

      • BIOS: funktioniert mit den von dieser Rolle konfigurierten Standardeinstellungen. Kann auch mit iPXE verwendet werden.
      • UEFI: verwende pxe_loader: 'Grub2 UEFI' mit den von dieser Rolle konfigurierten Standardeinstellungen. Kann auch mit iPXE verwendet werden.

    • HyperV:

      • Gen1 (BIOS): funktioniert mit den von dieser Rolle konfigurierten Standardeinstellungen bis CentOS7, CentOS8 und höher benötigt Gen2.
      • Gen2 (UEFI): benötigt iPXE, du musst SecureBoot deaktivieren.

  • Lokales Booten

Um iPXE zu aktivieren, setze foreman_deploy_ipxe: true und verwende pxe_loader: 'None' für deine Betriebssysteme.

Fehler: Fehler beim Erstellen von Betriebssystemen

Entferne alle Betriebssysteme aus Hosts -> Betriebssysteme (du kannst das, in dem sich der Foreman-Server befindet, nicht löschen).

Einschränkung: Ressourcen mit Passwörtern ändern sich immer

Da die Foreman-Module das aktuelle Passwortfeld für Passwortfelder nicht sehen können, können diese nicht verglichen werden.

Daher ändern sich diese immer (Betriebssysteme, Anmeldedaten für upstream-Repos usw.). Dies kann zusätzliche Aktionen je nach geändertem Ressourcentyp verursachen. Bisher hat dies jedoch keine Probleme verursacht, könnte die Ausführung des Plays jedoch etwas länger dauern.

Einschränkung: Hostgruppen verwenden immer die erste Partitionstabelle in der Liste

Da die Hostgruppen das kombinierte Ergebnis von Aktivierungs-Schlüsseln, Betriebssystemen und Lebenszyklen sind, ist die Konfigurierbarkeit begrenzt. Zum Zeitpunkt des Schreibens wird die Rolle alle Hostgruppen mit der gleichen Partitionstabelle konfigurieren.

Ein Beispiel für eine Bereitstellung mit einer anderen Partitionstabelle ist unten dargestellt:

# Die untenstehende Partitionstabelle ist so eingestellt, dass sie
# alle Festplatten außer der ersten für die automatische Partitionierung ignoriert.
# Bitte beachte, dass sie die Festplattentypen (vd oder sd) nicht automatisch erkennt,
# sodass du die zu verwendende Festplatte hardcodieren musst.
foreman_partition_tables:
  - name: 'Kickstart default first disk only'
    os_family: 'Redhat'
    layout: |
      <%#
      kind: ptable
      name: Kickstart default first disk only
      model: Ptable
      description: Verwaltet von Ansible, deine Änderungen gehen verloren
      %>
      zerombr
      clearpart --all --initlabel
      ignoredisk --use-only=sda
      autopart <%= host_param('autopart_options') %>

foreman_operating_systems:
  - name: 'CentOS'
    major_version: 7
    arch:
     - 'x86_64'
    os_family: 'Redhat'
    kickstart: true
    kickstart_repo: 'CentOS7-Base'
    partitions:
      - 'Kickstart default first disk only'
    root_pass: 'some_password'
    parameters:
      - name: 'autopart_options'
        value: '--nohome'
Über das Projekt

Ansible toolkit for Foreman

role foreman satellite katello lifecycle
Installieren
ansible-galaxy install thulium_drake.foreman
GitHub Repository
10 Sterne
0 Forks
0 Offene Issues
Lizenz
gpl-3.0
Downloads
1.4k
Besitzer