Configuration de Foreman par Ansible

Ce rôle permet de provisionner un serveur Foreman ou Satellite avec une organisation et du contenu.

Ce rôle nécessite les collections Ansible suivantes pour fonctionner :

• 'theforeman.foreman' 3.4.0 ou supérieur
• 'ansible.utils' 2.6.0 ou supérieur
• 'ansible.posix' 1.4.0 ou supérieur

Testé avec Ansible 2.12 et supérieur.

Ce rôle prend en charge Foreman 3.2 / Katello 4.4 et supérieur ou Red Hat Satellite 6.11 et supérieur.

Autres exigences sur le contrôleur Ansible :

• python-netaddr (pour les tâches liées au sous-réseau)

Consultez l'inventaire et les playbooks d'exemple pour plus d'informations! Ou lisez mon article de blog.

Installation hors ligne de Satellite

Si vous souhaitez installer Satellite via l'ISO d'installation hors ligne, assurez-vous d'avoir également configuré les dépôts RHEL à partir d'une ISO d'installation ou d'un miroir.

Vues de contenu (CV), vues de contenu composite (COV) et publication

Lorsque ce rôle est utilisé pour créer de nouvelles vues de contenu et composites, la stratégie suivante est appliquée :

• Les vues de contenu sont créées avec le même nom que le produit qu'elles contiennent.
• Les dépôts nouvellement créés seront synchronisés après leur création (asynchroniquement).
• Les vues de contenu composite nouvellement créées seront promues dans tous les environnements de cycle de vie de l'organisation.

L'idée derrière cela est que les COV sont les seules choses associées aux clients. Les CV de base sont uniquement présentes dans la bibliothèque et ne devraient pas être promues vers un autre environnement.

Toutes les COV créées ont la publication automatique activée et des exemples de playbooks pour "tagger" une nouvelle version et la publier sont fournis.

Découverte d'hôtes

Pour la découverte d'hôtes, enregistrez les enregistrements suivants dans le DNS pour permettre à FDI de se rapporter au bon serveur :

• Pour les serveurs Foreman :

_x-foreman._tcp.dev.example.com 600 IN SRV 0 5 443 foreman.dev.example.com

• Pour les Smart Proxies de Foreman :

_x-foreman._tcp.dev.example.com 600 IN SRV 0 5 8443 fm-proxy.dev.example.com

Si votre environnement ne fonctionne pas avec ces enregistrements, vous pouvez également définir foreman_discovery_image_autodetect sur false. Cela utilisera les paramètres par défaut de Foreman. Ceux-ci peuvent être perturbés lors de l'utilisation de Smart Proxies.

Installation de Smart Proxies

Certains paramètres utilisés pour les Smart Proxies sont partagés avec le serveur Foreman. Pour éviter les paramètres en double, l'inventaire suivant est suggéré :

[foreman]
foreman.infra.example.com

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

[foreman_infra]

[foreman_infra:children]
foreman
foreman_proxies

Ensuite, mettez tous les paramètres globaux pour Foreman dans les group_vars pour foreman_infra, qui seront alors disponibles pour le serveur et les proxies. Vous pouvez ensuite créer des host_vars pour chaque système Foreman (serveur ou proxies) contenant les paramètres spécifiques à l'instance.

Limitations, bugs et solutions

Parfois, l'installateur ne parvient pas à terminer la configuration des services Foreman. Les tâches Ansible ont été configurées (sauf si vous exécutez une version de Foreman/Satellite qui ne prend pas en charge --detailed-exitcodes) pour déclencher cela.

Lorsqu'un problème survient, vous pouvez suivre les étapes suivantes pour localiser le problème :

• Exécutez foreman-installer manuellement, aucun argument n'est requis. Cela donnera une direction générale où chercher.
• Vérifiez les journaux dans /var/log/foreman-installer.
• Redémarrez les services Foreman, cela 'réinitialisera' parfois les choses après quoi Foreman réussira à terminer l'installation.

Pour des choses spécifiques, voyez ci-dessous.

Informations sur le déploiement, la découverte et UEFI vs. BIOS vs. iPXE

Les tests ont montré que divers paramètres peuvent affecter la capacité d'un hôte à démarrer depuis le réseau.

Nous avons testé les configurations suivantes :

• Découverte :

  • KVM

    • BIOS : fonctionne avec les paramètres par défaut configurés par ce rôle. Peut également être utilisé avec iPXE.
    • UEFI : un peu incertain, vous pourriez rencontrer des problèmes pour essayer de charger le FDI depuis PXE car TFTP va expirer. iPXE fonctionne bien.

  • HyperV :

    • Gen1 (BIOS) : fonctionne avec les paramètres par défaut configurés. Peut également être utilisé avec iPXE.
    • Gen2 (UEFI) : nécessite iPXE, vous devez désactiver SecureBoot.

• Déploiement du système d'exploitation :

  • KVM

    • BIOS : fonctionne avec les paramètres par défaut configurés par ce rôle. Peut également être utilisé avec iPXE.
    • UEFI : utilisez pxe_loader: 'Grub2 UEFI' avec les paramètres par défaut de ce rôle. Peut également être utilisé avec iPXE.

  • HyperV :

    • Gen1 (BIOS) : fonctionne avec les paramètres par défaut configurés par ce rôle jusqu'à CentOS7, CentOS8 et supérieur nécessitent Gen2.
    • Gen2 (UEFI) : nécessite iPXE, vous devez désactiver SecureBoot.

• Démarrer en local

  • KVM

    • BIOS : fonctionne bien. Peut également être utilisé avec iPXE.
    • UEFI : utilisez pxe_loader: 'Grub2 UEFI' avec les paramètres par défaut de ce rôle. iPXE peut se bloquer dans le menu système UEFI : https://community.theforeman.org/t/ipxe-does-not-boot-local-hard-disk-on-uefi/21437

  • HyperV :

    • Gen1 : fonctionne bien.
    • Gen2 : fonctionne bien, vous devez désactiver SecureBoot.

Pour activer iPXE, définissez foreman_deploy_ipxe: true et utilisez pxe_loader: 'None' pour vos systèmes d'exploitation.

Bug : Erreur lors de la création de systèmes d'exploitation

Supprimez tous les systèmes d'exploitation de Hôtes -> Systèmes d'exploitation (vous ne pouvez pas supprimer celui où se trouve le serveur foreman).

Limitation : Les ressources avec des mots de passe changent toujours

Comme les modules Foreman ne peuvent pas voir le mot de passe actuel défini pour les champs de mot de passe, ceux-ci ne peuvent pas être comparés.

Par conséquent, cela change toujours (systèmes d'exploitation, informations d'identification du dépôt en amont, etc.). Cela peut entraîner des actions supplémentaires en fonction de la ressource modifiée. Cela n'a pas posé de problèmes jusqu'à présent, mais l'exécution des playbooks peut prendre un peu plus de temps en raison de cela.

Limitation : Les groupes d'hôtes utilisent toujours la première table de partition dans la liste

Comme les groupes d'hôtes sont le résultat combiné des clés d'activation, des systèmes d'exploitation et des cycles de vie, le niveau de configurabilité est limité. Au moment de l'écriture, le rôle configurera tous les groupes d'hôtes avec la même table de partition.

Un exemple pour un déploiement avec une table de partition différente est montré ci-dessous :

# La table de partition ci-dessous est définie pour ignorer
# tous les disques sauf le premier pour le partitionnement automatique.
# Veuillez noter qu'elle ne détecte pas automatiquement les types de disque (vd ou sd)
# donc vous devrez coder en dur le disque à utiliser.
foreman_partition_tables:
  - name: 'Kickstart default first disk only'
    os_family: 'Redhat'
    layout: |
      <%#
      kind: ptable
      name: Kickstart default first disk only
      model: Ptable
      description: Géré par Ansible, vos modifications seront perdues
      %>
      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'