Composer, installer et gérer des images RHEL for Edge

Red Hat Enterprise Linux 9

Créer, déployer et gérer des systèmes Edge avec Red Hat Enterprise Linux 9

Red Hat Customer Content Services

Résumé

Utilisez l'outil de création d'images pour composer des images RHEL (rpm-ostree) personnalisées et optimisées pour Edge. Ensuite, vous pouvez installer à distance, gérer en toute sécurité et mettre à l'échelle les déploiements des images sur les serveurs Edge.

Rendre l'open source plus inclusif

Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.

Fournir un retour d'information sur la documentation de Red Hat

Nous apprécions vos commentaires sur notre documentation. Faites-nous savoir comment nous pouvons l'améliorer.

Soumettre des commentaires sur des passages spécifiques

  1. Consultez la documentation au format Multi-page HTML et assurez-vous que le bouton Feedback apparaît dans le coin supérieur droit après le chargement complet de la page.
  2. Utilisez votre curseur pour mettre en évidence la partie du texte que vous souhaitez commenter.
  3. Cliquez sur le bouton Add Feedback qui apparaît près du texte en surbrillance.
  4. Ajoutez vos commentaires et cliquez sur Submit.

Soumettre des commentaires via Bugzilla (compte requis)

  1. Connectez-vous au site Web de Bugzilla.
  2. Sélectionnez la version correcte dans le menu Version.
  3. Saisissez un titre descriptif dans le champ Summary.
  4. Saisissez votre suggestion d'amélioration dans le champ Description. Incluez des liens vers les parties pertinentes de la documentation.
  5. Cliquez sur Submit Bug.

Chapitre 1. Présentation des images RHEL for Edge

Une image RHEL for Edge est une image rpm-ostree qui inclut des paquets système pour installer RHEL à distance sur des serveurs Edge.

Les paquets du système comprennent :

  • Base OS paquet
  • Podman, le moteur de conteneurs
  • Contenu supplémentaire du RPM

Contrairement aux images RHEL, RHEL for Edge est un système d'exploitation immuable, c'est-à-dire qu'il contient un répertoire racine read-only présentant les caractéristiques suivantes :

  • Les paquets sont isolés du répertoire racine
  • L'installation de paquets crée des couches qui facilitent le retour aux versions précédentes
  • Mises à jour efficaces pour les environnements déconnectés
  • Prise en charge de plusieurs branches et dépôts de systèmes d'exploitation
  • Système d'emballage hybride rpm-ostree

Vous pouvez déployer une image RHEL for Edge sur des serveurs Bare Metal, Appliance et Edge.

Vous pouvez composer des images RHEL for Edge personnalisées à l'aide de l'outil de création d'images. Vous pouvez également créer des images RHEL for Edge en accédant à l'application de gestion de périphérie dans la plateforme Red Hat Hybrid Cloud Console et configurer la gestion automatisée.

L'application de gestion de périphérie simplifie l'approvisionnement et l'enregistrement de vos images. Pour en savoir plus sur la gestion de périphérie, consultez la documentation Créer des images RHEL for Edge et configurer la gestion automatisée.

Avertissement

L'utilisation d'images personnalisées RHEL for Edge créées à l'aide des artefacts de la version sur site image builder n'est pas prise en charge dans l'application de gestion de périphérie. Voir Prise en charge de la gestion Edge.

Avec une image RHEL for Edge, vous pouvez obtenir les résultats suivants :

Key features

1.1. RHEL pour l'architecture Edge

Actuellement, vous pouvez déployer des images RHEL for Edge sur des systèmes AMD et Intel 64 bits.

Note

Actuellement, RHEL for Edge ne prend pas en charge les systèmes ARM.

1.2. Comment composer et déployer une image RHEL for Edge ?

La composition et le déploiement d'une image RHEL for Edge comportent deux phases :

  1. Composer une image RHEL rpm-ostree à l'aide de l'outil de construction d'images. Vous pouvez accéder à l'outil de construction d'images via une interface de ligne de commande dans l'outil composer-cli, ou utiliser une interface utilisateur graphique dans la console web RHEL.
  2. Déploiement de l'image à l'aide du programme d'installation RHEL.

Lors de la composition d'une image RHEL for Edge, vous pouvez sélectionner l'un des types d'image suivants. La composition des différentes images RHEL for Edge peut nécessiter ou non un accès au réseau. Voir le tableau :

Tableau 1.1. Type d'images RHEL for Edge

Type d'imageDescriptionConvient aux déploiements en réseauConvient aux déploiements non basés sur un réseau

RHEL for Edge Commit (.tar)

L'image Commit n'est pas directement amorçable, même si elle contient un système d'exploitation complet. Pour démarrer le type d'image Commit, vous devez le déployer.

Oui

Non

RHEL for Edge Container (.tar)

Le conteneur crée un commit OSTree et l'intègre dans un conteneur OCI avec un serveur web. Lorsque le conteneur est démarré, le serveur web sert le commit en tant que dépôt OSTree.

Non

Oui

RHEL for Edge Installer (.iso)

Le type d'image RHEL for Edge Installer extrait le commit du conteneur en cours d'exécution et crée une ISO de démarrage installable avec un fichier Kickstart configuré pour utiliser le commit OSTree intégré.

Non

Oui

RHEL for Edge Raw image (.raw.xz)

Les images brutes compressées consistent en un fichier qui contient une disposition de partition avec un engagement OSTree déployé existant. Vous pouvez flasher les images brutes RHEL sur un disque dur ou démarrer sur une machine virtuelle.

Oui

Oui

RHEL for Edge Simplified Installer (.iso)

Le type d'image Simplified Installer extrait le commit d'un conteneur en cours d'exécution et crée une ISO de démarrage installable avec un fichier Kickstart configuré pour utiliser le commit OSTree intégré.

Oui

Oui

Les types d'images varient en termes de contenu et conviennent donc à différents types d'environnements de déploiement.

Ressources supplémentaires

1.3. Déploiements hors réseau

Utilisez le générateur d'images pour créer des images RHEL rpm-ostree flexibles répondant à vos besoins, puis utilisez Anaconda pour les déployer dans votre environnement.

Vous pouvez accéder à image builder via une interface de ligne de commande dans l'outil composer-cli, ou utiliser une interface utilisateur graphique dans la console web RHEL.

La composition et le déploiement d'une image RHEL for Edge dans les déploiements non basés sur le réseau impliquent les étapes de haut niveau suivantes :

  1. Installer et enregistrer un système RHEL
  2. Installer le constructeur d'images
  3. À l'aide de l'outil de création d'images, créez un modèle avec des personnalisations pour l'image RHEL for Edge Container
  4. Importer le plan RHEL for Edge dans le constructeur d'images
  5. Créer une image RHEL for Edge intégrée dans un conteneur OCI avec un serveur web prêt à déployer le commit en tant que dépôt OSTree
  6. Télécharger le fichier image RHEL for Edge Container
  7. Déployer le conteneur desservant un référentiel à l'aide de la commande RHEL for Edge Container
  8. À l'aide de l'outil de création d'images, créez un autre modèle pour RHEL pour l'image Edge Installer
  9. Créer une image RHEL for Edge Installer configurée pour extraire le commit du conteneur en cours d'exécution intégré à l'image RHEL for Edge Container
  10. Télécharger l'image du programme d'installation de RHEL for Edge
  11. Exécuter l'installation

Le diagramme suivant représente le flux de travail du déploiement de l'image RHEL for Edge hors réseau :

Figure 1.1. Déploiement de RHEL for Edge dans un environnement hors réseau

RHEL for Edge non-network deployment workflow

1.4. Déploiements en réseau

Utilisez image builder pour créer des images RHEL rpm-ostree flexibles répondant à vos besoins, puis utilisez Anaconda pour les déployer dans votre environnement. image builder identifie automatiquement les détails de votre configuration de déploiement et génère la sortie de l'image sous forme de fichier edge-commit sous forme de fichier .tar.

Vous pouvez accéder à image builder via une interface de ligne de commande dans l'outil composer-cli, ou utiliser une interface utilisateur graphique dans la console web RHEL.

Vous pouvez composer et déployer l'image RHEL for Edge en effectuant les étapes de haut niveau suivantes :

  1. Installer et enregistrer un système RHEL
  2. Installer le constructeur d'images
  3. À l'aide de l'outil de création d'images, créez une image RHEL for Edge
  4. Importer le plan RHEL for Edge dans le constructeur d'images
  5. Créer une image RHEL for Edge Commit (.tar)
  6. Télécharger le fichier image RHEL for Edge
  7. Mise en place d'un serveur web
  8. Créer un nouveau plan pour un installateur RHEL for Edge (.iso)
  9. Créer l'image RHEL for Edge Installer (.iso), en pointant vers le contenu OSTree de l'artefact RHEL for Edge Commit (.tar)
  10. Téléchargez l'image ISO du programme d'installation de RHEL for Edge que vous avez créée
  11. Démarrer l'appareil périphérique à l'aide de l'image ISO RHEL for Edge Installer

Le diagramme suivant représente le processus de déploiement de l'image réseau RHEL for Edge :

Figure 1.2. Déploiement de RHEL for Edge dans un environnement de base réseau

RHEL for Edge network deployment workflow

1.5. Différence entre les images RHEL RPM et les images RHEL for Edge

Vous pouvez créer des images système RHEL au format RPM traditionnel basé sur les paquets, ainsi que des images RHEL for Edge (rpm-ostree).

Vous pouvez utiliser les RPM traditionnels basés sur les packages pour déployer RHEL sur des centres de données traditionnels. Cependant, avec les images RHEL for Edge, vous pouvez déployer RHEL sur des serveurs autres que les centres de données traditionnels. Ces serveurs comprennent des systèmes où le traitement de grandes quantités de données est effectué au plus près de la source où les données sont générées : les serveurs Edge.

Les images RHEL for Edge (rpm-ostree) ne sont pas des gestionnaires de paquets. Elles ne prennent en charge que les arborescences complètes du système de fichiers amorçable, et non les fichiers individuels. Ces images ne contiennent pas d'informations sur les fichiers individuels, telles que la manière dont ils ont été générés ou toute autre information relative à leur origine.

Les images rpm-ostree nécessitent un mécanisme distinct, le gestionnaire de paquets, pour installer des applications supplémentaires dans le répertoire /var. Ainsi, l'image rpm-ostree conserve le système d'exploitation inchangé, tout en maintenant l'état des répertoires /var et /etc. Les mises à jour atomiques permettent des retours en arrière et une mise en scène des mises à jour en arrière-plan.

Reportez-vous au tableau suivant pour savoir en quoi les images RHEL for Edge diffèrent des images RHEL RPM basées sur des packages.

Tableau 1.2. Différence entre les images RHEL RPM et les images RHEL for Edge

Principales caractéristiques

Image RHEL RPM

Image RHEL for Edge

OS assembly

Vous pouvez assembler les paquets localement pour former une image.

Les paquets sont assemblés dans un ostree que vous pouvez installer sur un système.

OS updates

Vous pouvez utiliser dnf update pour appliquer les mises à jour disponibles à partir des dépôts activés.

Vous pouvez utiliser rpm-ostree upgrade pour mettre en place une mise à jour si un nouveau commit est disponible dans le remote ostree à l'adresse /etc/ostree/remotes.d/. La mise à jour prend effet au redémarrage du système.

Repository

Le paquet contient des référentiels DNF

Le paquet contient le dépôt à distance Ostree

User access permissions

Lire l'écriture

Lecture seule (/usr)

Data persistence

Vous pouvez monter l'image sur n'importe quel point de montage autre que tmpfs

/etc & /var sont en lecture-écriture et comprennent des données persistantes.

Chapitre 2. Configuration du constructeur d'images

Utilisez image builder pour créer vos images RHEL for Edge personnalisées. Après avoir installé image builder sur un système RHEL, image builder est disponible en tant qu'application dans la console web RHEL. Vous pouvez également accéder à image builder via une interface de ligne de commande dans l'outil composer-cli.

Note

Il est recommandé d'installer le constructeur d'images sur une machine virtuelle.

Dans l'environnement où vous souhaitez installer le constructeur d'images, assurez-vous d'abord que la configuration requise est respectée, puis installez le constructeur d'images.

2.1. Configuration requise pour le constructeur d'images

L'environnement dans lequel s'exécute le constructeur d'images, par exemple une machine virtuelle, doit répondre aux exigences énumérées dans le tableau suivant.

Tableau 2.1. Configuration requise pour le constructeur d'images

Paramètres

Valeur minimale requise

Type de système

Une machine virtuelle dédiée

Processeur

2 cœurs

Mémoire

4 GiB

Espace disque

20 GiB

Privilèges d'accès

Niveau administrateur (root)

Réseau

Connectivité à l'internet

Note

L'espace disque requis de 20 GiB est suffisant pour installer et exécuter le constructeur d'images dans l'hôte. Pour construire et déployer des builds d'images, vous devez allouer de l'espace disque dédié supplémentaire.

2.2. Installation du constructeur d'images

Pour installer le générateur d'images sur une machine virtuelle dédiée, procédez comme suit :

Conditions préalables

  • La machine virtuelle est créée et mise sous tension.
  • Vous avez installé RHEL et vous avez souscrit à RHSM ou Red Hat Satellite.

Procédure

  1. Installez les paquets suivants sur la machine virtuelle.

    • osbuild-composer
    • composer-cli
    • cockpit-compositeur
    • bash-complétion
    • firewalld
    # dnf install osbuild-composer composer-cli cockpit-composer bash-completion firewalld

    Image builder est installé en tant qu'application dans la console web RHEL.

  2. Redémarrer la machine virtuelle
  3. Configurez le pare-feu du système pour autoriser l'accès à la console web :

    # firewall-cmd --add-service=cockpit && firewall-cmd --add-service=cockpit --permanent
  4. Activer le constructeur d'images.

    # systemctl enable osbuild-composer.socket cockpit.socket --now

    Les services osbuild-composer et cockpit démarrent automatiquement lors du premier accès.

  5. Charger le script de configuration de l'interpréteur de commandes pour que la fonction d'autocomplétion de la commande composer-cli fonctionne immédiatement sans redémarrage :

    $ source /etc/bash_completion.d/composer-cli

Ressources supplémentaires

Chapitre 3. Gestion des référentiels de constructeurs d'images

3.1. Dépôts par défaut du constructeur d'images

Le back-end osbuild-composer n'hérite pas des référentiels système situés dans le répertoire /etc/yum.repos.d/. Au lieu de cela, il dispose de son propre ensemble de dépôts officiels définis dans le répertoire /usr/share/osbuild-composer/repositories. Cela inclut le dépôt officiel Red Hat, qui contient les RPMs du système de base pour installer des logiciels supplémentaires ou mettre à jour des programmes déjà installés vers des versions plus récentes. Si vous souhaitez remplacer les référentiels officiels, vous devez définir des dérogations dans le répertoire /etc/osbuild-composer/repositories. Ce répertoire est destiné aux dérogations définies par l'utilisateur et les fichiers qui s'y trouvent sont prioritaires sur ceux du répertoire /usr.

Les fichiers de configuration n'ont pas le format habituel des référentiels DNF, que l'on connaît grâce aux fichiers de /etc/yum.repos.d/. Il s'agit plutôt de simples fichiers JSON.

3.2. Remplacer un référentiel système

Vous pouvez configurer un remplacement de référentiel pour le constructeur d'images dans le répertoire /etc/osbuild-composer/repositories en suivant les étapes suivantes.

Conditions préalables

  • Vous disposez d'un référentiel personnalisé accessible depuis le système hôte

Procédure

  1. Créez un répertoire dans lequel vous souhaitez stocker vos dérogations au référentiel :

    $ sudo mkdir -p /etc/osbuild-composer/repositories
  2. Vous pouvez créer votre propre structure de fichier JSON.
  3. Créez un fichier JSON, en utilisant un nom correspondant à votre version de RHEL. Vous pouvez également copier le fichier correspondant à votre distribution à partir de /usr/share/osbuild-composer/ et en modifier le contenu.

    Pour RHEL 9, utilisez /etc/osbuild-composer/repositories/rhel-92.json.

  4. Ajoutez la structure suivante à votre fichier JSON, par exemple :

    {
        "<ARCH>": [
            {
                "name": "baseos",
                "baseurl": "http://mirror.example.com/composes/released/RHEL-9/9.0/BaseOS/x86_64/os/",
                "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n (…​)",
                "check_gpg": true,
                "metadata_expire": ""
            }
        ]
    }

    Ne spécifiez qu'un seul des attributs suivants :

    • baseurl - chaîne de caractères : URL de base du référentiel.
    • metalink - string : URL d'un fichier metalink contenant une liste de dépôts miroirs valides.
    • mirrorlist - string : URL d'un fichier mirrorlist contenant une liste de dépôts miroirs valides

      Les autres champs sont facultatifs.

      1. Vous pouvez également copier le fichier JSON pour votre distribution.

        1. Copiez le fichier du référentiel dans le répertoire que vous avez créé. Dans la commande suivante, remplacez rhel-version.json par votre version de RHEL, par exemple : rhel-9.json.

          $  cp /usr/share/osbuild-composer/repositories/rhel-version.json /etc/osbuild-composer/repositories/
  5. À l'aide d'un éditeur de texte, modifiez les chemins d'accès baseurl dans le fichier rhel-9.json et enregistrez-le. Par exemple :

    $ vi /etc/osbuild-composer/repositories/rhel-version.json
  6. Redémarrer le site osbuild-composer.service:

    $ sudo systemctl restart osbuild-composer.service

Vérification

  • Vérifier que le référentiel pointe vers les bonnes URL :

    $ cat /etc/yum.repos.d/redhat.repo

    Vous pouvez voir que le référentiel pointe vers les bonnes URLs qui sont copiées depuis le fichier /etc/yum.repos.d/redhat.repo.

3.3. Remplacer un référentiel système par un support pour les abonnements

Le service osbuild-composer peut utiliser des abonnements système définis dans le fichier /etc/yum.repos.d/redhat.repo. Pour utiliser un abonnement système dans osbuild-composer, définissez une surcharge de référentiel qui a :

  • Le même baseurl que le référentiel défini dans /etc/yum.repos.d/redhat.repo.
  • La valeur de ”rhsm”: true définie dans l'objet JSON.

Conditions préalables

Procédure

  1. Obtenez le baseurl à partir du fichier /etc/yum.repos.d/redhat.repo:

    # cat /etc/yum.repos.d/redhat.repo
    [AppStream]
    name = AppStream mirror example
    baseurl = https://mirror.example.com/RHEL-9/9.0/AppStream/x86_64/os/
    enabled = 1
    gpgcheck = 0
    sslverify = 1
    sslcacert = /etc/pki/ca1/ca.crt
    sslclientkey = /etc/pki/ca1/client.key
    sslclientcert = /etc/pki/ca1/client.crt
    metadata_expire = 86400
    enabled_metadata = 0
  2. Configurez le référentiel pour qu'il utilise le même baseurl et attribuez la valeur true à rhsm:

    {
        "x86_64": [
            {
                "name": "AppStream mirror example",
                "baseurl": "https://mirror.example.com/RHEL-9/9.0/AppStream/x86_64/os/",
                "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n (…​)",
                "check_gpg": true,
                "rhsm": true
            }
        ]
    }
    Note

    osbuild-composer n'utilise pas automatiquement les référentiels définis à l'adresse /etc/yum.repos.d/. Vous devez les spécifier manuellement, soit en tant que remplacement du référentiel système, soit en tant que source supplémentaire à l'aide de composer-cli. Les dérogations au référentiel système sont généralement utilisées pour les référentiels "BaseOS" et "AppStream", tandis que les sources composer-cli sont utilisées pour tous les autres référentiels.

Par conséquent, le constructeur d'images lit le fichier /etc/yum.repos.d/redhat.repo à partir du système hôte et l'utilise comme source d'abonnements.

Chapitre 4. Composition d'une image RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL

Utiliser le constructeur d'images pour créer une image RHEL for Edge personnalisée (OSTree commit).

Pour accéder au constructeur d'images et créer votre image RHEL for Edge personnalisée, vous pouvez utiliser l'interface de la console web RHEL ou l'interface de ligne de commande.

Vous pouvez composer des images RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL en effectuant les étapes de haut niveau suivantes :

  1. Accéder au constructeur d'images dans la console web RHEL
  2. Créer un schéma directeur pour l'image RHEL for Edge.
  3. Créez une image RHEL for Edge. Vous pouvez créer les images suivantes :

    • Image RHEL for Edge Commit.
    • RHEL for Edge Container image.
    • RHEL for Edge Installer image.
  4. Télécharger l'image RHEL for Edge

4.1. Accès au constructeur d'images dans la console web RHEL

Pour accéder au constructeur d'images dans la console web RHEL, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez installé un système RHEL.
  • Vous disposez de droits d'administration sur le système.
  • Vous avez abonné le système RHEL à Red Hat Subscription Manager (RHSM) ou à Red Hat Satellite Server.
  • Le système est sous tension et accessible via le réseau.
  • Vous avez installé image builder sur le système.

Procédure

  1. Sur votre système RHEL, accédez à https://localhost:9090/ dans un navigateur web.
  2. Pour plus d'informations sur l'accès à distance au constructeur d'images, voir le document Gestion des systèmes à l'aide de la console Web RHEL 9.
  3. Connectez-vous à la console web en utilisant un compte d'utilisateur administratif.
  4. Dans la console web, dans le menu de gauche, cliquez sur Apps.
  5. Cliquez sur le générateur d'images.

    Le tableau de bord du constructeur d'images s'ouvre dans le volet de droite. Vous pouvez maintenant créer un plan pour les images RHEL for Edge.

4.2. Création d'un modèle pour l'image RHEL for Edge Commit à l'aide de l'outil de création d'images dans la console web RHEL

Pour créer un plan directeur pour l'image RHEL for Edge Commit à l'aide du constructeur d'images dans la console web RHEL, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Sur un système RHEL, vous avez ouvert le tableau de bord du constructeur d'images.

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer un modèle.

    La boîte de dialogue Create Blueprint s'ouvre.

  2. Sur la page Details:

    1. Saisissez le nom du plan et, éventuellement, sa description. Cliquez sur Suivant.
  3. Facultatif : dans la page Packages:

    1. Sur la page de recherche Available packages, saisissez le nom du paquet et cliquez sur le bouton > pour le déplacer dans le champ Paquets choisis. Recherchez et incluez autant de paquets que vous le souhaitez. Cliquez sur Suivant.

      Note

      Ces personnalisations sont toutes facultatives, sauf indication contraire.

  4. Sur la page Kernel, entrez un nom de noyau et les arguments de la ligne de commande.
  5. Sur la page File system, vous pouvez sélectionner Use automatic partitioning ou Manually configure partitions pour votre système de fichiers image. Pour configurer manuellement les partitions, procédez comme suit :

    1. Cliquez sur le bouton Configurer manuellement les partitions.

      La section Configure partitions s'ouvre, montrant la configuration basée sur les standards et les guides de sécurité de Red Hat.

    2. Dans le menu déroulant, fournissez les détails pour configurer les partitions :

      1. Dans le champ Mount point, sélectionnez l'une des options de type de point de montage suivantes :

        • / - le point de montage racine
        • /var
        • /home
        • /opt
        • /srv
        • /usr
        • /app
        • /data
        • /tmp
        • /usr/local

          Vous pouvez également ajouter un chemin supplémentaire au Mount point, tel que /tmp. Par exemple : /var comme préfixe et /tmp comme chemin supplémentaire donne /var/tmp.

          Note

          Selon le type de point de montage choisi, le type de système de fichiers devient xfs, et ainsi de suite.

      2. Dans le champ Minimum size partition du système de fichiers, entrez la taille minimale de partition souhaitée. Dans le menu déroulant Taille minimale, vous pouvez utiliser des unités de taille courantes telles que GiB, MiB ou KiB. L'unité par défaut est GiB.

        Note

        Minimum size signifie que le constructeur d'images peut encore augmenter la taille des partitions, au cas où elles seraient trop petites pour créer une image fonctionnelle.

    3. Pour ajouter d'autres partitions, cliquez sur le bouton Ajouter une partition. Si le message d'erreur suivant s'affiche : "Duplicate partitions : Une seule partition peut être créée à chaque point de montage", vous pouvez.. :

      1. Cliquez sur le bouton Supprimer pour supprimer la partition dupliquée.
      2. Choisissez un nouveau point de montage pour la partition que vous souhaitez créer.
    4. Après avoir terminé la configuration du partitionnement, cliquez sur Suivant.
  6. Sur la page Services, vous pouvez activer ou désactiver des services :

    1. Saisissez les noms des services que vous souhaitez activer ou désactiver, en les séparant par une virgule, un espace ou en appuyant sur la touche Entrée. Cliquez sur Suivant.
  7. Sur la page Firewall, configurez votre pare-feu :

    1. Saisissez l'adresse Ports et les services de pare-feu que vous souhaitez activer ou désactiver.
    2. Cliquez sur le bouton Ajouter une zone pour gérer vos règles de pare-feu pour chaque zone indépendamment. Cliquez sur Suivant.
  8. Sur la page Users, ajoutez un utilisateur en suivant les étapes suivantes :

    1. Cliquez sur Ajouter un utilisateur.
    2. Saisissez un Username, un password et un SSH key. Vous pouvez également marquer l'utilisateur en tant qu'utilisateur privilégié en cochant la case Server administrator. Cliquez sur Suivant.
  9. Sur la page Groups, ajoutez des groupes en suivant les étapes suivantes :

    1. Cliquez sur le bouton Ajouter des groupes:

      1. Saisissez un Group name et un Group ID. Vous pouvez ajouter d'autres groupes. Cliquez sur Suivant.
  10. Sur la page SSH keys, ajoutez une clé :

    1. Cliquez sur le bouton Ajouter une clé.

      1. Entrez la clé SSH.
      2. Saisissez une adresse User. Cliquez sur Suivant.
  11. Sur la page Timezone, définissez vos paramètres de fuseau horaire :

    1. Dans le champ Timezone, entrez le fuseau horaire que vous souhaitez ajouter à votre image système. Par exemple, ajoutez le format de fuseau horaire suivant : "US/Eastern".

      Si vous ne définissez pas de fuseau horaire, le système utilise par défaut le temps universel coordonné (UTC).

    2. Saisissez les serveurs NTP. Cliquez sur Suivant.
  12. Sur la page Locale, effectuez les étapes suivantes :

    1. Dans le champ de recherche Keyboard, saisissez le nom du paquet que vous souhaitez ajouter à votre image système. Par exemple, [\N- "en_US.UTF-8\N"] : [\N-"en_US.UTF-8\N"].
    2. Dans le champ de recherche Languages, saisissez le nom du paquet que vous souhaitez ajouter à votre image système. Par exemple : "us". Cliquez sur Suivant.
  13. Sur la page Others, effectuez les étapes suivantes :

    1. Dans le champ Hostname, entrez le nom d'hôte que vous souhaitez ajouter à votre image système. Si vous n'ajoutez pas de nom d'hôte, le système d'exploitation détermine le nom d'hôte.
    2. Obligatoire uniquement pour l'image Simplifier Installer : Dans le champ Installation Devices, entrez un nœud valide pour votre image système. Par exemple : dev/sda1. Cliquez sur Suivant.
  14. Obligatoire uniquement lors de la création d'images FIDO : Sur la page FIDO device onboarding, effectuez les étapes suivantes :

    1. Dans le champ Manufacturing server URL, entrez les informations suivantes :

      1. Dans le champ DIUN public key insecure, entrez la clé publique non sécurisée.
      2. Dans le champ DIUN public key hash, entrez le hachage de la clé publique.
      3. Dans le champ DIUN public key root certs, entrez les certificats racine de la clé publique. Cliquez sur Suivant.
  15. Sur la page OpenSCAP, effectuez les étapes suivantes :

    1. Dans le champ Datastream, entrez les instructions de remédiation datastream que vous souhaitez ajouter à votre image système.
    2. Dans le champ Profile ID, entrez le profil de sécurité profile_id que vous souhaitez ajouter à votre image système. Cliquez sur Suivant.
  16. Obligatoire uniquement lors de la création d'images Ignition : Sur la page Ignition, effectuez les étapes suivantes :

    1. Dans le champ Firstboot URL, saisissez le nom du paquet que vous souhaitez ajouter à votre image système.
    2. Dans le champ Embedded Data, faites glisser ou téléchargez votre fichier. Cliquez sur Suivant.
  17. . Sur la page Review, passez en revue les détails du plan. Cliquez sur Créer.

La vue du constructeur d'images s'ouvre et répertorie les plans existants.

4.3. Création d'une image RHEL for Edge Commit à l'aide du constructeur d'images dans la console web RHEL

Le type d'image “RHEL for Edge Commit (.tar)” contient un système d'exploitation complet, mais il n'est pas directement amorçable. Pour démarrer le type d'image Commit, vous devez le déployer dans un conteneur en cours d'exécution.

Pour créer une image RHEL for Edge Commit à l'aide du constructeur d'images dans la console Web RHEL, procédez comme suit :

Conditions préalables

  • Sur un système RHEL, vous avez accédé au tableau de bord du constructeur d'images.

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer une image.
  2. Sur la page Image output, procédez comme suit :

    1. Dans le menu déroulant Select a blueprint, sélectionnez le plan que vous souhaitez utiliser.
    2. Dans la liste déroulante Image output type, sélectionnez “RHEL for Edge Commit (.tar)” pour le déploiement en réseau.
    3. Cliquez sur Suivant.
    4. Sur la page OSTree settings, entrez :

      1. Repository URL: spécifie l'URL du dépôt OSTree de la livraison à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/.
      2. Parent commit: spécifiez un commit précédent, ou laissez le champ vide si vous n'avez pas de commit à ce moment-là.
      3. Dans la zone de texte Ref, indiquez un chemin de référence pour l'endroit où votre livraison sera créée. Par défaut, la console web spécifie rhel/9/$ARCH/edge. La valeur de "$ARCH" est déterminée par la machine hôte. Cliquez sur Suivant.
    5. Sur la page Review, vérifiez les personnalisations et cliquez sur Créer.

      Le constructeur d'images commence à créer une image RHEL for Edge Commit pour le plan que vous avez créé.

      Note

      Le processus de création d'une image dure jusqu'à 20 minutes.

Vérification

  1. Pour vérifier la progression de la création de l'image RHEL for Edge Commit :

    1. Cliquez sur l'onglet Images.

Une fois le processus de création d'image terminé, vous pouvez télécharger l'image “RHEL for Edge Commit (.tar)” qui en résulte.

Ressources supplémentaires

4.4. Création d'une image de conteneur RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL

Vous pouvez créer des images RHEL for Edge en sélectionnant “RHEL for Edge Container (.tar)”. Le type d'image RHEL for Edge Container (.tar) crée un commit OSTree et l'incorpore dans un conteneur OCI avec un serveur Web. Lorsque le conteneur est démarré, le serveur web sert le commit en tant que référentiel OSTree.

Suivez les étapes de cette procédure pour créer une image RHEL for Edge Container à l'aide de l'outil de création d'images dans la console Web RHEL.

Conditions préalables

  • Sur un système RHEL, vous avez accédé au tableau de bord du constructeur d'images.
  • Vous avez créé un schéma directeur.

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer une image.
  2. Sur la page Image output, procédez comme suit :
  3. Dans le menu déroulant Select a blueprint, sélectionnez le plan que vous souhaitez utiliser.

    1. Dans la liste déroulante Image output type, sélectionnez “RHEL for Edge Container (.tar)” pour le déploiement en réseau.
    2. Cliquez sur Suivant.
    3. Sur la page OSTree, entrez :

      1. Repository URL: spécifie l'URL du dépôt OSTree de la livraison à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/. Par défaut, le dossier de dépôt d'une image RHEL for Edge Container est "/repo".

        Pour trouver l'URL correcte à utiliser, accédez au conteneur en cours d'exécution et vérifiez le fichier nginx.conf. Pour savoir quelle URL utiliser, accédez au conteneur en cours d'exécution et consultez le fichier nginx.conf. Dans le fichier nginx.conf, trouvez l'entrée du répertoire root pour rechercher les informations du dossier /repo/. Notez que si vous ne spécifiez pas d'URL de référentiel lors de la création d'une image RHEL for Edge Container (.tar) à l'aide de Image Builder, l'entrée /repo/ par défaut est créée dans le fichier nginx.conf.

      2. Parent commit: spécifiez un commit précédent, ou laissez le champ vide si vous n'avez pas de commit à ce moment-là.
      3. Dans la zone de texte Ref, indiquez un chemin de référence pour l'endroit où votre livraison sera créée. Par défaut, la console web spécifie rhel/9/$ARCH/edge. La valeur de "$ARCH" est déterminée par la machine hôte. Cliquez sur Suivant.
    4. Sur la page Review, vérifiez les personnalisations. Cliquez sur Enregistrer le plan.
  4. Cliquez sur Créer.

    Le constructeur d'images commence à créer une image RHEL for Edge Container pour le plan que vous avez créé.

    Note

    Le processus de création d'une image dure jusqu'à 20 minutes.

Vérification

  1. Pour vérifier la progression de la création de l'image RHEL for Edge Container :

    1. Cliquez sur l'onglet Images.

Une fois le processus de création d'image terminé, vous pouvez télécharger l'image “RHEL for Edge Container (.tar)” qui en résulte.

Ressources supplémentaires

4.5. Création d'une image RHEL for Edge Installer à l'aide du constructeur d'images dans la console web RHEL

Vous pouvez créer des images RHEL for Edge Installer pour un déploiement hors réseau en sélectionnant RHEL for Edge Installer (.iso). Le type d'image RHEL for Edge Installer (.iso) extrait le référentiel de validation OSTree du conteneur en cours d'exécution desservi par RHEL for Edge Container (.tar) et crée une image ISO de démarrage installable avec un fichier Kickstart configuré pour utiliser la validation OSTree intégrée.

Suivez les étapes de cette procédure pour créer une image RHEL for Edge à l'aide de l'outil de création d'images dans la console web RHEL.

Conditions préalables

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer une image.
  2. Sur la page Image output, procédez comme suit :

    1. Dans le menu déroulant Select a blueprint, sélectionnez le plan que vous souhaitez utiliser.
    2. Dans la liste déroulante Image output type, sélectionnez RHEL for Edge Installer (.iso) l'image.
    3. Cliquez sur Suivant.
    4. Sur la page OSTree settings, entrez :

      1. Repository URL: spécifie l'URL du dépôt OSTree de la livraison à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/.
      2. Dans la zone de texte Ref, indiquez un chemin de référence pour l'endroit où votre livraison sera créée. Par défaut, la console web spécifie rhel/9/$ARCH/edge. La valeur de "$ARCH" est déterminée par la machine hôte. Cliquez sur Suivant.
    5. Sur la page Review, vérifiez les personnalisations. Cliquez sur Enregistrer le plan.
  3. Cliquez sur Créer.

    Le constructeur d'images commence à créer une image RHEL for Edge Installer pour le modèle que vous avez créé.

    Note

    Le processus de création d'une image dure jusqu'à 20 minutes.

Vérification

Une fois le processus de création d'image terminé, vous pouvez télécharger l'image RHEL for Edge Installer (.iso) qui en résulte.

  1. Pour vérifier la progression de la création de l'image RHEL for Edge Installer :

    1. Cliquez sur l'onglet Images.

Une fois le processus de création d'image terminé, vous pouvez télécharger l'image RHEL for Edge Installer (.iso) résultante et démarrer l'image ISO sur un périphérique.

Ressources supplémentaires

4.6. Téléchargement d'une image RHEL for Edge

Après avoir créé avec succès l'image RHEL for Edge à l'aide du générateur d'images, téléchargez l'image sur l'hôte local.

Procédure

Pour télécharger une image :

  1. Dans le menu More Options, cliquez sur Télécharger.

    L'outil de création d'images télécharge le fichier à votre emplacement de téléchargement par défaut.

Le fichier téléchargé consiste en un fichier .tar avec un référentiel OSTree pour les images RHEL for Edge Commit et RHEL for Edge Container, ou un fichier .iso pour les images RHEL for Edge Installer, avec un référentiel OSTree. Ce référentiel contient le commit et un fichier json qui contient des métadonnées d'information sur le contenu du référentiel.

4.7. Ressources supplémentaires

Chapitre 5. Composition d'une image RHEL for Edge à l'aide de la ligne de commande image builder

Vous pouvez utiliser le constructeur d'images pour créer une image RHEL for Edge personnalisée (OSTree commit).

Pour accéder au constructeur d'images et créer votre image RHEL for Edge personnalisée, vous pouvez utiliser l'interface de la console web RHEL ou l'interface de ligne de commande.

Pour les déploiements basés sur le réseau, le processus de composition des images RHEL for Edge à l'aide de l'interface de programmation comprend les étapes de haut niveau suivantes :

  1. Créer un modèle pour l'image RHEL for Edge
  2. Créer une image RHEL for Edge Commit
  3. Télécharger l'image RHEL for Edge Commit

Pour les déploiements non basés sur le réseau, le processus de composition des images RHEL for Edge à l'aide de la CLI comprend les étapes de haut niveau suivantes :

  1. Créer un modèle pour l'image RHEL for Edge
  2. Créer un modèle pour l'image RHEL for Edge Installer
  3. Créer une image RHEL for Edge Container
  4. Créer une image RHEL for Edge Installer
  5. Télécharger l'image RHEL for Edge

Pour effectuer les démarches, utilisez le logiciel composer-cli.

Note

Pour exécuter les commandes composer-cli en tant que non-root, vous devez faire partie du groupe weldr ou disposer d'un accès administrateur au système.

5.1. Flux de travail pour les déploiements en réseau

Ceci fournit les étapes pour construire OSTree commits. Ces commits OSTree contiennent un système d'exploitation complet, mais ne sont pas directement amorçables. Pour les démarrer, vous devez les déployer à l'aide d'un fichier Kickstart.

5.1.1. Création d'un modèle d'image RHEL for Edge Commit à l'aide de l'interface en ligne de commande image builder

Créez un schéma directeur pour l'image RHEL for Edge Commit à l'aide de la CLI.

Prérequis

  • Vous n'avez pas de plan existant. Pour le vérifier, dressez la liste des plans existants :

    $ sudo composer-cli blueprints list

Procédure

  1. Créez un fichier texte au format TOML, avec le contenu suivant :

    name = "blueprint-name"
    description = "blueprint-text-description"
    version = "0.0.1"
    modules = [ ]
    groups = [ ]

    Où ?

    • blueprint-name est le nom et blueprint-text-description est la description de votre plan.
    • 0.0.1 est le numéro de version selon le schéma de versionnement sémantique.
    • Modules décrivent le nom du paquet et la version correspondante à installer dans l'image. Par exemple, le nom du paquet = "tmux" et la version correspondante est version = "2.9a".

      Notez qu'il n'y a actuellement aucune différence entre les paquets et les modules.

    • Groups sont des groupes de paquets à installer dans l'image, par exemple le groupe de paquets anaconda-tools.

      A ce stade, si vous ne connaissez pas les modules et les groupes, laissez-les vides.

  2. Incluez les paquets requis et adaptez les autres détails du plan à vos besoins.

    Pour chaque paquet que vous souhaitez inclure dans le plan, ajoutez les lignes suivantes au fichier :

    [[packages]]
    name = "package-name"
    version = "package-version"

    Où ?

    • package-name est le nom du paquet, tel que httpd, gdb-doc, ou coreutils.
    • package-version est le numéro de version du paquet que vous souhaitez utiliser.

      La version du paquet prend en charge les spécifications de version dnf suivantes :

    • Pour une version spécifique, utilisez le numéro de version exact, par exemple 9.0.
    • Pour la dernière version disponible, utilisez l'astérisque *.
    • Pour la dernière version mineure, utilisez des formats tels que 9.*.
  3. Pousser (importer) le plan vers le serveur de construction d'images :

    # composer-cli blueprints push blueprint-name.toml
  4. Liste les plans existants pour vérifier si le plan créé a été poussé avec succès et s'il existe.

    # composer-cli blueprints show BLUEPRINT-NAME
  5. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve blueprint-name

Ressources supplémentaires

5.1.2. Création d'une image RHEL for Edge Commit à l'aide de l'interface en ligne de commande image builder

Pour créer une image RHEL for Edge Commit à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes et suivez la procédure.

Conditions préalables

  • Vous avez créé un schéma directeur pour l'image RHEL for Edge Commit.

Procédure

  1. Créez l'image RHEL for Edge Commit.

    # composer-cli compose start blueprint-name image-type

    Où ?

    • blueprint-name est le nom du plan RHEL for Edge.
    • image-type est edge-commit pour network-based deployment.

      Une confirmation de l'ajout du processus de composition à la file d'attente s'affiche. Elle indique également un numéro d'identifiant universel unique (UUID) pour l'image créée. Utilisez le numéro UUID pour suivre votre construction. Conservez également le numéro UUID à portée de main pour d'autres tâches.

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Le processus de création d'une image dure jusqu'à 20 minutes.

    Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

    Une fois que l'image est prête, vous pouvez la télécharger et l'utiliser sur votre site network deployments.

5.1.3. Création d'une mise à jour d'image RHEL for Edge avec un ref commit à l'aide de l'interface en ligne de commande image builder

Si vous avez modifié un plan existant, par exemple en ajoutant un nouveau package, et que vous souhaitez mettre à jour une image RHEL for Edge existante avec ce nouveau package, vous pouvez utiliser l'argument --parent pour générer une image RHEL for Edge Commit (.tar) mise à jour. L'argument --parent doit être un ref qui existe dans le référentiel spécifié par l'argument URL. L'argument --ref vous permet de spécifier un ref existant qui récupère un parent pour le nouveau commit que vous construisez. Vous devez spécifier le commit parent sous la forme d'une valeur ref à résoudre et à extraire, et non sous la forme d'un identifiant de commit, par exemple rhel/9/x86_64/edge. Lorsque vous spécifiez le commit parent sous la forme d'une valeur ref, Image Builder peut lire des informations du commit parent qui affecteront des parties du nouveau commit que vous construisez. Par conséquent, Image builder lit la base de données des utilisateurs du commit parent et préserve les UID et les GID pour les utilisateurs et les groupes du système créés par le paquet.

Pour créer une image RHEL for Edge avec un argument parent à l'aide de l'interface CLI de construction d'images, assurez-vous d'avoir rempli les conditions préalables suivantes et suivez la procédure.

Conditions préalables

  • Vous avez mis à jour un plan existant pour l'image RHEL for Edge.
  • Vous disposez d'une image RHEL for Edge existante (commit OSTree). Voir Extraction du commit de l'image RHEL for Edge.
  • Le site ref en cours de construction est disponible dans le dépôt OSTree spécifié par l'URL.

Procédure

  1. Créer l'image RHEL for Edge commit :

    # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --parent parent-OSTree-REF --url URL blueprint-name image-type

    Par exemple :

    • Pour créer un nouveau commit RHEL for Edge basé sur un parent et avec un nouveau ref, exécutez la commande suivante: :

      # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --parent rhel/9/x86_64/edge --url http://10.0.2.2:8080/repo rhel_update edge-commit
    • Pour créer un nouveau commit RHEL for Edge basé sur le même site ref, exécutez la commande suivante :

      # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url http://10.0.2.2:8080/repo rhel_update edge-commit

      Où ?

      • L'argument --ref spécifie le même chemin d'accès que celui que vous avez utilisé pour créer un référentiel OSTree.
      • L'argument --parent spécifie le commit parent en tant que ref à résoudre et à extraire, et non en tant qu'identifiant de commit, par exemple rhel/9/x86_64/edge.
      • blueprint-name est le nom du plan RHEL for Edge.
      • L'argument --url spécifie l'URL du dépôt OSTree de l'engagement à intégrer dans l'image, par exemple http://10.0.2.2:8080/repo.
      • image-type est edge-commit pour network-based deployment.

        Note
        • L'argument --parent ne peut être utilisé que pour le type d'image RHEL for Edge Commit (.tar). L'utilisation conjointe des arguments --url et --parent entraîne des erreurs avec le type d'image RHEL for Edge Container (.tar).
        • Si vous omettez l'argument parent ref, le système revient à l'adresse ref spécifiée par l'argument --ref.

        Une confirmation de l'ajout du processus de composition à la file d'attente s'affiche. Elle indique également un numéro d'identifiant universel unique (UUID) pour l'image créée. Utilisez le numéro UUID pour suivre votre construction. Conservez également le numéro UUID à portée de main pour d'autres tâches.

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Le processus de création de l'image prend quelques minutes.

    (Facultatif) Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    (Facultatif) Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

Une fois la création de l'image terminée, pour mettre à niveau un déploiement OSTree existant, vous devez :

5.1.4. Téléchargement d'une image RHEL for Edge à l'aide de l'interface de ligne de commande du constructeur d'images

Pour télécharger une image RHEL for Edge à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez créé une image RHEL for Edge.

Procédure

  1. Examinez l'état de l'image RHEL for Edge.

    # composer-cli compose status

    La sortie doit afficher ce qui suit :

    $ <UUID> FINIS date blueprint-name blueprint-version image-type
  2. Télécharger l'image.

    # composer-cli compose image <UUID>

    Image builder télécharge l'image sous forme de fichier tar dans le répertoire actuel.

    Le numéro UUID et la taille de l'image s'affichent à côté.

    $ <UUID>-commit.tar : size MB

L'image contient un commit et un fichier json avec des métadonnées d'information sur le contenu du référentiel.

5.2. Flux de travail pour les déploiements non basés sur un réseau

Pour créer une image ISO de démarrage qui installe un système basé sur OSTree à l'aide des images "RHEL for Edge Container" et "RHEL for Edge Installer" et qui peut être déployée ultérieurement sur un périphérique dans des environnements déconnectés, procédez comme suit.

5.2.1. Création d'un modèle de conteneur RHEL for Edge à l'aide de l'interface CLI de construction d'images

Pour créer un modèle d'image RHEL for Edge Container, procédez comme suit :

Procédure

  1. Créez un fichier texte au format TOML, avec le contenu suivant :

    name = "blueprint-name"
    description = "blueprint-text-description"
    version = "0.0.1"
    modules = [ ]
    groups = [ ]

    Où ?

    • blueprint-name est le nom et blueprint-text-description est la description de votre plan.
    • 0.0.1 est le numéro de version selon le schéma de versionnement sémantique.
    • Modules décrivent le nom du paquet et la version correspondante à installer dans l'image. Par exemple, le nom du paquet = "tmux" et la version correspondante est version = "2.9a".

      Notez qu'il n'y a actuellement aucune différence entre les paquets et les modules.

    • Groups sont des groupes de paquets à installer dans l'image, par exemple le groupe de paquets anaconda-tools.

      A ce stade, si vous ne connaissez pas les modules et les groupes, laissez-les vides.

  2. Incluez les paquets requis et adaptez les autres détails du plan à vos besoins.

    Pour chaque paquet que vous souhaitez inclure dans le plan, ajoutez les lignes suivantes au fichier :

    [[packages]]
    name = "package-name"
    version = "package-version"

    Où ?

    • package-name est le nom du paquet, tel que httpd, gdb-doc, ou coreutils.
    • package-version est le numéro de version du paquet que vous souhaitez utiliser.

      La version du paquet prend en charge les spécifications de version dnf suivantes :

    • Pour une version spécifique, utilisez le numéro de version exact, par exemple 9.0.
    • Pour la dernière version disponible, utilisez l'astérisque *.
    • Pour la dernière version mineure, utilisez des formats tels que 9.*.
  3. Pousser (importer) le plan vers le serveur de construction d'images :

    # composer-cli blueprints push blueprint-name.toml
  4. Liste les plans existants pour vérifier si le plan créé a été poussé avec succès et s'il existe.

    # composer-cli blueprints show BLUEPRINT-NAME
  5. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve blueprint-name

Ressources supplémentaires

5.2.2. Création d'un plan d'installation de RHEL for Edge à l'aide de l'interface CLI de construction d'images

Vous pouvez créer un modèle pour construire une image RHEL for Edge Installer (.iso) et spécifier des comptes utilisateur pour créer automatiquement un ou plusieurs utilisateurs sur le système au moment de l'installation. Voir Création d'un compte d'utilisateur administratif pour un modèle d'image RHEL for Edge. Il crée un utilisateur sur le système au moment de l'installation.

Avertissement

Lorsque vous créez un utilisateur dans le plan avec la personnalisation customizations.user, le plan crée l'utilisateur dans le répertoire /usr/lib/passwd et le mot de passe dans le répertoire /usr/etc/shadow. Notez que vous ne pouvez pas modifier le mot de passe dans les versions ultérieures de l'image dans un système en cours d'exécution utilisant les mises à jour OSTree. Les utilisateurs que vous créez avec les blueprints ne doivent être utilisés que pour accéder au système créé. Après avoir accédé au système, vous devez créer des utilisateurs, par exemple à l'aide de la commande useradd.

Pour créer un modèle d'image pour RHEL for Edge Installer, procédez comme suit :

Procédure

  1. Créez un fichier texte au format TOML, avec le contenu suivant :

    name = "blueprint-installer"
    description = "blueprint-for-installer-image"
    version = "0.0.1"
    
    [[customizations.user]]
    name = "user"
    description = "account"
    password = "user-password"
    key = "user-ssh-key "
    home = "path"
    groups = ["user-groups"]

    Où ?

    • blueprint-name est le nom et blueprint-text-description est la description de votre plan.
    • 0.0.1 est le numéro de version selon le schéma de versionnement sémantique.
  2. Pousser (importer) le plan vers le serveur de construction d'images :

    # composer-cli blueprints push blueprint-name.toml
  3. Liste les plans existants pour vérifier si le plan créé a été poussé avec succès et s'il existe.

    # composer-cli blueprints show blueprint-name
  4. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve blueprint-name

Ressources supplémentaires

5.2.3. Création d'une image de conteneur RHEL for Edge à l'aide de l'interface CLI de construction d'images

Pour créer une image RHEL for Edge Container à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes et suivez la procédure.

Conditions préalables

  • Vous avez créé un schéma directeur pour l'image RHEL for Edge Container.

Procédure

  1. Créez l'image RHEL for Edge Container.

    # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type

    Où ?

    • --ref est la même valeur que celle utilisée par le client pour construire le dépôt d'ostree
    • --url est l'URL du dépôt OSTree de l'engagement à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/. Par défaut, le dossier de dépôt d'une image RHEL for Edge Container est "/repo". Voir Configuration d'un serveur Web pour l'installation de l'image RHEL for Edge.

      Pour trouver l'URL correcte à utiliser, accédez au conteneur en cours d'exécution et vérifiez le fichier nginx.conf. Pour savoir quelle URL utiliser, accédez au conteneur en cours d'exécution et consultez le fichier nginx.conf. Dans le fichier nginx.conf, trouvez l'entrée du répertoire root pour rechercher les informations du dossier /repo/. Notez que si vous ne spécifiez pas d'URL de référentiel lors de la création d'une image RHEL for Edge Container (.tar) à l'aide de Image Builder, l'entrée /repo/ par défaut est créée dans le fichier nginx.conf.

    • blueprint-name est le nom du plan RHEL for Edge.
    • image-type est edge-container pour non-network-based deployment.

      Une confirmation de l'ajout du processus de composition à la file d'attente s'affiche. Elle indique également un numéro d'identifiant universel unique (UUID) pour l'image créée. Utilisez le numéro UUID pour suivre votre construction. Conservez également le numéro UUID à portée de main pour d'autres tâches.

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Le processus de création d'une image dure jusqu'à 20 minutes.

    Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

    Une fois l'image prête, elle peut être utilisée pour non-network deployments. Voir Création d'une image RHEL for Edge Container pour les déploiements non basés sur le réseau.

5.2.4. Création d'une image RHEL for Edge Installer à l'aide de l'interface de ligne de commande pour les déploiements non basés sur le réseau

Pour créer une image RHEL for Edge Installer qui intègre le commit OSTree, à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez créé un schéma directeur pour RHEL pour l'image Edge Installer.
  • Vous avez créé une image RHEL for Edge Edge Container et l'avez déployée à l'aide d'un serveur web.

Procédure

  1. Commencez à créer l'image RHEL for Edge Installer.

    # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type

    Où ?

    • ref est la même valeur que celle utilisée par le client pour construire le dépôt d'ostree
    • URL-OSTree-repository est l'URL du dépôt OSTree de l'engagement à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo. Voir Création d'une image RHEL for Edge Container pour les déploiements non basés sur le réseau.
    • blueprint-name est le nom du modèle RHEL for Edge Installer.
    • image-type est edge-installer.

      Une confirmation de l'ajout du processus de composition à la file d'attente s'affiche. Elle indique également un numéro d'identifiant universel unique (UUID) pour l'image créée. Utilisez le numéro UUID pour suivre votre construction. Conservez également le numéro UUID à portée de main pour d'autres tâches.

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie de la commande affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Le processus de création de l'image prend quelques minutes.

    Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

    Une fois l'image prête, vous pouvez l'utiliser pour non-network deployments. Voir Installation de l'image RHEL for Edge pour les déploiements non basés sur le réseau.

5.2.5. Téléchargement d'une image RHEL for Edge Installer à l'aide de l'interface CLI de construction d'images

Pour télécharger une image RHEL for Edge Installer à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez créé une image RHEL for Edge Installer.

Procédure

  1. Examinez l'état de l'image RHEL for Edge.

    # composer-cli compose status

    La sortie doit afficher ce qui suit :

    $ <UUID> FINIS date blueprint-name blueprint-version image-type
  2. Télécharger l'image.

    # composer-cli compose image <UUID>

    Image builder télécharge l'image sous forme de fichier .iso dans le répertoire actuel.

    Le numéro UUID et la taille de l'image s'affichent à côté.

    $ <UUID>-boot.iso : size MB

L'image obtenue est une image ISO amorçable.

5.3. Personnalisations d'images prises en charge

Vous pouvez personnaliser votre image en ajoutant à votre plan un paquetage RPM supplémentaire, en activant un service ou en personnalisant un paramètre de la ligne de commande du noyau. Vous pouvez utiliser plusieurs personnalisations d'image dans les blueprints. Pour utiliser ces options, vous devez configurer les personnalisations dans le blueprint et l'importer (push) dans le constructeur d'images.

Note

Ces personnalisations ne sont pas prises en charge lors de l'utilisation du constructeur d'images dans la console web.

Sélectionner un groupe de paquets
[[packages]]
name = "package_group_name"

Remplacez "package_group_name" par le nom du groupe. Par exemple, "@server with gui".

Définir le nom d'hôte de l'image
[customizations]
hostname = "baseimage"
Spécifications utilisateur pour l'image système résultante
[[customizations.user]]
name = "USER-NAME"
description = "USER-DESCRIPTION"
password = "PASSWORD-HASH"
key = "PUBLIC-SSH-KEY"
home = "/home/USER-NAME/"
shell = "/usr/bin/bash"
groups = ["users", "wheel"]
uid = NUMBER
gid = NUMBER

Le GID est facultatif et doit déjà exister dans l'image. Il peut être créé par un paquet ou par le plan directeur à l'aide de l'entrée [[customizations.group]].

Important

Pour générer le fichier password hash, vous devez installer python3 sur votre système.

# dnf install python3

Remplacez PASSWORD-HASH par l'actuel password hash. Pour générer password hash, utilisez une commande telle que :

$ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

Remplacez PUBLIC-SSH-KEY par la clé publique réelle.

Remplacez les autres espaces réservés par des valeurs appropriées.

Vous devez saisir l'adresse name. Vous pouvez omettre toutes les lignes dont vous n'avez pas besoin.

Répétez ce bloc pour chaque utilisateur à inclure.

Spécifications du groupe pour l'image système résultante
[[customizations.group]]
name = "GROUP-NAME"
gid = NUMBER

Répétez ce bloc pour chaque groupe à inclure.

Définir la clé SSH d'un utilisateur existant
[[customizations.sshkey]]
user = "root"
key = "PUBLIC-SSH-KEY"
Note

La personnalisation "Définir la clé SSH d'un utilisateur existant" ne s'applique qu'aux utilisateurs existants. Pour créer un utilisateur et définir une clé SSH, voir la personnalisation User specifications for the resulting system image.

Ajouter une option de paramètre de démarrage du noyau aux valeurs par défaut
[customizations.kernel]
append = "KERNEL-OPTION"
Par défaut, le constructeur d'images intègre un noyau par défaut dans l'image. Mais vous pouvez personnaliser le noyau avec la configuration suivante dans le blueprint
[customizations.kernel]
name = "KERNEL-rt"
Définir un nom de noyau à utiliser dans une image
[customizations.kernel.name]
name = "KERNEL-NAME"
Définir le fuseau horaire et les serveurs Network Time Protocol (NTP) pour l'image système résultante
[customizations.timezone]
timezone = "TIMEZONE"
ntpservers = "NTP_SERVER"

Si vous ne définissez pas de fuseau horaire, le système utilise par défaut Universal Time, Coordinated (UTC) . La définition de serveurs NTP est facultative.

Définir les paramètres linguistiques de l'image système résultante
[customizations.locale]
languages = ["LANGUAGE"]
keyboard = "KEYBOARD"

Le paramétrage de la langue et des options du clavier est obligatoire. Vous pouvez ajouter de nombreuses autres langues. La première langue que vous ajoutez sera la langue principale et les autres langues seront secondaires. Par exemple, la première langue ajoutée sera la langue principale et les autres langues seront secondaires :

[customizations.locale]
languages = ["en_US.UTF-8"]
keyboard = "us"

Pour dresser la liste des valeurs prises en charge par les langues, exécutez la commande suivante :

$ localectl list-locales

Pour dresser la liste des valeurs prises en charge par le clavier, exécutez la commande suivante :

$ localectl list-keymaps
Définir le pare-feu pour l'image système résultante
[customizations.firewall]
port = ["PORTS"]

Pour activer les listes, vous pouvez utiliser des ports numériques ou leurs noms dans le fichier /etc/services.

Personnaliser les services de pare-feu

Examinez les services de pare-feu disponibles.

$ firewall-cmd --get-services

Dans le plan, sous la section customizations.firewall.service, indiquez les services de pare-feu que vous souhaitez personnaliser.

[customizations.firewall.services]
enabled = ["SERVICES"]
disabled = ["SERVICES"]

Les services répertoriés dans firewall.services sont différents des noms de services disponibles dans le fichier /etc/services.

Note

Si vous ne souhaitez pas personnaliser les services de pare-feu, omettez les sections [customizations.firewall] et [customizations.firewall.services] du plan.

Définir les services à activer pendant le démarrage
[customizations.services]
enabled = ["SERVICES"]
disabled = ["SERVICES"]

Vous pouvez contrôler les services à activer pendant le démarrage. Certains types d'images ont déjà des services activés ou désactivés pour s'assurer que l'image fonctionne correctement et cette configuration ne peut pas être remplacée. La personnalisation de [customizations.services] dans le blueprint ne remplace pas ces services, mais les ajoute à la liste des services déjà présents dans les modèles d'image.

Note

Chaque fois qu'une compilation démarre, elle clone le référentiel du système hôte. Si vous vous référez à un référentiel avec un historique important, le clonage peut prendre un certain temps et utiliser une quantité importante d'espace disque. De plus, le clone est temporaire et la compilation le supprime après avoir créé le paquetage RPM.

Spécifier une configuration personnalisée du système de fichiers

Vous pouvez spécifier une configuration de système de fichiers personnalisée dans vos blueprints et créer ainsi des images avec une disposition de disque spécifique, au lieu de la configuration par défaut. L'utilisation d'une configuration différente de la configuration par défaut dans vos blueprints vous permet de bénéficier des avantages suivants

  • sécurité benchmark conformité
  • protection contre les erreurs hors disque
  • amélioration des performances
  • cohérence avec les installations existantes

    Pour personnaliser la configuration du système de fichiers dans votre projet :

    [[customizations.filesystem]]
    mountpoint = "MOUNTPOINT"
    size = MINIMUM-PARTITION-SIZE

    Le plan directeur prend en charge les mountpoints suivants et leurs sous-répertoires :

    • / - le point de montage racine
    • /var
    • /home
    • /opt
    • /srv
    • /usr
    • /app
    • /data
    • /boot - Pris en charge à partir de RHEL 8.7 et RHEL 9.1.

      Note

      La personnalisation des points de montage n'est prise en charge qu'à partir des distributions RHEL 8.5 et RHEL 9.0, à l'aide de la CLI. Dans les distributions antérieures, vous pouvez uniquement spécifier la partition root comme point de montage et spécifier l'argument size comme alias pour la taille de l'image.

      Si vous avez plus d'une partition dans l'image personnalisée, vous pouvez créer des images avec une partition de système de fichiers personnalisé sur LVM et redimensionner ces partitions au moment de l'exécution. Pour ce faire, vous pouvez spécifier une configuration de système de fichiers personnalisée dans votre plan et créer ainsi des images avec l'agencement de disque souhaité. La configuration par défaut du système de fichiers reste inchangée si vous utilisez des images simples sans personnalisation du système de fichiers, et cloud-init redimensionne la partition racine.

      Note

      À partir de la version 8.6, pour le RPM osbuild-composer-46.1-1.el8 et les versions ultérieures, les partitions physiques ne sont plus disponibles et les personnalisations du système de fichiers créent des volumes logiques.

      Le schéma directeur convertit automatiquement la personnalisation du système de fichiers en une partition LVM.

      La valeur MINIMUM-PARTITION-SIZE n'a pas de format de taille par défaut. La personnalisation du plan directeur prend en charge les valeurs et unités suivantes : kB à TB et KiB à TiB. Par exemple, vous pouvez définir la taille du point de montage en octets :

      [[customizations.filesystem]]
      mountpoint = "/var"
      size = 1073741824

      Vous pouvez également définir la taille du point de montage en utilisant des unités.

      Note

      Vous ne pouvez définir la taille du point de montage qu'en utilisant les unités de la version du paquetage fournie pour les distributions RHEL 8.6 et RHEL 9.0.

      Par exemple :

      [[customizations.filesystem]]
      mountpoint = "/opt"
      size = "20 GiB"
      
      or
      
      [[customizations.filesystem]]
      mountpoint = "/boot"
      size = "1 GiB"
Créez des répertoires et des fichiers personnalisés pour votre image dans le répertoire /etc

Pour créer des fichiers et des répertoires personnalisés dans votre image, utilisez les personnalisations [[customizations.files]] et [[customizations.directories]]. Actuellement, vous ne pouvez utiliser ces personnalisations que dans le répertoire /etc.

Note

Ces personnalisations du plan directeur sont prises en charge par tous les types d'images, à l'exception des types d'images qui déploient des commits OSTree, tels que edge-raw-image, edge-installer, et edge-simplified-installer.

Create a custom directory blueprint customization

Avec la personnalisation de [[customizations.directories]] blueprint, vous pouvez créer des répertoires personnalisés dans le répertoire /etc de votre image.

Avertissement

Si vous utilisez customizations.directories avec un chemin de répertoire qui existe déjà dans l'image avec mode, user ou group, la construction de l'image échoue pour empêcher la modification de la propriété ou des autorisations du répertoire existant.

Grâce à la personnalisation de [[customizations.directories]] blueprint, vous pouvez :

  • Créer de nouveaux répertoires.
  • Définissez la propriété de l'utilisateur et du groupe pour le répertoire que vous créez.
  • Définit l'autorisation du mode répertoire au format octal.
  • Veillez à ce que les répertoires parents soient créés si nécessaire.

Pour personnaliser la configuration d'un répertoire dans votre plan, créez un fichier avec le contenu suivant, par exemple :

[[customizations.directories]]
path = "/etc/directory_name"
mode = "octal_access_permission"
user = "user_string_or_integer"
group = "group_string_or_integer"
ensure_parents = boolean

Les entrées du plan sont décrites comme suit :

  • path - Obligatoire - indiquez le chemin d'accès au répertoire que vous souhaitez créer. Il doit s'agir d'un chemin absolu sous le répertoire /etc.
  • mode - Facultatif - définit l'autorisation d'accès au répertoire, au format octal. Si vous ne spécifiez pas d'autorisation, la valeur par défaut est 0755. Le zéro initial est facultatif.
  • user - Facultatif - définit un utilisateur comme propriétaire du répertoire. Si vous ne spécifiez pas d'utilisateur, la valeur par défaut est root. Vous pouvez spécifier l'utilisateur sous la forme d'une chaîne de caractères ou d'un nombre entier.
  • group - Facultatif - définit un groupe comme propriétaire du répertoire. Si vous ne spécifiez pas de groupe, la valeur par défaut est root. Vous pouvez spécifier le groupe sous la forme d'une chaîne de caractères ou d'un nombre entier.
  • ensure_parents - Facultatif - Indiquez si vous souhaitez créer des répertoires parents si nécessaire. Si vous ne spécifiez pas de valeur, la valeur par défaut est false.

Create a custom file blueprint customization

Vous pouvez utiliser la personnalisation du plan de fichier pour créer de nouveaux fichiers ou remplacer des fichiers existants. Le répertoire parent du fichier que vous spécifiez doit exister, sinon la construction de l'image échoue. Assurez-vous que le répertoire parent existe en le spécifiant dans la personnalisation [[customizations.directories]].

Avertissement

Si vous combinez les personnalisations de fichiers avec d'autres personnalisations de plans, cela peut affecter le fonctionnement des autres personnalisations ou remplacer les personnalisations de fichiers actuelles. Si vous n'êtes pas sûr des personnalisations, utilisez la personnalisation de modèle appropriée.

Grâce à la personnalisation de [[customizations.files]] blueprint, vous pouvez :

  • Créer de nouveaux fichiers texte.
  • Modifier les fichiers existants. ATTENTION : cette modification peut remplacer le contenu existant.
  • Définissez la propriété de l'utilisateur et du groupe pour le fichier que vous créez.
  • Définit l'autorisation de mode au format octal.

    Note

    Vous ne pouvez pas créer ou remplacer les fichiers suivants :

  • /etc/fstab
  • /etc/shadow
  • /etc/passwd
  • /etc/group

Pour personnaliser un fichier dans votre plan, créez un fichier avec le contenu suivant, par exemple :

[[customizations.files]]
path = "/etc/directory_name"
mode = "octal_access_permission"
user = "user_string_or_integer"
group = "group_string_or_integer"
data = "Hello world!"

Les entrées du plan sont décrites comme suit :

  • path - Obligatoire - indiquez le chemin d'accès au fichier que vous souhaitez créer. Il doit s'agir d'un chemin absolu sous le répertoire /etc.
  • mode Facultatif - définit l'autorisation d'accès au fichier, au format octal. Si vous ne spécifiez pas d'autorisation, la valeur par défaut est 0644. Le zéro initial est facultatif.
  • user - Facultatif - définit un utilisateur comme propriétaire du fichier. Si vous ne spécifiez pas d'utilisateur, la valeur par défaut est root. Vous pouvez spécifier l'utilisateur sous la forme d'une chaîne de caractères ou d'un nombre entier.
  • group - Facultatif - définit un groupe comme propriétaire du fichier. Si vous ne spécifiez pas de groupe, la valeur par défaut est root. Vous pouvez spécifier le groupe sous la forme d'une chaîne de caractères ou d'un nombre entier.
  • data - Facultatif - Spécifiez le contenu d'un fichier de texte brut. Si vous n'indiquez pas de contenu, un fichier vide est créé.

5.4. Ressources supplémentaires

Chapitre 6. Création d'images d'installation simplifiées pour le provisionnement d'une image RHEL for Edge

Vous pouvez créer une image RHEL for Edge Simplified Installer, optimisée pour une installation sans surveillance sur un périphérique, et l'intégrer à une image RHEL for Edge.

6.1. Création et déploiement simplifiés de l'image d'installation

Créez une image RHEL for Edge Simplified Installer en utilisant le type d'image edge-simplified-installer.

Pour créer une image RHEL for Edge Simplified Installer, fournissez un commit OSTree existant. L'image simplifiée qui en résulte contient une image brute dans laquelle le commit OSTree a été déployé. Une fois que vous avez démarré l'image ISO du programme d'installation simplifiée, elle fournit un système RHEL for Edge que vous pouvez utiliser sur un disque dur ou en tant qu'image de démarrage dans une machine virtuelle. Vous pouvez vous connecter au système déployé à l'aide du nom d'utilisateur et du mot de passe que vous avez spécifiés dans le plan utilisé pour créer l'image de l'installateur simplifié.

L'image RHEL for Edge Simplified Installer est optimisée pour une installation sans surveillance sur un périphérique et prend en charge à la fois les déploiements basés sur le réseau et les déploiements non basés sur le réseau. Toutefois, pour les déploiements basés sur le réseau, elle ne prend en charge que le démarrage UEFI HTTP.

La composition et le déploiement d'une image RHEL for Edge simplifiée impliquent les étapes de haut niveau suivantes :

  1. Installer et enregistrer un système RHEL
  2. Installer le constructeur d'images
  3. À l'aide de l'outil de création d'images, créez un modèle avec des personnalisations pour l'image RHEL for Edge Container
  4. Importer le plan RHEL for Edge dans le constructeur d'images
  5. Créer une image RHEL for Edge intégrée dans un conteneur OCI avec un serveur web prêt à déployer le commit en tant que dépôt OSTree
  6. Créer un plan pour l'image edge-simplified-installer
  7. Construire une image simplifiée de RHEL for Edge
  8. Télécharger l'image simplifiée de RHEL for Edge
  9. Installer l'image brute avec edge-simplified-installer virt-install

Le diagramme suivant représente le processus de construction et de provisionnement de RHEL for Edge Simplified :

Figure 6.1. Mise en place et déploiement de RHEL for Edge dans un environnement de base réseau

RHEL for Edge Simplified workflow

6.2. Création d'un plan pour une image simplifiée à l'aide de l'interface CLI de construction d'images

Pour créer un plan pour une image RHEL for Edge simplifiée, vous devez le personnaliser avec un emplacement device file pour permettre une installation sans surveillance sur un appareil et un emplacement URL pour effectuer l'échange initial d'informations d'identification de l'appareil. Vous devez également spécifier des utilisateurs et des groupes d'utilisateurs dans le plan. Pour cela, suivez les étapes suivantes :

Procédure

  1. Créez un fichier texte en clair au format Tom's Obvious, Minimal Language (TOML), avec le contenu suivant :

    name = "simplified-installer-blueprint"
    description = "blueprint for the simplified installer image"
    version = "0.0.1"
    packages = []
    modules = []
    groups = []
    distro = ""
    
    [customizations]
    installation_device = "/dev/vda"
    
    [[customizations.user]]
    name = "admin"
    password = "admin"
    groups = ["users", "wheel"]
    
    [customizations.fdo]
    manufacturing_server_url = "http://10.0.0.2:8080"
    diun_pub_key_insecure = "true"
    Note

    La personnalisation FDO dans les plans est facultative, et vous pouvez créer votre image RHEL for Edge Simplified Installer sans erreur.

    • name est le nom et description est la description de votre plan.
    • 0.0.1 est le numéro de version selon le schéma de versionnement sémantique.
    • Modules décrivent le nom du paquet et la version correspondante à installer dans l'image. Par exemple, le nom du paquet = "tmux" et la version correspondante est version = "2.9a". Notez qu'il n'y a actuellement aucune différence entre les paquets et les modules.
    • Groups sont des groupes de paquets à installer dans l'image, par exemple le paquet du groupe anaconda-tools. Si vous ne connaissez pas les modules et les groupes, laissez-les vides.
    • installation-device est la personnalisation qui permet une installation sans surveillance sur votre appareil.
    • manufacturing_server_url est l'URL permettant d'effectuer l'échange initial des informations d'identification du dispositif.
    • name est le nom d'utilisateur pour se connecter à l'image.
    • password est un mot de passe de votre choix.
    • groups sont des groupes d'utilisateurs, tels que "widget".
  2. Pousser (importer) le plan vers le serveur de construction d'images :

    # composer-cli blueprints push blueprint-name.toml
  3. Liste les plans existants pour vérifier si le plan créé a été poussé avec succès et s'il existe.

    # composer-cli blueprints show blueprint-name
  4. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve blueprint-name

6.3. Création d'une image RHEL for Edge Simplified Installer à l'aide de l'interface CLI de construction d'images

Pour créer une image RHEL for Edge Simplified à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

Procédure

  1. Créer l'image ISO amorçable.

    # composer-cli compose start-ostree \
    blueprint-name \
    edge-simplified-installer \
    --ref rhel/9/x86_64/edge \
    --url URL-OSTree-repository \

    Où ?

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Les processus de création d'images peuvent durer jusqu'à dix minutes.

    Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

6.4. Téléchargement d'une image simplifiée de RHEL for Edge à l'aide de l'interface de ligne de commande du constructeur d'images

Pour télécharger une image RHEL for Edge à l'aide de l'interface de ligne de commande image builder, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez créé une image RHEL for Edge.

Procédure

  1. Examinez l'état de l'image RHEL for Edge.

    # composer-cli compose status

    La sortie doit afficher ce qui suit :

    $ <UUID> FINIS date blueprint-name blueprint-version image-type
  2. Télécharger l'image.

    # composer-cli compose image <UUID>

    Image builder télécharge l'image sous la forme d'un fichier .iso dans le répertoire où vous exécutez la commande.

    Le numéro UUID et la taille de l'image s'affichent à côté.

    $ <UUID>-simplified-installer.iso : size MB

Vous avez donc téléchargé une image ISO RHEL for Edge Simplified Installer. Vous pouvez l'utiliser directement comme ISO de démarrage pour installer un système RHEL for Edge.

6.5. Création d'un plan pour une image simplifiée à l'aide de l'interface graphique du constructeur d'images

Pour créer une image RHEL for Edge Simplified Installer, vous devez créer un modèle et vous assurer que vous le personnalisez avec :

  • Emplacement d'un nœud de dispositif pour permettre une installation sans surveillance sur votre dispositif.
  • URL permettant d'effectuer l'échange initial d'informations d'identification du dispositif.
  • Un utilisateur ou un groupe d'utilisateurs.
Note

Vous pouvez également ajouter toute autre personnalisation nécessaire à votre image.

Pour créer un modèle d'image simplifiée RHEL for Edge dans l'interface utilisateur graphique du constructeur d'images, procédez comme suit :

Conditions préalables

Procédure

  1. Cliquez sur Créer un plan dans le coin supérieur droit de l'application de création d'images.

    Un assistant de dialogue contenant des champs pour le nom et la description du plan s'ouvre.

  2. Sur la page Details:

    1. Saisissez le nom du plan et, éventuellement, sa description. Cliquez sur Suivant.
  3. En option : Sur la page Packages, effectuez les étapes suivantes :

    1. Dans la recherche Available packages, saisissez le nom du paquet et cliquez sur le bouton > pour le déplacer dans le champ Paquets choisis. Recherchez et incluez autant de paquets que vous le souhaitez. Cliquez sur Suivant.

      Note

      Les personnalisations sont toutes facultatives, sauf indication contraire.

  4. Facultatif : Sur la page Kernel, entrez un nom de noyau et les arguments de la ligne de commande.
  5. Facultatif : Sur la page File system, vous pouvez sélectionner Use automatic partitioning ou Manually configure partitions pour votre système de fichiers image. Pour configurer manuellement les partitions, procédez comme suit :

    1. Cliquez sur le bouton Configurer manuellement les partitions.

      La section Configurer les partitions s'ouvre, montrant la configuration basée sur les standards et les guides de sécurité de Red Hat.

    2. Dans le menu déroulant, fournissez les détails pour configurer les partitions :

      1. Dans le champ Mount point, sélectionnez l'une des options de type de point de montage suivantes :

        • / - le point de montage racine
        • /var
        • /home
        • /opt
        • /srv
        • /usr
        • /app
        • /data
        • /tmp
        • /usr/local

          Vous pouvez également ajouter un chemin supplémentaire au Mount point, tel que /tmp. Par exemple : /var comme préfixe et /tmp comme chemin supplémentaire donne /var/tmp.

          Note

          Selon le type de point de montage choisi, le type de système de fichiers devient xfs, et ainsi de suite.

      2. Dans le champ Minimum size partition du système de fichiers, entrez la taille minimale de partition souhaitée. Dans le menu déroulant Taille minimale, vous pouvez utiliser des unités de taille courantes telles que GiB, MiB ou KiB. L'unité par défaut est GiB.

        Note

        Minimum size signifie que le constructeur d'images peut encore augmenter la taille des partitions, au cas où elles seraient trop petites pour créer une image fonctionnelle.

    3. Pour ajouter d'autres partitions, cliquez sur le bouton Ajouter une partition. Si le message d'erreur suivant s'affiche : "Duplicate partitions : Une seule partition peut être créée à chaque point de montage", vous pouvez.. :

      1. Cliquez sur le bouton Supprimer pour supprimer la partition dupliquée.
      2. Choisissez un nouveau point de montage pour la partition que vous souhaitez créer.
    4. Après avoir terminé la configuration du partitionnement, cliquez sur Suivant.
  6. Optionnel : Sur la page Services, vous pouvez activer ou désactiver des services :

    1. Saisissez les noms des services que vous souhaitez activer ou désactiver, en les séparant par une virgule, un espace ou en appuyant sur la touche Entrée. Cliquez sur Suivant.
  7. Facultatif : Sur la page Firewall, configurez votre pare-feu :

    1. Saisissez l'adresse Ports et les services de pare-feu que vous souhaitez activer ou désactiver.
    2. Cliquez sur le bouton Ajouter une zone pour gérer vos règles de pare-feu pour chaque zone indépendamment. Cliquez sur Suivant.
  8. Sur la page Users, ajoutez un utilisateur en suivant les étapes suivantes :

    1. Cliquez sur Ajouter un utilisateur.
    2. Saisissez un Username, un password et un SSH key. Vous pouvez également marquer l'utilisateur en tant qu'utilisateur privilégié en cochant la case Server administrator.

      Note

      Lorsque vous spécifiez l'utilisateur dans la personnalisation du plan et que vous créez ensuite une image à partir de ce plan, le plan crée l'utilisateur dans le répertoire /usr/lib/passwd et le mot de passe dans le répertoire /usr/etc/shadow au moment de l'installation. Vous pouvez vous connecter à l'appareil avec le nom d'utilisateur et le mot de passe que vous avez créés pour le modèle. Après avoir accédé au système, vous devez créer des utilisateurs, par exemple à l'aide de la commande useradd.

      Cliquez sur Suivant.

  9. Facultatif : Sur la page Groups, ajoutez des groupes en suivant les étapes suivantes :

    1. Cliquez sur le bouton Ajouter des groupes:

      1. Saisissez un Group name et un Group ID. Vous pouvez ajouter d'autres groupes. Cliquez sur Suivant.
  10. Facultatif : Sur la page SSH keys, ajoutez une clé :

    1. Cliquez sur le bouton Ajouter une clé.

      1. Entrez la clé SSH.
      2. Saisissez une adresse User. Cliquez sur Suivant.
  11. Facultatif : Sur la page Timezone, définissez vos paramètres de fuseau horaire :

    1. Dans le champ Timezone, entrez le fuseau horaire que vous souhaitez ajouter à votre image système. Par exemple, ajoutez le format de fuseau horaire suivant : "US/Eastern".

      Si vous ne définissez pas de fuseau horaire, le système utilise par défaut le temps universel coordonné (UTC).

    2. Saisissez les serveurs NTP. Cliquez sur Suivant.
  12. En option : Sur la page Locale, effectuez les étapes suivantes :

    1. Dans le champ de recherche Keyboard, saisissez le nom du paquet que vous souhaitez ajouter à votre image système. Par exemple, [\N- "en_US.UTF-8\N"] : [\N-"en_US.UTF-8\N"].
    2. Dans le champ de recherche Languages, saisissez le nom du paquet que vous souhaitez ajouter à votre image système. Par exemple : "us". Cliquez sur Suivant.
  13. Obligatoire : Sur la page Others, effectuez les étapes suivantes :

    1. Dans le champ Hostname, saisissez le nom d'hôte que vous souhaitez ajouter à votre image système. Si vous n'ajoutez pas de nom d'hôte, le système d'exploitation détermine le nom d'hôte.
    2. Obligatoire : Dans le champ Installation Devices, entrez un nœud valide pour votre image système afin de permettre une installation sans surveillance sur votre appareil. Par exemple : dev/sda1. Cliquez sur Suivant.
  14. En option : Sur la page FIDO device onboarding, effectuez les étapes suivantes :

    1. Dans le champ Manufacturing server URL, entrez le manufacturing server URL pour effectuer l'échange initial d'informations d'identification du dispositif, par exemple : "http://10.0.0.2:8080". La personnalisation FDO dans les plans est facultative et vous pouvez créer votre image RHEL for Edge Simplified Installer sans erreur.
    2. Dans le champ DIUN public key insecure, saisissez le hachage de la clé publique de certification pour effectuer l'échange initial d'informations d'identification de l'appareil. Ce champ accepte la valeur "true", ce qui signifie qu'il s'agit d'une connexion non sécurisée au serveur de fabrication. Par exemple : manufacturing_server_url="http://${FDO_SERVER}:8080" diun_pub_key_insecure="true". Vous ne devez utiliser qu'une seule de ces trois options : \N "key insecure\N", \N "key hash\N" et \N "key root certs\N".
    3. Dans le champ DIUN public key hash, entrez la version hachée de votre clé publique. Par exemple : 17BD05952222C421D6F1BB1256E0C925310CED4CE1C4FFD6E5CB968F4B73BF73. Vous pouvez obtenir le hachage de la clé en le générant à partir du certificat du serveur de fabrication. Pour générer le hachage de la clé, exécutez la commande suivante :

      # openssl x509 -fingerprint -sha256 -noout -in /etc/fdo/aio/keys/diun_cert.pem | cut -d"=" -f2 | sed 's/://g'

      Le site /etc/fdo/aio/keys/diun_cert.pem est le certificat qui est stocké dans le serveur de fabrication.

    4. Dans le champ DIUN public key root certs, entrez la clé publique des certificats racine. Ce champ accepte le contenu du fichier de certification qui est stocké dans le serveur de fabrication. Pour obtenir le contenu du fichier de certification, exécutez la commande suivante :

      $ cat /etc/fdo/aio/keys/diun_cert.pem.
  15. Cliquez sur Suivant.
  16. Sur la page Review, passez en revue les détails du projet. Cliquez sur Créer.

La vue du constructeur d'images s'ouvre et répertorie les plans existants.

6.6. Création d'une image RHEL for Edge Simplified Installer à l'aide de l'interface graphique du constructeur d'images

Pour créer une image RHEL for Edge Simplified à l'aide de l'interface graphique du constructeur d'images, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

Procédure

  1. Accéder au tableau de bord du constructeur de mages.
  2. Dans la table des plans, recherchez le plan pour lequel vous souhaitez créer une image.
  3. Naviguez jusqu'à l'onglet Images et cliquez sur Create Image. L'assistant Create image s'ouvre.
  4. Sur la page Image output, effectuez les étapes suivantes :

    1. Dans la liste Select a blueprint, sélectionnez le plan que vous avez créé pour l'image RHEL for Edge Simplified.
    2. Dans la liste Image output type, sélectionnez RHEL for Edge Simplified Installer (.iso).
    3. Dans le champ Image Size, entrez la taille de l'image. La taille minimale requise pour l'image de l'installateur simplifié est de :
  5. Cliquez sur Suivant.
  6. Dans la page OSTree settings, effectuez les étapes suivantes :

    1. Dans le champ Repository URL, saisissez l'URL du référentiel à partir duquel le commit OSTree parent sera extrait.
    2. Dans le champ Ref, entrez le chemin du nom de la branche ref. Si vous n'entrez pas de ref, le ref par défaut de la distribution est utilisé.
  7. Sur la page Review, vérifiez la personnalisation de l'image et cliquez sur Créer.

La construction de l'image démarre et dure jusqu'à 20 minutes. Pour arrêter la construction, cliquez sur Arrêter la construction.

6.7. Téléchargement d'une image simplifiée de RHEL for Edge à l'aide de l'interface graphique de création d'image

Pour télécharger une image RHEL for Edge à l'aide de l'interface graphique du constructeur d'images, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Vous avez créé avec succès une image RHEL for Edge. Voir le lien.

Procédure

  1. Accédez au tableau de bord image builder. Le tableau de bord de la liste des plans s'ouvre.
  2. Dans le tableau des plans, recherchez le plan pour lequel vous avez créé l'image de l'installateur simplifié de RHEL for Edge.
  3. Naviguez jusqu'à l'onglet Images.
  4. Choisissez l'une des options :

    • Télécharger l'image.
    • Téléchargez les journaux de l'image pour inspecter les éléments et vérifier s'il y a un problème.
Note

Vous pouvez utiliser l'image ISO de l'installateur simplifié de RHEL for Edge que vous avez téléchargée directement comme ISO de démarrage pour installer un système RHEL for Edge.

6.8. Mise en place d'un serveur d'amorçage HTTP UEFI

Pour configurer un serveur UEFI HTTP Boot, afin de pouvoir commencer à provisionner une machine virtuelle RHEL for Edge sur le réseau en se connectant à ce serveur UEFI HTTP Boot, procédez comme suit :

Conditions préalables

  • Vous avez créé l'image d'installation simplifiée ISO.
  • Un serveur http qui sert le contenu ISO.

Procédure

  1. Montez l'image ISO dans le répertoire de votre choix :

    # mkdir /mnt/rhel9-install/
    # mount -o loop,ro -t iso9660 /path_directory/installer.iso /mnt/rhel9-install/

    Remplacez /path_directory/installer.iso par le chemin d'accès à l'image ISO amorçable RHEL for Edge.

  2. Copiez les fichiers de l'image montée à la racine du serveur HTTP. Cette commande crée le répertoire /var/www/html/rhel9-install/ avec le contenu de l'image.

    # mkdir /var/www/html/httpboot/
    # cp -R /mnt/rhel9-install/* /var/www/html/httpboot/
    # chmod -R +r /var/www/html/httpboot/*
    Note

    Certaines méthodes de copie peuvent ignorer le fichier .treeinfo qui est nécessaire pour une source d'installation valide. L'exécution de la commande cp pour des répertoires entiers, comme indiqué dans cette procédure, copiera correctement .treeinfo.

  3. Mettre à jour le fichier /var/www/html/EFI/BOOT/grub.cfg en remplaçant

    1. coreos.inst.install_dev=/dev/sda avec coreos.inst.install_dev=/dev/vda
    2. linux /images/pxeboot/vmlinuz avec linuxefi /images/pxeboot/vmlinuz
    3. initrd /images/pxeboot/initrd.img avec initrdefi /images/pxeboot/initrd.img
    4. coreos.inst.image_file=/run/media/iso/disk.img.xz avec coreos.inst.image_url=http://{IP-ADDRESS}/disk.img.xz

      L'adresse IP-ADDRESS est l'adresse IP de cette machine, qui servira de serveur de démarrage http.

  4. Démarrez le service httpd :

    # systemctl start httpd.service

    Par conséquent, après avoir configuré un serveur UEFI HTTP Boot, vous pouvez installer votre RHEL for Edge à l'aide de UEFI HTTP boot.

6.9. Déployer l'image ISO simplifiée dans une machine virtuelle

Déployez l'image ISO RHEL for Edge que vous avez générée en créant une image RHEL for Edge Simplified à l'aide de l'une des sources d'installation suivantes :

  • UEFI HTTP Boot
  • virt-install

Cet exemple montre comment créer une source d'installation virt-install à partir de votre image ISO pour une installation network-based.

Conditions préalables

  • Vous avez créé une image ISO.
  • Vous mettez en place une configuration réseau pour prendre en charge le démarrage HTTP de l'UEFI.

Procédure

  1. Mettez en place une configuration réseau pour prendre en charge le démarrage de UEFI HTTP. Voir Configuration du démarrage HTTP UEFI avec libvirt.
  2. Utilisez la commande virt-install pour créer une machine virtuelle RHEL for Edge à partir de l'UEFI HTTP Boot.

    # virt-install \
        --name edge-install-image \
        --disk path=”  “, ,format=qcow2
        --ram 3072 \
        --memory 4096 \
        --vcpus 2 \
        --network network=integration,mac=mac_address \
        --os-type linux
        --os-variant rhel9 \
        --cdrom "/var/lib/libvirt/images/”ISO_FILENAME"
        --boot uefi,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/edk2/ovmf/OVMF_VARS.fd,loader_secure=no
        --virt-type kvm \
        --graphics none \
         --wait=-1
         --noreboot

Une fois la commande exécutée, l'installation de la machine virtuelle démarre.

Vérification

  • Connectez-vous à la machine virtuelle créée.

6.10. Déployer l'image ISO simplifiée à partir d'une clé USB

Déployez l'image ISO RHEL for Edge que vous avez générée en créant une image RHEL for Edge Simplified à l'aide de USB installation.

Cet exemple montre comment créer une source USB installation à partir de votre image ISO.

Conditions préalables

  • Vous avez créé une image d'installation simplifiée, qui est une image ISO.
  • Vous disposez d'une clé USB de 8 Go.

Procédure

  1. Copiez le fichier image ISO sur une clé USB.
  2. Connectez la clé USB au port de l'ordinateur que vous souhaitez démarrer.
  3. Démarrez l'image ISO à partir de la clé USB. Le menu de démarrage vous propose les options suivantes :

    Install Red Hat Enterprise Linux 9
    Test this media & install Red Hat Enterprise Linux 9
  4. Choisissez Installer Red Hat Enterprise Linux 9, ce qui lance l'installation du système.

Ressources supplémentaires

Chapitre 7. Utilisation de l'outil Ignition pour les images de l'installateur simplifié RHEL for Edge

RHEL for Edge utilise l'outil Ignition pour injecter la configuration utilisateur dans les images à un stade précoce du processus de démarrage. La configuration utilisateur injectée par l'outil Ignition comprend les éléments suivants :

  • La configuration de l'utilisateur.
  • Écriture de fichiers, tels que les fichiers ordinaires, et systemd unités.

Au premier démarrage, Ignition lit sa configuration soit à partir d'une URL distante, soit à partir d'un fichier intégré dans l'ISO de l'installateur simplifié. Ensuite, Ignition applique cette configuration à l'image.

7.1. Création d'un fichier de configuration Ignition

L'outil Butane est l'option préférée pour créer un fichier de configuration Ignition. Butane consomme un fichier Butane Config YAML et produit un fichier Ignition Config au format JSON. Le fichier JSON est utilisé par un système lors de son premier démarrage. Le fichier Ignition Config applique la configuration de l'image, comme la création d'utilisateurs et l'installation des unités systemd.

Conditions préalables

  • Vous avez installé l'outil Butane version v0.17.0 :

    $ sudo dnf/yum install -y butane

Procédure

  1. Créez un fichier Butane Config et enregistrez-le au format .bu. Vous devez spécifier l'entrée variant comme r4e, et l'entrée version comme 1.0.0, pour les images RHEL for Edge. La variante Butane r4e de la version 1.0.0 cible la version 3.3.0 des spécifications d'Ignition. Voici un exemple de fichier YAML de Butane Config :

    variant: r4e
    version: 1.0.0
    ignition:
      config:
        merge:
          - source: http://192.168.122.1:8000/sample.ign
    passwd:
      users:
        - name: core
          groups:
            - wheel
          password_hash: password_hash_here
          ssh_authorized_keys:
            - ssh-ed25519 some-ssh-key-here
    storage:
      files:
        - path: /etc/NetworkManager/system-connections/enp1s0.nmconnection
          contents:
            inline: |
              [connection]
              id=enp1s0
              type=ethernet
              interface-name=enp1s0
              [ipv4]
              address1=192.168.122.42/24,192.168.122.1
              dns=8.8.8.8;
              dns-search=
              may-fail=false
              method=manual
          mode: 0600
        - path: /usr/local/bin/startup.sh
          contents:
            inline: |
              #!/bin/bash
              echo "Hello, World!"
          mode: 0755
    systemd:
      units:
        - name: hello.service
          contents: |
            [Unit]
            Description=A hello world
            [Install]
            WantedBy=multi-user.target
          enabled: true
        - name: fdo-client-linuxapp.service
          dropins:
            - name: log_trace.conf
              contents: |
                [Service]
                Environment=LOG_LEVEL=trace
  2. Exécutez la commande suivante pour consommer le fichier Butane Config YAML et générer une Ignition Config au format JSON :

    $ ./path/butane example.bu
    {"ignition":{"config":{"merge":[{"source":"http://192.168.122.1:8000/sample.ign"}]},"timeouts":{"httpTotal":30},"version":"3.3.0"},"passwd":{"users":[{"groups":["wheel"],"name":"core","passwordHash":"password_hash_here","sshAuthorizedKeys":["ssh-ed25519 some-ssh-key-here"]}]},"storage":{"files":[{"path":"/etc/NetworkManager/system-connections/enp1s0.nmconnection","contents":{"compression":"gzip","source":"data:;base64,H4sIAAAAAAAC/0yKUcrCMBAG3/csf/ObUKQie5LShyX5SgPNNiSr0NuLgiDzNMPM8VBFtHzoQjkxtPp+ITsrGLahKYyyGtoqEYNKwfeZc32OC0lKDb179rfg/HVyPgQ3hv8w/v0WT0k7T+7D/S1Dh7S4MRU5h1XyzqvsHVRg25G4iD5kp1cAAAD//6Cvq2ihAAAA"},"mode":384},{"path":"/usr/local/bin/startup.sh","contents":{"source":"data:;base64,IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8sIFdvcmxkISIK"},"mode":493}]},"systemd":{"units":[{"contents":"[Unit]\nDescription=A hello world\n[Install]\nWantedBy=multi-user.target","enabled":true,"name":"hello.service"},{"dropins":[{"contents":"[Service]\nEnvironment=LOG_LEVEL=trace\n","name":"log_trace.conf"}],"name":"fdo-client-linuxapp.service"}]}}

    Après avoir exécuté le fichier Butane Config YAML pour vérifier et générer le fichier Ignition Config JSON, vous pouvez recevoir des avertissements lorsque vous utilisez des champs non pris en charge, comme les partitions, par exemple. Vous pouvez corriger ces champs et réexécuter la vérification.

Vous avez maintenant un fichier de configuration Ignition JSON que vous pouvez utiliser pour personnaliser votre plan.

Ressources supplémentaires

7.2. Création d'un plan dans l'interface graphique avec le support d'Ignition

Lorsque vous créez une image d'installateur simplifié, vous pouvez personnaliser votre plan en saisissant les informations suivantes dans la page Ignition du plan :

  • Firstboot URL - Vous devez entrer une URL qui pointe vers la configuration Ignition qui sera récupérée lors du premier démarrage. Elle peut être utilisée à la fois pour l'image brute et pour l'image d'installation simplifiée.
  • Embedded Data - Vous devez fournir le fichier encodé base64 Ignition Configuration . Il ne peut être utilisé que pour l'image de l'installateur simplifié.

Pour personnaliser votre plan pour une image RHEL for Edge simplifiée avec prise en charge de la configuration Ignition à l'aide de la personnalisation du plan Ignition, procédez comme suit :

Conditions préalables

Procédure

  1. Cliquez sur Créer un plan dans le coin supérieur droit.

    Un assistant de dialogue contenant des champs pour le nom et la description du plan s'ouvre.

    • Sur la page Details:

      • Saisissez le nom du plan et, éventuellement, sa description. Cliquez sur Suivant.
    • Sur la page Ignition, effectuez les étapes suivantes :

      • Dans le champ Firstboot URL, entrez l'URL qui pointe vers la configuration d'Ignition à récupérer lors du premier démarrage.
      • Dans le champ Embedded Data, faites glisser ou téléchargez le fichier Ignition Configuration encodé base64. Cliquez sur Suivant.
    • Examinez les détails de l'image et cliquez sur Créer.

La vue du tableau de bord du constructeur d'images s'ouvre et répertorie les plans existants.

Suivant

7.3. Création d'un plan avec support pour Ignition en utilisant l'interface de programmation (CLI)

Lorsque vous créez une image d'installation simplifiée, vous pouvez personnaliser votre plan en y ajoutant la section customizations.ignition. Vous pouvez ainsi créer une image d'installation simplifiée ou une image brute que vous pouvez utiliser pour les plates-formes bare metal. La personnalisation de customizations.ignition dans le plan permet aux fichiers de configuration d'être utilisés dans les images ISO edge-simplified-installer et edge-raw-image.

  • Pour l'image ISO edge-simplified-installer, vous pouvez personnaliser le plan pour intégrer un fichier de configuration Ignition qui sera inclus dans l'image ISO. Par exemple :

    [customizations.ignition.embedded]
    config = "eyJ --- BASE64 STRING TRIMMED --- 19fQo="

    Vous devez fournir un fichier de configuration Ignition encodé base64.

  • Pour l'image ISO edge-simplified-installer comme pour l'image edge-raw-image, vous pouvez personnaliser le plan, en définissant une URL qui sera recherchée pour obtenir la configuration d'Ignition au premier démarrage. Par exemple, vous pouvez définir une URL qui sera recherchée pour obtenir la configuration d'Ignition au premier démarrage :

    [customizations.ignition.firstboot]
    url = "http://your_server/ignition_configuration.ig"

    Vous devez entrer une URL qui pointe vers la configuration d'Ignition qui sera récupérée lors du premier démarrage.

Pour personnaliser votre plan pour une image Simplified RHEL for Edge avec prise en charge de la configuration Ignition, procédez comme suit :

Conditions préalables

  • Si vous utilisez la personnalisation [customizations.ignition.embedded], vous devez créer un fichier de configuration Ignition.
  • Si vous utilisez la personnalisation [customizations.ignition.firstboot], vous devez avoir créé un conteneur dont l'URL pointe vers la configuration Ignition qui sera récupérée lors du premier démarrage.
  • La section de personnalisation du plan [customizations.ignition.embedded] permet à coreos-installer-dracut de définir -ignition-url|-ignition-file en fonction de la présence du fichier osbuild.

Procédure

  1. Créez un fichier texte en clair au format Tom's Obvious, Minimal Language (TOML), avec le contenu suivant :

    name = "simplified-installer-blueprint"
    description = "Blueprint with Ignition for the simplified installer image"
    version = "0.0.1"
    packages = []
    modules = []
    groups = []
    distro = ""
    
    [customizations.ignition.embedded]
    config = "eyJ --- BASE64 STRING TRIMMED --- 19fQo="

    Où ?

    • name est le nom et description est la description de votre plan.
    • Le site version est le numéro de version selon le schéma de versionnement sémantique.
    • Les adresses modules et packages décrivent le nom du paquet et la version correspondante à installer dans l'image. Par exemple, le paquet name = "tmux" et la version correspondante sont version = "3.3a". Notez qu'il n'y a actuellement aucune différence entre les paquets et les modules.
    • Les groups sont des groupes de paquets à installer dans l'image. Par exemple, groups = "anaconda-tools" est un groupe de paquets. Si vous ne connaissez pas les modules et les groupes, laissez-les vides.

      Avertissement

      Si vous voulez créer un utilisateur avec Ignition, vous ne pouvez pas utiliser les personnalisations FDO pour créer un utilisateur en même temps. Vous pouvez créer des utilisateurs avec Ignition et copier des fichiers de configuration avec FDO. Mais si vous créez des utilisateurs, créez-les avec Ignition ou FDO, mais pas les deux en même temps.

  2. Pousser (importer) le plan vers le serveur de construction d'images :

    # composer-cli blueprints push blueprint-name.toml
  3. Liste les plans existants pour vérifier si le plan créé a été poussé avec succès et s'il existe.

    # composer-cli blueprints show blueprint-name
  4. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve blueprint-name

Suivant

Ressources supplémentaires

Chapitre 8. Approvisionnement automatique et onboarding de RHEL for Edge avec FDO

Vous pouvez créer une image RHEL for Edge Simplified Installer et l'intégrer à une image RHEL for Edge. Le processus FIDO device onboarding (FDO) permet de provisionner et d'embarquer automatiquement vos appareils Edge et d'échanger des données avec d'autres appareils et systèmes connectés sur les réseaux.

Important

Red Hat fournit le processus FDO en tant que fonctionnalité d'aperçu technologique et devrait être exécuté sur des réseaux sécurisés. Les fonctionnalités d'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement. Voir Technology Preview Features Support Scope sur le portail client de Red Hat pour plus d'informations sur l'étendue de l'assistance pour les fonctionnalités Technology Preview.

8.1. Le processus d'intégration des dispositifs FIDO (FDO)

L'intégration de l'appareil est le processus qui :

  • Dispositions et embarquement d'un dispositif physique.
  • Configure automatiquement les informations d'identification pour ce périphérique.
  • Permet à cet appareil de se connecter et d'interagir en toute sécurité sur le réseau.

Avec FIDO device onboarding (FDO), vous pouvez effectuer un onboarding sécurisé des appareils en ajoutant de nouveaux appareils à votre architecture IOT. Il s'agit notamment de la configuration spécifiée des appareils qui doit être approuvée et intégrée au reste des systèmes en cours d'exécution et de déployer de nouveaux systèmes prêts à être utilisés. L'authentification FDO est un processus d'intégration automatique qui est déclenché par l'installation d'un nouveau dispositif afin d'intégrer un dispositif en toute sécurité. Le protocole FDO résout le problème de la confiance et de la chaîne de propriété, ainsi que l'automatisation nécessaire à l'intégration sécurisée d'un appareil à grande échelle. Il effectue l'initialisation de l'appareil au stade de la fabrication et la liaison tardive de l'appareil pour son utilisation effective. Cela signifie que la liaison effective de l'appareil à un système de gestion a lieu lors du premier démarrage de l'appareil, sans qu'il soit nécessaire de procéder à une configuration manuelle de l'appareil. L'utilisation du protocole FDO permet de prendre en charge l'intégration automatisée des dispositifs sécurisés, c'est-à-dire l'installation et l'intégration sans contact qui ne nécessitent pas la présence d'une personne spécialisée à l'extrémité de l'appareil. Une fois le dispositif intégré, vous pouvez vous y connecter et appliquer des correctifs, des mises à jour et des retours en arrière.

Avec FDO, vous pouvez bénéficier des avantages suivants :

  • FDO est un moyen sûr et simple d'enrôler un appareil dans une plateforme de gestion. Au lieu d'intégrer une configuration Kickstart à l'image, FDO applique la personnalisation, telle que l'inclusion de données sensibles comme les identifiants, les clés ou les certificats, directement à l'image ISO.
  • FDO résout le problème de la liaison tardive à un appareil, ce qui permet de partager toutes les données sensibles sur un canal FDO sécurisé.
  • FDO identifie cryptographiquement l'identité et la propriété du système avant d'enregistrer et de transmettre la configuration et d'autres secrets au système. Cela permet aux utilisateurs non techniques de mettre le système sous tension.

Pour créer une image RHEL for Edge Simplified Installer et l'intégrer automatiquement, fournissez un commit OSTree existant. L'image simplifiée qui en résulte contient une image brute dans laquelle le commit OSTree a été déployé. Une fois que vous avez démarré l'image ISO de l'installateur simplifié, elle fournit un système RHEL for Edge que vous pouvez utiliser sur un disque dur ou en tant qu'image de démarrage dans une machine virtuelle.

L'image RHEL for Edge Simplified Installer est optimisée pour une installation sans surveillance sur un périphérique et prend en charge à la fois les déploiements basés sur le réseau et les déploiements non basés sur le réseau. Toutefois, pour les déploiements basés sur le réseau, elle ne prend en charge que le démarrage UEFI HTTP.

Le protocole FDO est basé sur les serveurs suivants :

  • Serveur de fabrication

    Ce serveur se trouve à l'emplacement du serveur du fabricant. Le serveur de fabrication :

    1. Signe le dispositif.
    2. Crée un bon qui est utilisé pour définir la propriété de l'appareil, plus tard dans le processus.
    3. Lier l'appareil à une plate-forme de gestion spécifique.
  • Serveur de rendez-vous

    Ce serveur se trouve à l'emplacement du serveur du propriétaire ou sur la plateforme où le système de gestion des appareils sera situé, par exemple dans un nuage. Le serveur Rendezvous :

    1. Obtient le bon généré par le serveur de fabrication lors du premier démarrage de l'appareil.
    2. Fait correspondre l'UUID de l'appareil avec une plate-forme cible et fournit des informations à l'appareil sur le point de terminaison du serveur Owner qu'il doit utiliser.
  • Serveur de gestion des propriétaires

    Ce serveur se trouve sur le site du serveur du propriétaire ou sur la plate-forme où l'appareil sera déployé. Le serveur de gestion du propriétaire :

    1. Crée un canal sécurisé entre l'appareil et le serveur du propriétaire après l'authentification de l'appareil.
    2. Utilise le canal sécurisé pour envoyer au dispositif les informations requises, telles que les fichiers et les scripts pour l'automatisation de l'accueil.
  • Client de l'appareil

    Il s'agit du serveur installé sur l'appareil. Le client de l'appareil

    1. Lance les requêtes vers les multiples serveurs où l'automatisation de l'onboarding sera exécutée.
    2. Utilise les protocoles TCP/IP pour communiquer avec les serveurs.

Le diagramme suivant représente le processus d'intégration des dispositifs FIDO :

Figure 8.1. Déploiement de RHEL for Edge dans un environnement hors réseau

FDO device onboarding

Sur le site Manufacturer server, l'appareil reçoit les informations d'identification FDO, un ensemble de certificats et de clés à installer sur le système d'exploitation, ainsi que le point d'extrémité du serveur Rendezvous (URL). Il reçoit également le bon de propriété, qui est conservé séparément au cas où vous auriez besoin de modifier l'affectation du propriétaire.

  1. Le client de l'appareil lit les informations d'identification de l'appareil
  2. L'appareil client se connecte au réseau
  3. À un stade précoce, le système de gestion du propriétaire informe le serveur de rendez-vous du fabricant de l'emplacement du système de gestion du propriétaire
  4. Après s'être connecté au réseau, le client de l'appareil contacte le serveur de rendez-vous
  5. Le serveur Rendezvous envoie l'URL du point de terminaison du propriétaire au client du périphérique et enregistre le périphérique. Cette action permet de connecter et de démarrer l'appareil.
  6. Le client du dispositif se connecte au système de gestion du propriétaire partagé par le serveur Rendezvous, prouve qu'il s'agit du bon dispositif en signant une déclaration avec une clé de dispositif
  7. Le système de gestion du propriétaire fait ses preuves en signant une déclaration avec la dernière clé du bon du propriétaire
  8. Le système de gestion des propriétaires fournit la configuration de l'appareil, que le client de l'appareil stocke, par exemple, dans une clé SSH
  9. Le client du dispositif reçoit et vérifie le justificatif de propriété
  10. Ensuite, le client de l'appareil récupère ses informations d'identification de l'appareil
  11. Ensuite, le système de gestion des propriétaires signale que le client du dispositif a été intégré

    L'ensemble du processus FDO est terminé et n'est plus utilisé dans ce dispositif.

8.2. Approvisionnement automatique et mise en service de RHEL pour les appareils Edge

Le provisionnement automatique et l'intégration d'un dispositif RHEL for Edge impliquent les étapes de haut niveau suivantes :

  1. Installer et enregistrer un système RHEL
  2. Installer le constructeur d'images
  3. À l'aide de l'outil de création d'images, créez un modèle avec des personnalisations pour l'image RHEL for Edge Container
  4. Importer le plan RHEL for Edge dans le constructeur d'images
  5. Créer une image RHEL for Edge intégrée dans un conteneur OCI avec un serveur web prêt à déployer le commit en tant que dépôt OSTree
  6. Créer un modèle pour edge-simplified-installer avec des personnalisations pour les chemins d'accès aux périphériques de stockage et les personnalisations FDO

    name = "fdo"
    description = "FDO blueprint"
    version = "0.0.1"
    packages = []
    modules = []
    groups = []
    distro = ""
    
    [customizations]
    installation_device = "/dev/vda"
    
    [customizations.fdo]
    manufacturing_server_url = "http://10.0.0.2:8080"
    diun_pub_key_insecure = "true"
  7. Construire une image d'installation simplifiée de RHEL for Edge
  8. Télécharger l'image d'installation simplifiée de RHEL for Edge
  9. Installer l'image ISO de l'installateur simplifié sur un périphérique. Le client FIDO FDO fonctionne sur l'image ISO de l'installateur simplifié et la structure de répertoire UEFI rend l'image amorçable.
  10. La configuration du réseau permet à l'appareil d'atteindre le serveur de fabrication pour procéder à l'échange initial des données d'identification de l'appareil.
  11. Une fois que le système a atteint le point d'extrémité, les informations d'identification du périphérique sont créées pour ce dernier.
  12. Le serveur embarqué utilise les informations d'identification de l'appareil pour s'authentifier auprès du serveur embarqué. le serveur d'intégration transmet la configuration à l'appareil ou au système. Après s'être connecté au système, celui-ci se connecte au serveur d'accueil et reçoit la configuration.
  13. Le serveur d'accueil fournit à l'appareil une clé SSH et installe le système.
  14. Ensuite, il redémarre le système et le chiffre à l'aide d'une clé forte stockée dans le TPM.
  15. Vous pouvez vous connecter au système avec les informations d'identification que vous avez configurées dans le fichier de configuration de l'API des informations de service et vérifier la configuration qui a été créée dans l'image ISO de l'installateur simplifié.

Ressources supplémentaires

8.3. Génération de clés et de certificats

Pour faire fonctionner l'infrastructure FIDO device onboarding (FDO), vous devez générer des clés et des certificats. FDO génère ces clés et ces certificats pour configurer le serveur de fabrication. FDO génère automatiquement les certificats et les fichiers de configuration .yaml lorsque vous installez les services, et les recréer est facultatif. Une fois les services installés et démarrés, ils s'exécutent avec les paramètres par défaut.

Important

Red Hat fournit l'outil fdo-admin-tool generate-key-and-cert en tant que fonctionnalité d'aperçu technologique et devrait être exécuté sur des réseaux sécurisés. Les fonctionnalités d'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement. Voir Technology Preview Features Support Scope sur le portail client de Red Hat pour plus d'informations sur l'étendue de l'assistance pour les fonctionnalités Technology Preview.

Conditions préalables

  • Vous avez installé le paquetage RPM fdo-admin-cli

Procédure

  1. Créez un répertoire pour les clés et les certificats :

    $ mkdir /etc/fdo/keys
  2. Générer les clés et les certificats dans le répertoire /etc/fdo:

    $ for i in "diun" "manufacturer" "device-ca" "owner"; do fdo-admin-tool generate-key-and-cert $i; done
    $ ls keys
    device_ca_cert.pem device_ca_key.der diun_cert.pem diun_key.der manufacturer_cert.pem manufacturer_key.der owner_cert.pem owner_key.der
  3. Vérifiez la clé et les certificats qui ont été créés dans le répertoire /etc/fdo/keys:

    $ tree keys

    Vous pouvez voir le résultat suivant :

    – device_ca_cert.pem
    – device_ca_key.der
    – diun_cert.pem
    – diun_key.dre
    – manufacturer_cert.pem
    – manufacturer_key.der
    – owner_cert.pem
    – owner_key.pem

Ressources supplémentaires

  • Les fdo-admin-tool generate-key-and-cert –-help

8.4. Installation et fonctionnement du serveur de fabrication

Le paquet RPM de fdo-manufacturing-server fournit les informations d'identification nécessaires pour embarquer en toute sécurité sur l'appareil. Il stocke également d'autres composants, tels que les justificatifs du propriétaire, les clés du fabricant et les informations sur les sessions de fabrication. Lors de l'installation de l'appareil, le serveur de fabrication génère les informations d'identification de l'appareil spécifique, y compris son GUID, les informations de rendez-vous et d'autres métadonnées. Plus tard dans le processus, l'appareil utilise ces informations de rendez-vous pour contacter le serveur de rendez-vous.

Important

Red Hat fournit l'outil fdo-manufacturing-server en tant que fonctionnalité d'aperçu technologique et doit être exécuté sur des réseaux sécurisés car les fonctionnalités d'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement. Consultez la page Technology Preview Features Support Scope sur le portail client de Red Hat pour obtenir des informations sur la portée de l'assistance pour les fonctionnalités Technology Preview.

Pour installer le paquetage RPM manufacturing server, suivez les étapes suivantes :

Procédure

  1. Installez le paquetage fdo-admin-cli:

    # dnf install -y fdo-admin-cli
  2. Vérifier si le paquetage RPM fdo-manufacturing-server est installé :

    $ rpm -qa | grep fdo-manufacturing-server --refresh
  3. Vérifier si les fichiers ont été correctement installés :

    $ ls /usr/share/doc/fdo

    Vous pouvez voir le résultat suivant :

    Output:
    manufacturing-server.yml
    owner-onboarding-server.yml
    rendezvous-info.yml
    rendezvous-server.yml
    serviceinfo-api-server.yml
  4. Facultatif : Vérifiez le contenu de chaque fichier, par exemple :

    $ cat /usr/share/doc/fdo/manufacturing-server.yml
  5. Créez un répertoire pour chacun des composants : pièces justificatives du propriétaire, clés du fabricant et sessions de fabrication.

    # mkdir -p /etc/fdo/stores/manufacturer_keys
    # mkdir -p /etc/fdo/stores/manufacturing_sessions
    # mkdir -p /etc/fdo/stores/owner_vouchers
  6. Configurez le serveur de fabrication. Vous devez fournir les informations suivantes :

    • L'URL du serveur de fabrication
    • L'adresse IP ou le nom DNS du serveur de rendez-vous
    • Le chemin d'accès aux clés et aux certificats que vous avez générés. Voir la section Générer des clés et des certificats.

      Vous trouverez un exemple de fichier de configuration du serveur de fabrication dans le répertoire /usr/share/doc/fdo/manufacturing-server.yml. Le fichier suivant est un exemple de manufacturing server.yml qui est créé et sauvegardé dans le répertoire /etc/fdo. Il contient les chemins d'accès aux répertoires, certificats, clés que vous avez créés, l'adresse IP du serveur Rendezvous et le port par défaut.

      session_store_driver:
        Directory:
          path: /etc/fdo/stores/manufacturing_sessions/
      ownership_voucher_store_driver:
        Directory:
          path: /etc/fdo/stores/owner_vouchers
      public_key_store_driver:
        Directory:
          path: /etc/fdo/stores/manufacturer_keys
      bind: "0.0.0.0:8080"
      protocols:
        plain_di: false
        diun:
          mfg_string_type: SerialNumber
          key_type: SECP384R1
          allowed_key_storage_types:
            - Tpm
            - FileSystem
          key_path: /etc/fdo/keys/diun_key.der
          cert_path: /etc/fdo/keys/diun_cert.pem
      rendezvous_info:
        - deviceport: 8082
          ip_address: 192.168.122.99
          ownerport: 8082
          protocol: http
      manufacturing:
        manufacturer_cert_path: /etc/fdo/keys/manufacturer_cert.pem
        device_cert_ca_private_key: /etc/fdo/keys/device_ca_key.der
        device_cert_ca_chain: /etc/fdo/keys/device_ca_cert.pem
        owner_cert_path: /etc/fdo/keys/owner_cert.pem
        manufacturer_private_key: /etc/fdo/keys/manufacturer_key.der
  7. Démarrer le serveur de fabrication.

    1. Vérifier si le fichier de l'unité systemd se trouve sur le serveur :

      # systemctl list-unit-files | grep fdo | grep manufac
      fdo-manufacturing-server.service disabled disabled
    2. Activer et démarrer le serveur de fabrication.

      # systemctl enable --now fdo-manufacturing-server.service
    3. Ouvrez les ports par défaut de votre pare-feu :

      # firewall-cmd --add-port=8080/tcp --permanent
      # systemctl restart firewalld
    4. Assurez-vous que le service écoute sur le port 8080 :

      # ss -ltn
  8. Assurez-vous que toute votre infrastructure FDO est configurée et que le service systemd installé par le RPM fonctionne. Le serveur de fabrication se charge de créer et d'activer les informations d'identification sur le nouvel appareil.

    $ cat /usr/share/doc/fdo/manufacturing-server.yml
  9. Installez RHEL for Edge sur votre système à l'aide du programme d'installation simplifié. Voir Création d'images d'installation simplifiée pour provisionner une image RHEL for Edge.

8.5. Installation, configuration et fonctionnement du serveur Rendezvous

Installez le paquet RPM fdo-rendezvous-server pour permettre aux systèmes de recevoir le bon généré par le serveur de fabrication lors du premier démarrage de l'appareil. Le serveur Rendezvous fait ensuite correspondre l'UUID de l'appareil avec la plate-forme ou le nuage cible et informe l'appareil du point d'extrémité du serveur Owner qu'il doit utiliser.

Conditions préalables

  • Vous avez créé un certificat manufacturer_cert.pem. Voir Génération de clés et de certificats.
  • Vous avez copié le certificat manufacturer_cert.pem dans le répertoire /etc/fdo/keys du serveur Rendezvous.

Procédure

  1. Installez les paquets RPM fdo-rendezvous-server:

    # dnf install -y fdo-rendezvous-server
  2. Créez les répertoires pour stocker les répertoires suivants : le répertoire enregistré, où les bons des propriétaires d'appareils enregistrés seront hébergés, et le répertoire des sessions :

    # mkdir -p /etc/fdo/stores/rendezvous_registered
    # mkdir -p /etc/fdo/stores/rendezvous_sessions
  3. Créez le fichier de configuration rendezvous-server.yml, y compris le chemin d'accès au certificat du fabricant. Vous trouverez un exemple à l'adresse /usr/share/doc/fdo/rendezvous-server.yml. L'exemple suivant montre un fichier de configuration enregistré sur /etc/fdo/rendezvous-server.yml.

    storage_driver:
      Directory:
        path: /etc/fdo/stores/rendezvous_registered
    session_store_driver:
      Directory:
        path: /etc/fdo/stores/rendezvous_sessions
    trusted_manufacturer_keys_path: /etc/fdo/keys/manufacturer_cert.pem
    max_wait_seconds: ~
    bind: "0.0.0.0:8082"
  4. Vérifier l'état du service du serveur Rendezvous :

    # systemctl list-unit-files | grep fdo | grep rende
    fdo-rendezvous-server.service disabled disabled
    1. Si le service est arrêté et désactivé, activez-le et démarrez-le :

      # systemctl enable --now fdo-rendezvous-server.service
  5. Vérifiez que le serveur écoute sur le port 8082 configuré par défaut :

    # ss -ltn
  6. Ouvrez le port si un pare-feu est configuré sur ce serveur :

    # firewall-cmd --add-port=8082/tcp --permanent
    # systemctl restart firewalld

8.6. Installation, configuration et fonctionnement du serveur Owner

Installez les paquets RPM fdo-owner-cli et fdo-owner-onboarding-server pour permettre aux systèmes de recevoir le bon généré par le serveur de fabrication lors du premier démarrage de l'appareil. Le serveur Rendezvous fait ensuite correspondre l'UUID de l'appareil avec la plate-forme ou le nuage cible et informe l'appareil du point d'extrémité du serveur Owner qu'il doit utiliser.

Conditions préalables

  • Le dispositif sur lequel le serveur sera déployé dispose d'un module TPM (Trusted Platform Module) pour crypter le disque. Si ce n'est pas le cas, vous obtiendrez une erreur lors du démarrage de l'appareil RHEL for Edge.
  • Vous avez créé les répertoires device_ca_cert.pem, owner_key.der et owner_cert.pem avec des clés et des certificats et vous les avez copiés dans le répertoire /etc/fdo/keys.

Procédure

  1. Installez les RPMs nécessaires sur ce serveur :

    # dnf install -y fdo-owner-cli fdo-owner-onboarding-server
  2. Créez les répertoires supplémentaires dont le service Serveur du propriétaire a besoin :

    # mkdir -p /etc/fdo/stores/owner_vouchers
    # mkdir -p /etc/fdo/stores/owner_onboarding_sessions
  3. Préparez le fichier de configuration owner-onboarding-server.yml et enregistrez-le dans le répertoire /etc/fdo/. Incluez dans ce fichier le chemin d'accès aux certificats que vous avez déjà copiés et des informations sur l'endroit où publier le service du serveur Owner.

    L'exemple suivant est disponible à l'adresse /usr/share/doc/fdo/owner-onboarding-server.yml. Vous pouvez trouver des références à l'API Informations sur les services, telles que l'URL ou le jeton d'authentification.

    ---
    ownership_voucher_store_driver:
      Directory:
        path: /etc/fdo/stores/owner_vouchers
    session_store_driver:
      Directory:
        path: /etc/fdo/stores/owner_onboarding_sessions
    trusted_device_keys_path: /etc/fdo/keys/device_ca_cert.pem
    owner_private_key_path: /etc/fdo/keys/owner_key.der
    owner_public_key_path: /etc/fdo/keys/owner_cert.pem
    bind: "0.0.0.0:8081"
    service_info_api_url: "http://localhost:8083/device_info"
    service_info_api_authentication:
      BearerToken:
        token: Kpt5P/5flBkaiNSvDYS3cEdBQXJn2Zv9n1D50431/lo=
    owner_addresses:
      - transport: http
        addresses:
          - ip_address: 192.168.122.149
  4. Créer et configurer l'API des informations sur les services.

    1. Ajoutez les informations automatisées pour l'onboarding, telles que la création de l'utilisateur, les fichiers à copier ou à créer, les commandes à exécuter, le disque à crypter, etc. Utilisez l'exemple de fichier de configuration Service Info API dans /usr/share/doc/fdo/serviceinfo-api-server.yml comme modèle pour créer le fichier de configuration sous /etc/fdo/.

      ---
      service_info:
        initial_user:
          username: admin
          sshkeys:
          - "ssh-rsa AAAA...."
        files:
        - path: /root/resolv.conf
          source_path: /etc/resolv.conf
        commands:
        - command: touch
          args:
          - /root/test
          return_stdout: true
          return_stderr: true
        diskencryption_clevis:
        - disk_label: /dev/vda4
          binding:
            pin: tpm2
            config: "{}"
          reencrypt: true
        additional_serviceinfo: ~
      bind: "0.0.0.0:8083"
      device_specific_store_driver:
        Directory:
          path: /etc/fdo/stores/serviceinfo_api_devices
      service_info_auth_token: Kpt5P/5flBkaiNSvDYS3cEdBQXJn2Zv9n1D50431/lo=
      admin_auth_token: zJNoErq7aa0RusJ1w0tkTjdITdMCWYkndzVv7F0V42Q=
  5. Vérifier l'état des unités systemd :

    # systemctl list-unit-files | grep fdo
    fdo-owner-onboarding-server.service        disabled        disabled
    fdo-serviceinfo-api-server.service         disabled        disabled
    1. Si le service est arrêté et désactivé, activez-le et démarrez-le :

      # systemctl enable --now fdo-owner-onboarding-server.service
      # systemctl enable --now fdo-serviceinfo-api-server.service
      Note

      Vous devez redémarrer les services systemd chaque fois que vous modifiez les fichiers de configuration.

  6. Vérifiez que le serveur écoute sur le port 8083 configuré par défaut :

    # ss -ltn
  7. Ouvrez le port si un pare-feu est configuré sur ce serveur :

    # firewall-cmd --add-port=8081/tcp --permanent
    # firewall-cmd --add-port=8083/tcp --permanent
    # systemctl restart firewalld

8.7. Embarquement automatique d'un appareil RHEL for Edge à l'aide de l'authentification FDO

Pour préparer votre appareil à embarquer automatiquement un appareil RHEL for Edge et à le provisionner dans le cadre du processus d'installation, procédez comme suit :

Conditions préalables

  • Vous avez créé un commit OSTree pour RHEL for Edge et l'avez utilisé pour générer un artefact edge-simplified-installer.
  • Votre appareil est assemblé.
  • Vous avez installé le paquetage RPM fdo-manufacturing-server. Voir Installation du paquetage du serveur de fabrication.

Procédure

  1. Commencez le processus d'installation en démarrant l'image d'installation simplifiée de RHEL for Edge sur votre appareil. Vous pouvez l'installer à partir d'un CD-ROM ou d'une clé USB, par exemple.
  2. Vérifier, à l'aide du terminal, que le dispositif est parvenu au service de fabrication pour procéder à l'échange initial des données d'identification du dispositif et qu'il a produit un justificatif de propriété.

    Vous trouverez le justificatif de propriété dans l'emplacement de stockage configuré par le paramètre ownership_voucher_store_driver: dans le fichier manufacturing-sever.yml.

    Le répertoire doit contenir un fichier ownership_voucher avec un nom au format GUID qui indique que les informations d'identification correctes ont été ajoutées à l'appareil.

    Le serveur d'accueil utilise les informations d'identification de l'appareil pour s'authentifier auprès du serveur d'accueil. Il transmet ensuite la configuration à l'appareil. Une fois que l'appareil a reçu la configuration du serveur d'accueil, il reçoit une clé SSH et installe le système d'exploitation sur l'appareil. Enfin, le système redémarre automatiquement et est chiffré à l'aide d'une clé forte stockée dans le TPM.

Vérification

Après le redémarrage automatique de l'appareil, vous pouvez vous connecter à l'appareil avec les informations d'identification que vous avez créées dans le cadre du processus FDO.

  1. Connectez-vous à l'appareil en fournissant le nom d'utilisateur et le mot de passe que vous avez créés dans l'API des informations sur les services.

Chapitre 9. Déploiement d'une image RHEL for Edge dans un environnement réseau

Vous pouvez déployer une image RHEL for Edge à l'aide de l'interface utilisateur graphique du programme d'installation RHEL ou d'un fichier Kickstart. Le processus global de déploiement d'une image RHEL for Edge varie selon que votre environnement de déploiement est basé sur le réseau ou non.

Note

Pour déployer les images sur du métal nu, utilisez un fichier Kickstart.

Déploiements en réseau

Le déploiement d'une image RHEL for Edge dans un environnement basé sur le réseau implique les étapes de haut niveau suivantes :

  1. Extraire le contenu du fichier image.
  2. Mise en place d'un serveur web
  3. Installer l'image

9.1. Extraction de l'image RHEL for Edge

Après avoir téléchargé le commit, extrayez le fichier .tar et notez le nom de la ref et l'identifiant du commit.

Le fichier de validation téléchargé se compose d'un fichier .tar et d'un dépôt OSTree. Le dépôt OSTree contient un commit et un fichier compose.json.

Le fichier compose.json contient des métadonnées sur la livraison avec des informations telles que le "Ref", l'ID de référence et l'ID de la livraison. L'ID de la livraison contient les paquets RPM.

Pour extraire le contenu du paquet, procédez comme suit :

Conditions préalables

  • Créer un fichier Kickstart ou utiliser un fichier existant.

Procédure

  1. Extraire le fichier d'image téléchargé .tar:

    # tar xvf <UUID>-commit.tar
  2. Allez dans le répertoire où vous avez extrait le fichier .tar.

    Il comporte un fichier compose.json et un répertoire OSTree. Le fichier compose.json contient le numéro de livraison et le répertoire OSTree contient les paquets RPM.

  3. Ouvrez le fichier compose.json et notez le numéro d'identification du commit. Vous aurez besoin de ce numéro lorsque vous procéderez à la mise en place d'un serveur web.

    Si vous avez installé le processeur JSON jq, vous pouvez également récupérer l'identifiant du commit en utilisant l'outil jq:

    # jq '.["ostree-commit"]' < compose.json
  4. Liste des paquets RPM dans le commit.

    # rpm-ostree db list rhel/9/x86_64/edge --repo=repo
  5. Utilisez un fichier Kickstart pour exécuter le programme d'installation RHEL. Vous pouvez utiliser un fichier existant ou en créer un à l'aide de l'outil Kickstart Generator.

    Dans le fichier Kickstart, veillez à inclure les détails relatifs à l'approvisionnement du système de fichiers, à la création d'un utilisateur et à la récupération et au déploiement de l'image RHEL for Edge. Le programme d'installation RHEL utilise ces informations au cours du processus d'installation.

    Voici un exemple de fichier Kickstart :

    lang en_US.UTF-8
    keyboard us
    timezone Etc/UTC --isUtc
    text
    zerombr
    clearpart --all --initlabel
    autopart
    reboot
    user --name=core --group=wheel
    sshkey --username=core "ssh-rsa AAAA3Nza…​."
    rootpw --lock
    network --bootproto=dhcp
    
    ostreesetup --nogpg --osname=rhel --remote=edge --url=https://mirror.example.com/repo/ --ref=rhel/9/x86_64/edge

    L'installation basée sur OStree utilise la commande ostreesetup pour établir la configuration. Elle récupère le commit OSTree en utilisant les drapeaux suivants :

    • --nogpg - Désactiver la vérification des clés GNU Privacy Guard (GPG).
    • --osname - Racine de gestion pour l'installation du système d'exploitation.
    • --remote - Racine de gestion pour l'installation du système d'exploitation
    • --url - URL du référentiel à partir duquel l'installation doit être effectuée.
    • --ref - Nom de la branche du référentiel que l'installation utilise.
    • --url=https://mirror.example.com/repo/ - est l'adresse du système hôte sur lequel vous avez extrait l'engagement de périphérie et servi sur nginx. Vous pouvez utiliser l'adresse pour atteindre le système hôte à partir de l'ordinateur invité.

      Par exemple, si vous extrayez l'image de validation dans le répertoire /var/www/html et que vous diffusez la validation sur nginx sur un ordinateur dont le nom d'hôte est www.example.com, la valeur du paramètre --url est la suivante http://www.example.com/repo.

      Note

      Utilisez le protocole http pour démarrer un service qui servira le commit, car https n'est pas activé sur le serveur HTTP Apache.

9.2. Configuration d'un serveur web pour l'installation des images RHEL for Edge

Après avoir extrait le contenu de l'image RHEL for Edge, configurez un serveur web pour fournir les détails de la livraison de l'image au programme d'installation RHEL à l'aide de HTTP.

L'exemple suivant présente les étapes à suivre pour configurer un serveur web en utilisant un conteneur.

Conditions préalables

Procédure

  1. Créez le fichier de configuration nginx en suivant les instructions suivantes :

    events {
    
    }
    
    http {
        server{
            listen 8080;
            root /usr/share/nginx/html;
                    }
             }
    
    pid /run/nginx.pid;
    daemon off;
  2. Créez un fichier Docker en suivant les instructions suivantes :

    FROM registry.access.redhat.com/ubi8/ubi
    RUN dnf -y install nginx && dnf clean all
    COPY kickstart.ks /usr/share/nginx/html/
    COPY repo /usr/share/nginx/html/
    COPY nginx /etc/nginx.conf
    EXPOSE 8080
    CMD ["/usr/sbin/nginx", "-c", "/etc/nginx.conf"]
    ARG commit
    ADD ${commit} /usr/share/nginx/html/

    Où ?

    • kickstart.ks est le nom du fichier Kickstart de l'image RHEL for Edge. Le fichier Kickstart contient des informations sur les directives. Pour vous aider à gérer les images ultérieurement, il est conseillé d'inclure les contrôles et les paramètres des contrôles Greenboot. Pour cela, vous pouvez mettre à jour le fichier Kickstart pour inclure les paramètres suivants :

      lang en_US.UTF-8
      keyboard us
      timezone Etc/UTC --isUtc
      text
      zerombr
      clearpart --all --initlabel
      autopart
      reboot
      user --name=core --group=wheel
      sshkey --username=core "ssh-rsa AAAA3Nza…​."
      
      ostreesetup --nogpg --osname=rhel --remote=edge
      --url=https://mirror.example.com/repo/
      --ref=rhel/9/x86_64/edge
      
      %post
      cat << EOF > /etc/greenboot/check/required.d/check-dns.sh
      #!/bin/bash
      
      DNS_SERVER=$(grep nameserver /etc/resolv.conf | cut -f2 -d" ")
      COUNT=0
      
      # check DNS server is available
      ping -c1 $DNS_SERVER
      while [ $? != '0' ] && [ $COUNT -lt 10 ]; do
      
      							
      							
      							
      							
      							
      							
      							
      							COUNT++
      echo "Checking for DNS: Attempt $COUNT ."
      sleep 10
      ping -c 1 $DNS_SERVER
      done
      EOF
      %end

      Tout service HTTP peut héberger le référentiel OSTree, et l'exemple, qui utilise un conteneur, n'est qu'une option pour y parvenir. Le fichier Docker exécute les tâches suivantes :

      1. Utilise la dernière image de base universelle (UBI)
      2. Installe le serveur web (nginx)
      3. Ajoute le fichier Kickstart au serveur
      4. Ajoute le commit de l'image RHEL for Edge au serveur
  3. Construire un conteneur Docker

    # podman build -t name-of-container-image --build-arg commit=uuid-commit.tar .
  4. Exécuter le conteneur

    # podman run --rm -d -p port:8080 localhost/name-of-container-image

    Le serveur est donc configuré et prêt à démarrer l'installateur RHEL à l'aide du référentiel commit.tar et du fichier Kickstart.

9.3. Téléchargement de l'image ISO de RHEL Boot

Vous pouvez télécharger une image ISO Red Hat Boot à partir du portail client de Red Hat. L'image ISO Boot de Red Hat est utilisée pour lancer le programme d'installation de RHEL. Le programme d'installation récupère le fichier Kickstart que vous avez fourni pour l'installation de RHEL for Edge.

Conditions préalables

Procédure

  1. Ouvrez un navigateur et accédez à https://access.redhat.com/downloads.
  2. Sous Gestion de l'infrastructure, cliquez sur le produit Red Hat Enterprise Linux 9.
  3. Cliquez sur le bouton Télécharger maintenant pour l'option "Red Hat Enterprise Linux 9 Boot ISO"

Ressources supplémentaires

9.4. Installation de l'image RHEL for Edge à l'aide d'un fichier Kickstart

Pour installer l'image RHEL for Edge qui utilise un fichier Kickstart, utilisez le serveur web. Le serveur Web utilise le référentiel de l'image RHEL for Edge commit.tar et le fichier Kickstart pour démarrer le programme d'installation RHEL.

Conditions préalables

Procédure

  1. Exécutez le programme d'installation RHEL Anaconda à l'aide de libvirt virt-install:

    virt-install \
    --name rhel-edge-test-1 \
    --memory 2048 \
    --vcpus 2 \
    --disk path=prepared_disk_image.qcow2,format=qcow2,size=8 \
    --os-variant rhel9 \
    --cdrom /home/username/Downloads/rhel-9-x86_64-boot.iso
  2. Sur l'écran d'installation :

    Figure 9.1. Menu de démarrage de Red Hat Enterprise Linux

    The Red Hat Enterprise Linux boot menu
    1. Appuyez sur la touche e pour ajouter un paramètre supplémentaire au noyau :

      inst.ks=http://edge_device_ip:port/kickstart.ks

      Le paramètre kernel indique que vous souhaitez installer RHEL à l'aide du fichier Kickstart et non de l'image RHEL contenue dans le programme d'installation RHEL.

    2. Après avoir ajouté les paramètres du noyau, appuyez sur Ctrl X pour démarrer l'installation RHEL à l'aide du fichier Kickstart.

      Le programme d'installation RHEL démarre, récupère le fichier Kickstart à partir du point d'extrémité du serveur (HTTP) et exécute les commandes, y compris la commande d'installation de la commande d'image RHEL for Edge à partir du point d'extrémité HTTP. Une fois l'installation terminée, le programme d'installation RHEL vous invite à fournir des informations de connexion.

Vérification

  1. Dans l'écran de connexion, saisissez les informations d'identification de votre compte utilisateur et cliquez sur Entrée.
  2. Vérifiez que l'image RHEL for Edge a été installée avec succès.

    $ rpm-ostree status

    La sortie de la commande fournit l'identifiant de validation de l'image et indique que l'installation a réussi.

    Voici un exemple de résultat :

    State: idle
    Deployments:
    * ostree://edge:rhel/9/x86_64/edge
    		  Timestamp: 2020-09-18T20:06:54Z
    			Commit: 836e637095554e0b634a0a48ea05c75280519dd6576a392635e6fa7d4d5e96

Chapitre 10. Déploiement d'une image RHEL for Edge dans un environnement non basé sur le réseau

Le type d'image RHEL for Edge Container (.tar) combiné au type d'image RHEL for Edge Installer (.iso) donne une image ISO. L'image ISO peut être utilisée dans des environnements déconnectés pendant le déploiement de l'image sur un appareil. Cependant, l'accès au réseau peut être nécessaire pour construire les différents artefacts.

Le déploiement d'une image RHEL for Edge dans un environnement non basé sur un réseau implique les étapes de haut niveau suivantes :

  1. Téléchargez le conteneur RHEL for Edge. Voir Téléchargement d'une image RHEL for Edge pour plus d'informations sur le téléchargement de l'image RHEL for Edge.
  2. Charger l'image du conteneur RHEL for Edge dans Podman
  3. Exécuter l'image du conteneur RHEL for Edge dans Podman
  4. Charger le plan d'installation de RHEL for Edge
  5. Construire l'image du programme d'installation de RHEL for Edge
  6. Préparer un disque .qcow2
  7. Démarrer la machine virtuelle (VM)
  8. Installer l'image

10.1. Création d'une image RHEL for Edge Container pour les déploiements non basés sur le réseau

Vous pouvez créer un conteneur en cours d'exécution en chargeant le commit OSTree RHEL for Edge Container téléchargé dans Podman. Pour cela, suivez les étapes :

Conditions préalables

Procédure

  1. Naviguez jusqu'au répertoire dans lequel vous avez téléchargé le commit RHEL for Edge Container OSTree.
  2. Chargez le commit OSTree de RHEL for Edge Container dans Podman.

    sudo podman load -i UUID-container.tar

    La sortie de la commande indique l'ID de l'image, par exemple : @8e0d51f061ff1a51d157804362bc875b649b27f2ae1e66566a15e7e6530cec63

  3. Marquez la nouvelle image RHEL for Edge Container à l'aide de l'ID d'image généré à l'étape précédente.

    $ sudo podman tag image-ID localhost/edge-container

    La commande podman tag attribue un nom supplémentaire à l'image locale.

  4. Exécutez le conteneur nommé edge-container.

    $ sudo podman run -d --name=edge-container -p 8080:8080 localhost/edge-container

    La commande podman run -d --name=edge-container attribue un nom à votre conteneur en se basant sur l'image localhost/edge-container.

  5. Liste des contenants :

    $ sudo podman ps -a
    CONTAINER ID  IMAGE                               	COMMAND	CREATED    	STATUS                	PORTS   NAMES
    2988198c4c4b  …./localhost/edge-container   /bin/bash  3 seconds ago  Up 2 seconds ago      	edge-container

Par conséquent, Podman exécute un conteneur qui dessert un référentiel OSTree avec le commit RHEL for Edge Container.

10.2. Création d'une image RHEL for Edge Installer pour les déploiements non basés sur le réseau

Après avoir construit un conteneur en cours d'exécution pour servir un dépôt avec le commit RHEL for Edge Container, créez une image RHEL for Edge Installer (.iso). L'image RHEL for Edge Installer (.iso) tire le commit servi par RHEL for Edge Container (.tar). Une fois que le commit RHEL for Edge Container est chargé dans Podman, il expose le commit OSTree au format URL.

Pour créer l'image RHEL for Edge Installer dans l'interface CLI, procédez comme suit :

Conditions préalables

  • Vous avez créé un schéma directeur pour l'image RHEL for Edge.
  • Vous avez créé une image RHEL for Edge Edge Container et l'avez déployée à l'aide d'un serveur Web.

Procédure

  1. Commencez à créer l'image RHEL for Edge Installer.

    # composer-cli compose start-ostree --ref rhel/9/x86_64/edge --url URL-OSTree-repository blueprint-name image-type

    Où ?

    • ref est la même valeur que celle utilisée par le client pour construire le dépôt d'ostree
    • URL-OSTree-repository est l'URL du dépôt OSTree de l'engagement à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/. Voir Création d'une image RHEL for Edge Container pour les déploiements non basés sur le réseau.
    • blueprint-name est le nom du modèle RHEL for Edge Installer.
    • image-type est edge-installer.

      Une confirmation de l'ajout du processus de composition à la file d'attente s'affiche. Elle indique également un numéro d'identifiant universel unique (UUID) pour l'image créée. Utilisez le numéro UUID pour suivre votre construction. Conservez également le numéro UUID à portée de main pour d'autres tâches.

  2. Vérifier l'état de la composition de l'image.

    # composer-cli compose status

    La sortie de la commande affiche l'état dans le format suivant :

    <UUID> RUNNING date blueprint-name blueprint-version image-type
    Note

    Le processus de création de l'image prend quelques minutes.

    Pour interrompre le processus de création d'image, exécutez :

    # composer-cli composer cancel <UUID>

    Pour supprimer une image existante, exécutez :

    # composer-cli composer delete <UUID>

    Image builder tire le commit qui est servi par le conteneur en cours d'exécution pendant la construction de l'image.

    Une fois la construction de l'image terminée, vous pouvez télécharger l'image ISO résultante.

  3. Téléchargez l'image. Voir Téléchargement d'une image RHEL for Edge.

    Une fois l'image prête, vous pouvez l'utiliser pour non-network deployments. Voir Installation de l'image RHEL for Edge pour les déploiements non basés sur le réseau.

10.3. Installation de l'image RHEL for Edge pour les déploiements non basés sur le réseau

Pour installer l'image RHEL for Edge, procédez comme suit :

Conditions préalables

  • Vous avez créé une image ISO de RHEL for Edge Installer.
  • Vous avez arrêté le conteneur en cours d'exécution.
  • Une image disque pour installer le commit que vous avez créé.
  • Vous avez installé le paquetage edk2-ovmf.
  • Vous avez installé le paquetage virt-viewer.
  • Vous avez personnalisé votre projet avec un compte utilisateur. Voir Création d'un compte d'utilisateur administratif pour un modèle d'image RHEL for Edge.

    Avertissement

    Si vous ne définissez pas de personnalisation du compte utilisateur dans votre schéma directeur, vous ne pourrez pas vous connecter à l'image ISO.

Procédure

  1. Créez un fichier disque qcow VM pour installer l'image (.iso). Il s'agit d'une image d'un disque dur pour la machine virtuelle (VM). Par exemple, il s'agit d'une image d'un disque dur pour la machine virtuelle (VM) :

    $ qemu-img create -f qcow2 diskfile.qcow2 20G
  2. Utilisez la commande virt-install pour démarrer la VM en utilisant le disque comme une unité et l'ISO d'installation comme un CD-ROM. Par exemple :

    $ virt-install \
    --boot uefi \
    --name VM_NAME
    --memory 2048 \
    --vcpus 2 \
    --disk path=diskfile.qcow2
    --cdrom /var/lib/libvirt/images/UUID-installer.iso \
    --os-variant rhel9.0

    Cette commande demande à virt-install de :

    • Indique à la VM d'utiliser l'UEFI pour démarrer, au lieu du BIOS.
    • Monter l'ISO d'installation.
    • Utilisez l'image du disque dur créée lors de la première étape.

      Vous obtenez un programme d'installation Anaconda. L'installateur RHEL démarre, charge le fichier Kickstart de l'ISO et exécute les commandes, y compris la commande d'installation du commit de l'image RHEL for Edge. Une fois l'installation terminée, le programme d'installation demande des informations de connexion.

      Note

      Anaconda est préconfiguré pour utiliser le Container commit lors de l'installation. Cependant, vous devez définir les configurations du système, telles que la partition du disque, le fuseau horaire, entre autres.

  3. Connectez-vous à l'interface graphique d'Anaconda à l'aide de virt-viewer pour configurer le système :

    $ virt-viewer --connect qemu:///system --wait VM_NAME
  4. Redémarrez le système pour terminer l'installation.
  5. Sur l'écran de connexion, indiquez les informations d'identification de votre compte utilisateur et cliquez sur Entrée.

Verification steps

  1. Vérifiez que l'image RHEL for Edge a été installée avec succès.

    $  rpm-ostree status

La sortie de la commande fournit l'identifiant de validation de l'image et indique que l'installation a réussi.

Chapitre 11. Gestion des images RHEL for Edge

Pour gérer les images RHEL for Edge, vous pouvez effectuer l'une des tâches administratives suivantes :

  • Modifier le modèle d'image RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL
  • Modifier le modèle d'image RHEL for Edge à l'aide de la ligne de commande image builder
  • Mise à jour des images RHEL for Edge
  • Configurer rpm-ostree remotes sur les nœuds, pour mettre à jour la politique des nœuds
  • Restaurer les images RHEL for Edge manuellement ou automatiquement à l'aide de Greenboot

11.1. Modification d'un modèle d'image RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL

Vous pouvez modifier le modèle d'image RHEL for Edge pour :

  • Ajoutez les composants supplémentaires dont vous pourriez avoir besoin
  • Modifier la version d'un composant existant
  • Retirer tout composant existant

11.1.1. Ajout d'un composant au modèle d'image RHEL for Edge à l'aide du constructeur d'images dans la console web RHEL

Pour ajouter un composant à un modèle d'image RHEL for Edge, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure pour modifier le modèle correspondant.

Conditions préalables

  • Sur un système RHEL, vous avez accédé au tableau de bord du constructeur d'images.
  • Vous avez créé un schéma directeur pour l'image RHEL for Edge.

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur le plan que vous souhaitez modifier.

    Pour rechercher un plan spécifique, saisissez le nom du plan dans la zone de texte du filtre et cliquez sur Entrée.

  2. Dans la partie supérieure droite du plan, cliquez sur Modifier les paquets.

    L'assistant Edit blueprints s'ouvre.

  3. Sur la page Details, mettez à jour le nom du plan et cliquez sur Suivant.
  4. Sur la page Packages, suivez les étapes :

    1. Sur le site Available Packages, saisissez le nom du paquet que vous souhaitez ajouter dans la zone de texte du filtre, puis cliquez sur Entrée.

      Une liste avec le nom du composant s'affiche.

    2. Cliquez sur > pour ajouter le composant au plan.
  5. Sur la page Review, cliquez sur Enregistrer.

    Le plan est maintenant mis à jour avec le nouveau paquet.

11.1.2. Suppression d'un composant d'un modèle d'image RHEL for Edge à l'aide du constructeur d'images dans la console Web RHEL

Pour supprimer un ou plusieurs composants indésirables d'un modèle d'image RHEL for Edge que vous avez créé, assurez-vous que vous avez rempli les conditions préalables suivantes, puis suivez la procédure.

Conditions préalables

  • Sur un système RHEL, vous avez accédé au tableau de bord du constructeur d'images.
  • Vous avez créé un schéma directeur pour l'image RHEL for Edge.
  • Vous avez ajouté au moins un composant au plan RHEL for Edge.

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur le plan que vous souhaitez modifier.

    Pour rechercher un plan spécifique, saisissez le nom du plan dans la zone de texte du filtre et cliquez sur Entrée.

  2. Dans la partie supérieure droite du plan, cliquez sur Modifier les paquets.

    L'assistant Edit blueprints s'ouvre.

  3. Sur la page Details, mettez à jour le nom du plan et cliquez sur Suivant.
  4. Sur la page Packages, suivez les étapes :

    1. Sur le site Chosen packages, cliquez sur < pour supprimer le composant choisi. Vous pouvez également cliquer sur << pour supprimer tous les paquets en même temps.
  5. Sur la page Review, cliquez sur Enregistrer.

    Le plan est maintenant mis à jour.

11.1.3. Modification d'un modèle d'image RHEL for Edge à l'aide de l'interface en ligne de commande

Vous pouvez modifier les spécifications de votre modèle d'image RHEL for Edge à l'aide de la ligne de commande du constructeur d'images. Pour ce faire, assurez-vous d'avoir rempli les conditions préalables suivantes, puis suivez la procédure pour modifier le modèle correspondant.

Conditions préalables

  • Vous avez accès à la ligne de commande du constructeur d'images.
  • Vous avez créé un modèle d'image RHEL for Edge.

Procédure

  1. Enregistrer (exporter) le plan dans un fichier texte local :

    # composer-cli blueprints save BLUEPRINT-NAME
  2. Modifiez le fichier BLUEPRINT-NAME.toml à l'aide d'un éditeur de texte de votre choix et apportez vos modifications.

    Avant de terminer les modifications, vérifiez que le fichier est un plan valide :

  3. Augmenter le numéro de version.

    Veillez à utiliser un système de versionnement sémantique.

    Note

    si vous ne modifiez pas la version, la composante corrective de la version est augmentée automatiquement.

  4. Vérifier si le contenu est une spécification TOML valide. Voir la documentation TOML pour plus d'informations.

    Note

    La documentation TOML est un produit communautaire et n'est pas pris en charge par Red Hat. Vous pouvez signaler tout problème lié à l'outil à l'adresse https://github.com/toml-lang/toml/issues.

  5. Enregistrez le fichier et fermez l'éditeur.
  6. Repousser (importer) le plan dans la ligne de commande du constructeur d'images :

    # composer-cli blueprints push BLUEPRINT-NAME.toml
    Note

    Lorsque vous repoussez le plan dans la ligne de commande du constructeur d'images, indiquez le nom du fichier, y compris l'extension .toml.

  7. Vérifiez que le contenu téléchargé dans le générateur d'images correspond à vos modifications :

    # composer-cli blueprints show BLUEPRINT-NAME
  8. Vérifiez si les composants et les versions répertoriés dans le plan et leurs dépendances sont valides :

    # composer-cli blueprints depsolve BLUEPRINT-NAME

11.2. Mise à jour des images RHEL for Edge

11.2.1. Comment les mises à jour des images RHEL for Edge sont-elles déployées ?

Avec les images RHEL for Edge, vous pouvez déployer les mises à jour manuellement ou automatiser le processus de déploiement. Les mises à jour sont appliquées de manière atomique, c'est-à-dire que l'état de chaque mise à jour est connu, et les mises à jour sont stockées et appliquées uniquement au redémarrage. Comme aucun changement n'est visible avant le redémarrage de l'appareil, vous pouvez planifier un redémarrage pour garantir un temps de fonctionnement optimal.

Lors de la mise à jour de l'image, seul le contenu du système d'exploitation mis à jour est transféré sur le réseau. Cela rend le processus de déploiement plus efficace par rapport au transfert de l'image entière. Les binaires et les bibliothèques du système d'exploitation dans /usr sont read-only, et l'état read and write est maintenu dans les répertoires /var et /etc.

Lors du passage à un nouveau déploiement, les répertoires /etc et /var sont copiés dans le nouveau déploiement avec les autorisations read and write. Le répertoire /usr est copié en tant que lien logiciel vers le répertoire du nouveau déploiement, avec les autorisations read-only.

Le diagramme suivant illustre le processus de déploiement de la mise à jour de l'image RHEL for Edge :

Image Deployment

Par défaut, le nouveau système est démarré en utilisant une procédure similaire à une opération chroot. Le nouveau répertoire /sysroot se compose principalement des éléments suivants :

  • Base de données du référentiel dans le répertoire /sysroot/ostree/repo.
  • Révisions du système de fichiers dans le répertoire /sysroot/ostree/deploy/rhel/deploy, créées par chaque opération de mise à jour du système.
  • Le répertoire /sysroot/ostree/boot, qui renvoie aux déploiements du point précédent. Notez que /ostree est un lien souple vers /sysroot/ostree. Les fichiers du répertoire /sysroot/ostree/boot ne sont pas dupliqués. Le même fichier est utilisé s'il n'est pas modifié pendant le déploiement. Les fichiers sont des liens en dur vers un autre fichier stocké dans le répertoire /sysroot/ostree/repo/objects.

Le système d'exploitation sélectionne le déploiement de la manière suivante :

  1. L'outil dracut analyse l'argument du noyau ostree dans le système de fichiers initramfs root et configure le répertoire /usr en tant que montage bind read-only.
  2. Lier le répertoire de déploiement dans /sysroot au répertoire /.
  3. Remonter le système d'exploitation déjà monté dirs à l'aide de l'indicateur de montage MS_MOVE

En cas de problème, vous pouvez effectuer un retour en arrière en supprimant les anciens déploiements à l'aide de la commande rpm-ostree cleanup. Chaque machine cliente contient un référentiel OSTree stocké dans /ostree/repo, et un ensemble de déploiements stockés dans /ostree/deploy/$STATEROOT/$CHECKSUM.

Avec les mises à jour de déploiement de l'image RHEL for Edge, vous pouvez bénéficier d'une meilleure cohérence du système sur plusieurs appareils, d'une reproductibilité plus facile et d'une meilleure isolation entre le changement d'état du système avant et après.

11.2.2. Déploiement manuel des mises à jour d'images RHEL for Edge

Après avoir modifié un plan RHEL for Edge, vous pouvez mettre à jour le commit de l'image. Image builder génère un nouveau commit pour l'image RHEL for Edge mise à jour. Utilisez ce nouveau commit pour déployer l'image avec les dernières versions des paquets ou avec des paquets supplémentaires.

Pour déployer les mises à jour des images RHEL for Edge, assurez-vous que vous remplissez les conditions préalables, puis suivez la procédure.

Conditions préalables

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer une image.
  2. Dans la fenêtre Create Image, procédez comme suit :

    1. Dans la page de sortie des images :

      1. Dans la liste déroulante Select a blueprint, sélectionnez le plan que vous avez modifié.
      2. Dans la liste déroulante Image output type, sélectionnez RHEL for Edge Commit (.tar). Cliquez sur Suivant.
    2. Dans la page OSTree settings, entrez :

      1. Dans le champ Repository URL, saisissez l'URL du référentiel OSTree de la livraison à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/. Voir Configuration d'un serveur web pour l'installation de l'image RHEL for Edge.
      2. Dans le champ Parent commit, indiquez l'ID du commit parent qui a été généré précédemment. Voir Extraction du commit de l'image RHEL for Edge.
      3. Dans le champ Ref, vous pouvez soit spécifier un nom pour votre livraison, soit le laisser vide. Par défaut, la console web spécifie Ref comme rhel/9/arch_name/edge. Cliquez sur Suivant.
    3. Sur la page Review, vérifiez les personnalisations et cliquez sur Créer une image. Le constructeur d'images commence à créer une image RHEL for Edge pour le plan mis à jour. Le processus de création d'image prend quelques minutes.

      Pour visualiser la progression de la création de l'image RHEL for Edge, cliquez sur le nom du plan dans les fils d'Ariane, puis sur l'onglet Images.

      L'image résultante inclut les derniers paquets que vous avez ajoutés, le cas échéant, et a pour parent l'original commit ID.

  3. Téléchargez l'image RHEL for Edge Commit (.tar) qui en résulte.

    1. Dans l'onglet Images, cliquez sur Télécharger pour enregistrer l'image RHEL for Edge Commit (.tar) sur votre système.
  4. Extraire le fichier OSTree commit (.tar).

    # tar -xf UUID-commit.tar -C UPGRADE_FOLDER
  5. Mettre à jour le répertoire OSTree :

    # ostree pull-local --repo http://10.0.2.2:8080/repo UPGRADE_FOLDER/repo OSTREE_REF
    # ostree summary --update --repo http://10.0.2.2:8080/repo
  6. Construire un conteneur docker, en utilisant cette fois l'ID du commit enfant.

    # podman build -t name-of-server --build-arg commit=UUID-child_commit.tar .
  7. Exécuter le conteneur.

    # podman run --rm -p 8000:80 name-of-server
  8. Sur le système RHEL approvisionné, à partir de l'image de bord originale, vérifiez l'état actuel.

    $ rpm-ostree status

    S'il n'y a pas de nouvel identifiant de livraison, exécutez la commande suivante pour vérifier si une mise à niveau est disponible :

    $ rpm-ostree upgrade --check

    La sortie de la commande fournit l'identifiant de l'engagement OSTree actif.

  9. Mettre à jour OSTree pour rendre disponible le nouvel identifiant de livraison OSTree.

    $ rpm-ostree upgrade

    OSTree vérifie s'il existe une mise à jour dans le référentiel. Si c'est le cas, il récupère la mise à jour et vous demande de redémarrer votre système afin que vous puissiez activer le déploiement de cette nouvelle mise à jour.

  10. Vérifiez à nouveau l'état actuel :

    $ rpm-ostree status

    Vous pouvez maintenant voir qu'il y a 2 commits disponibles :

    • L'engagement actif du parent.
    • Un nouvel engagement qui n'est pas actif et qui contient une différence ajoutée.
  11. Pour activer le nouveau déploiement et rendre la nouvelle validation active, redémarrez votre système.

    # systemctl reboot

    L'installateur Anaconda redémarre dans le nouveau déploiement. Sur l'écran de connexion, vous pouvez voir un nouveau déploiement disponible pour démarrer.

  12. Si vous souhaitez démarrer sur le déploiement le plus récent (commit), la commande rpm-ostree upgrade ordonne automatiquement les entrées de démarrage de manière à ce que le nouveau déploiement soit le premier de la liste. En option, vous pouvez utiliser la touche fléchée de votre clavier pour sélectionner l'entrée du menu GRUB et appuyer sur Entrée.
  13. Fournissez les informations d'identification de votre compte d'utilisateur.
  14. Vérifier l'état de l'OSTree :

    $ rpm-ostree status

    La sortie de la commande fournit l'identifiant de l'engagement actif.

  15. Pour voir les paquets modifiés, s'il y en a, lancez un diff entre le commit parent et le nouveau commit :

    $ rpm-ostree db diff parent_commit new_commit

    La mise à jour indique que le paquet que vous avez installé est disponible et prêt à être utilisé.

11.2.3. Déploiement manuel des mises à jour d'images RHEL for Edge à l'aide de la ligne de commande

Après avoir modifié un plan RHEL for Edge, vous pouvez mettre à jour le commit de l'image. Image builder génère un nouveau commit pour l'image RHEL for Edge mise à jour. Utilisez le nouveau commit pour déployer l'image avec les dernières versions des paquets ou avec des paquets supplémentaires à l'aide de la CLI.

Pour déployer des mises à jour d'images RHEL for Edge à l'aide de l'interface de programmation, assurez-vous de remplir les conditions préalables, puis suivez la procédure.

Conditions préalables

Procédure

  1. Créez l'image RHEL for Edge Commit (.tar) avec les arguments suivants :

    # composer-cli compose start-ostree --ref ostree_ref --url URL-OSTree-repository -blueprint_name_ image-type

  2. Vérifiez la progression de la création de l'image RHEL for Edge :

    # composer-cli compose status
    Note

    Les processus de création d'images peuvent durer de dix à trente minutes.

    L'image résultante inclut les derniers paquets que vous avez ajoutés, le cas échéant, et a pour parent l'image originale commit ID.

  3. Téléchargez l'image RHEL for Edge obtenue. Pour plus d'informations, voir Téléchargement d'une image RHEL for Edge à l'aide de l'interface de ligne de commande du constructeur d'images.
  4. Extraire le commit OSTree.

    # tar -xf UUID-commit.tar -C UPGRADE_FOLDER
  5. Servez le commit OSTree en utilisant httpd. Voir Configuration d'un serveur web pour l'installation de RHEL for Edge image.
  6. Mettre à jour le répertoire OSTree :

    # ostree pull-local --repo http://10.0.2.2:8080/repo UPGRADE_FOLDER/repo OSTREE_REF
    # ostree summary --update --repo http://10.0.2.2:8080/repo
  7. Sur le système RHEL approvisionné à partir de l'image de bord originale, vérifiez l'état actuel :

    $ rpm-ostree status

    S'il n'y a pas de nouvel identifiant de livraison, exécutez la commande suivante pour vérifier si une mise à niveau est disponible :

    $ rpm-ostree upgrade --check

    La sortie de la commande fournit l'identifiant de l'engagement OSTree actif.

  8. Mettre à jour OSTree pour rendre disponible le nouvel identifiant de livraison OSTree :

    $ rpm-ostree upgrade

    OSTree vérifie s'il existe une mise à jour dans le référentiel. Si c'est le cas, il récupère la mise à jour et vous demande de redémarrer votre système afin que vous puissiez activer le déploiement de la nouvelle mise à jour.

  9. Vérifiez à nouveau l'état actuel :

    $ rpm-ostree status

    Vous devriez maintenant voir qu'il y a 2 commits disponibles :

    • L'engagement parental actif
    • Un nouvel engagement qui n'est pas actif et qui contient 1 différence ajoutée
  10. Pour activer le nouveau déploiement et rendre la nouvelle validation active, redémarrez votre système :

    # systemctl reboot

    L'installateur Anaconda redémarre dans le nouveau déploiement. Sur l'écran de connexion, vous pouvez voir un nouveau déploiement disponible pour démarrer.

  11. Si vous souhaitez démarrer sur le déploiement le plus récent, la commande rpm-ostree upgrade ordonne automatiquement les entrées de démarrage de sorte que le nouveau déploiement soit le premier de la liste. En option, vous pouvez utiliser la touche fléchée de votre clavier pour sélectionner l'entrée du menu GRUB et appuyer sur Entrée.
  12. Connectez-vous en utilisant les informations d'identification de votre compte.
  13. Vérifier l'état de l'OSTree :

    $ rpm-ostree status

    La sortie de la commande fournit l'identifiant de l'engagement actif.

  14. Pour voir les paquets modifiés, s'il y en a, lancez un diff entre le commit parent et le nouveau commit :

    $ rpm-ostree db diff parent_commit new_commit

    La mise à jour indique que le paquet que vous avez installé est disponible et prêt à être utilisé.

11.2.4. Déploiement manuel des mises à jour d'images RHEL for Edge pour les déploiements non basés sur le réseau

Après avoir modifié un plan RHEL for Edge, vous pouvez mettre à jour le commit de l'image. Image builder génère un nouveau commit pour l'image RHEL for Edge mise à jour. Utilisez ce nouveau commit pour déployer l'image avec les dernières versions des paquets ou avec des paquets supplémentaires.

Pour déployer les mises à jour des images RHEL for Edge, assurez-vous que vous remplissez les conditions préalables, puis suivez la procédure.

Conditions préalables

Procédure

  1. Dans le tableau de bord du constructeur d'images, cliquez sur Créer une image.
  2. Dans la fenêtre Create Image, procédez comme suit :

    1. Dans la page de sortie des images :

      1. Dans la liste déroulante Select a blueprint, sélectionnez le plan que vous avez modifié.
      2. Dans la liste déroulante Image output type, sélectionnez RHEL for Edge Container (.tar). Cliquez sur Suivant.
    2. Dans la page OSTree settings, entrez :

      1. Dans le champ Repository URL, saisissez l'URL du référentiel OSTree de la livraison à intégrer dans l'image. Par exemple, http://10.0.2.2:8080/repo/. Voir Configuration d'un serveur web pour l'installation de l'image RHEL for Edge.
      2. Dans le champ Parent commit, indiquez l'ID du commit parent qui a été généré précédemment. Voir Extraction du commit de l'image RHEL for Edge.
      3. Dans le champ Ref, vous pouvez soit spécifier un nom pour votre livraison, soit le laisser vide. Par défaut, la console web spécifie Ref comme rhel/9/arch_name/edge. Cliquez sur Suivant.
    3. Dans la page Review, vérifiez les personnalisations et cliquez sur Créer une image.

      Le constructeur d'images crée une image RHEL for Edge pour le plan mis à jour.

      Pour visualiser la progression de la création de l'image RHEL for Edge, cliquez sur l'onglet Images.

      Note

      Le processus de création de l'image prend quelques minutes.

      L'image résultante inclut les derniers paquets que vous avez ajoutés, le cas échéant, et a pour parent l'image originale commit ID.

  3. Télécharger l'image RHEL for Edge résultante

    1. Dans l'onglet Images, cliquez sur Download pour enregistrer l'image RHEL for Edge Container (.tar) sur votre système.
  4. Charger l'image du conteneur RHEL for Edge dans Podman, en utilisant cette fois l'identifiant de livraison de l'enfant.

    $ cat ./child-commit_ID-container.tar | sudo podman load
  5. Exécuter Podman.

    #  sudo podman run -p 8080:8080 localhost/edge-test
  6. Mettre à jour le répertoire OSTree :

    # ostree pull-local --repo http://10.0.2.2:8080/repo UPGRADE_FOLDER/repo OSTREE_REF
    # ostree summary --update --repo http://10.0.2.2:8080/repo
  7. Sur le système RHEL approvisionné, à partir de l'image de bord originale, vérifiez l'état actuel.

    $ rpm-ostree status

    S'il n'y a pas de nouvel identifiant de livraison, exécutez la commande suivante pour vérifier si une mise à niveau est disponible :

    $ rpm-ostree upgrade --check

    Si des mises à jour sont disponibles, la sortie de la commande fournit des informations sur les mises à jour disponibles dans le référentiel OSTree, telles que l'ID du commit OSTree actif. Dans le cas contraire, la commande affiche un message indiquant qu'aucune mise à jour n'est disponible.

  8. Mettre à jour OSTree pour rendre disponible le nouvel identifiant de livraison OSTree.

    $ rpm-ostree upgrade

    OSTree vérifie s'il existe une mise à jour dans le référentiel. Si c'est le cas, il récupère la mise à jour et vous demande de redémarrer votre système afin que vous puissiez activer le déploiement de cette nouvelle mise à jour.

  9. Vérifier l'état actuel :

    $ rpm-ostree status

    Vous pouvez maintenant voir qu'il y a 2 commits disponibles :

    • L'engagement actif du parent.
    • Un nouvel engagement qui n'est pas actif et qui contient une différence ajoutée.
  10. Pour activer le nouveau déploiement et rendre la nouvelle validation active, redémarrez votre système.

    # systemctl reboot

    L'installateur Anaconda redémarre dans le nouveau déploiement. Sur l'écran de connexion, vous pouvez voir un nouveau déploiement disponible pour démarrer.

  11. Si vous souhaitez démarrer sur le dernier commit/déploiement, la commande rpm-ostree upgrade ordonne automatiquement les entrées de démarrage de manière à ce que le nouveau déploiement soit le premier de la liste. En option, vous pouvez utiliser la touche fléchée de votre clavier pour sélectionner l'entrée du menu GRUB et appuyer sur Entrée.
  12. Fournissez les informations d'identification de votre compte d'utilisateur.
  13. Vérifier l'état de l'OSTree :

    $ rpm-ostree status

    La sortie de la commande fournit l'identifiant de l'engagement actif.

  14. Pour voir les paquets modifiés, s'il y en a, lancez un diff entre le commit parent et le nouveau commit :

    $ rpm-ostree db diff parent_commit new_commit

    La mise à jour indique que le paquet que vous avez installé est disponible et prêt à être utilisé.

11.3. Mise à niveau de RHEL pour les systèmes Edge

11.3.1. Mise à niveau de votre système RHEL 8 vers RHEL 9

Vous pouvez mettre à niveau votre système RHEL 8 vers RHEL 9 à l'aide de la commande rpm-ostree rebase. Cette commande prend entièrement en charge l'ensemble de paquets par défaut de RHEL pour les mises à niveau Edge des mises à jour les plus récentes de RHEL 8 vers les mises à jour les plus récentes de RHEL 9. La mise à niveau télécharge et installe l'image RHEL 9 en arrière-plan. Une fois la mise à niveau terminée, vous devez redémarrer votre système pour utiliser la nouvelle image RHEL 9.

Note

La mise à niveau ne prend pas en charge toutes les versions et inclusions possibles du paquet rpm. Vous devez tester vos ajouts de paquets pour vous assurer qu'ils fonctionnent comme prévu.

Conditions préalables

  • Vous disposez d'un système RHEL for Edge 8 en cours d'exécution
  • Vous disposez d'un serveur de référentiel OSTree par HTTP
  • Vous avez créé un schéma directeur pour l'image RHEL for Edge 9 que vous allez mettre à niveau

Procédure

  1. Sur le système où s'exécute le constructeur d'images, créez une image RHEL for Edge 9 :

    1. Lancer la composition de l'image :

      $ sudo composer-cli compose start blueprint-name edge-commit
    2. Une fois la composition terminée, téléchargez l'image.
    3. Extraire l'image téléchargée dans le dossier /var/www/html/:

      $ sudo tar -xf image_file -C /var/www/html
    4. Démarrez le service httpd:

      $ systemctl start httpd.service
  2. Sur l'appareil RHEL for Edge, vérifiez la configuration actuelle du référentiel distant :

    $ sudo cat /etc/ostree/remotes.d/edge.conf
    Note

    Selon la configuration de votre fichier Kickstart, le dépôt /etc/ostree/remotes.d peut être vide. Si vous avez configuré votre dépôt distant, vous pouvez voir sa configuration. Pour les images edge-installer, raw-image, et simplified-installer, le dépôt distant est configuré par défaut.

  3. Vérifier le référentiel URL actuel :

    $ sudo ostree remote show-url edge

    edge est le référentiel d'Ostree.

  4. Liste des branches de référence distantes :

    $ ostree remote refs edge

    Vous pouvez voir le résultat suivant :

    Error: Remote refs not available; server has no summary file
  5. Pour ajouter le nouveau dépôt :

    1. Configurez la clé URL pour ajouter un référentiel distant. Par exemple :

      $ sudo ostree remote add \ --no-gpg-verify rhel9 http://192.168.122.1/repo/
    2. Configurez la clé URL pour qu'elle pointe vers le commit RHEL 9 pour la mise à niveau. Par exemple :

      $ sudo cat /etc/ostree/remotes.d/edge.conf [remote "edge"] url=http://192.168.122.1/ostree/repo/ gpg-verify=false
    3. Confirmez que l'URL a été définie pour le nouveau référentiel distant :

      $ sudo cat /etc/ostree/remotes.d/rhel9.conf [remote "edge"] url=http://192.168.122.1/repo/ gpg-verify=false
    4. Voir le nouveau référentiel URL :

      $ sudo ostree remote show-url rhel9 http://192.168.122.1/ostree-rhel9/repo/
    5. Liste les options actuelles de la liste à distance :

      $ sudo ostree remote list
      
      output:
      edge
      rhel9
  6. Rebasez votre système sur la version RHEL, en fournissant le chemin de référence pour la version RHEL 9 :

    $ rpm-ostree rebase rhel9:rhel/9/x86_64/edge
  7. Redémarrez votre système.

    $ systemctl reboot
  8. Entrez votre nom d'utilisateur et votre mot de passe.
  9. Vérifier l'état actuel du système :

    $ rpm-ostree status

Vérification

  1. Vérifier l'état actuel du déploiement en cours :

    $ rpm-ostree status
  2. Facultatif : Liste des processeurs et des tâches gérés par le noyau en temps réel.

    $ top
  3. Si la mise à niveau ne répond pas à vos besoins, vous avez la possibilité de revenir manuellement à la version précédente du déploiement stable de RHEL 8 :

    $ sudo rpm-ostree rollback
  4. Redémarrez votre système. Entrez votre nom d'utilisateur et votre mot de passe :

    $ systemctl reboot

    Après le redémarrage, votre système exécute RHEL 9 avec succès.

    Note

    Si votre mise à niveau réussit et que vous ne souhaitez pas utiliser la version précédente de RHEL 8, vous pouvez supprimer l'ancien référentiel :

    $ sudo ostree remote delete edge

11.4. Déploiement des mises à jour automatiques des images de RHEL for Edge

Après avoir installé une image RHEL for Edge sur un appareil Edge, vous pouvez vérifier si des mises à jour de l'image sont disponibles, le cas échéant, et les appliquer automatiquement.

Les paramètres rpm-ostreed-automatic.service (service systemd) et rpm-ostreed-automatic.timer (timer systemd) contrôlent la fréquence des vérifications et des mises à jour. Les mises à jour disponibles, le cas échéant, apparaissent sous forme de déploiements échelonnés.

Le déploiement de mises à jour automatiques d'images implique les étapes de haut niveau suivantes :

  • Mise à jour de la politique de mise à jour des images
  • Permettre le téléchargement automatique et la mise à disposition des mises à jour

11.4.1. Mise à jour de la politique de mise à jour des images RHEL for Edge

Pour mettre à jour la stratégie de mise à jour de l'image, utilisez les paramètres AutomaticUpdatePolicy et IdleExitTimeout du fichier rpm-ostreed.conf à l'emplacement /etc/rpm-ostreed.conf sur un appareil Edge.

Les paramètres AutomaticUpdatePolicy contrôlent la politique de mise à jour automatique et proposent les options de vérification des mises à jour suivantes :

  • none: Désactive les mises à jour automatiques. Par défaut, le paramètre AutomaticUpdatePolicy est défini sur none.
  • check: Télécharge suffisamment de métadonnées pour afficher les mises à jour disponibles avec l'état rpm-ostree.
  • stage: Télécharge et décompresse les mises à jour qui sont appliquées lors d'un redémarrage.

Le paramètre IdleExitTimeout contrôle le temps d'inactivité en secondes avant la sortie du démon et dispose des options suivantes :

  • 0 : Désactive la sortie automatique.
  • 60 : Par défaut, le paramètre IdleExitTimeout est défini sur 60.

Pour activer les mises à jour automatiques, procédez comme suit :

Procédure

  1. Dans le fichier /etc/rpm-ostreed.conf, mettez à jour les éléments suivants :

    • Remplacer la valeur de AutomaticUpdatePolicy par check.
    • Pour exécuter les contrôles de mise à jour, spécifiez une valeur en secondes pour IdleExitTimeout.
  2. Rechargez le service rpm-ostreed et activez la minuterie systemd.

    # systemctl reload rpm-ostreed
    # systemctl enable rpm-ostreed-automatic.timer --now
  3. Vérifiez l'état de rpm-ostree pour vous assurer que la politique de mise à jour automatique est configurée et que le temps est actif.

    # rpm-ostree status

    La sortie de la commande est la suivante :

    État : inactif ; mises à jour automatiques activées (vérification ; dernière exécution il y a <minutes>)

    En outre, la sortie affiche également des informations sur les mises à jour disponibles.

11.4.2. Activation du téléchargement automatique et de la mise à disposition des mises à jour de RHEL for Edge

Une fois que vous avez mis à jour la politique de mise à jour des images pour vérifier les mises à jour des images, les mises à jour éventuelles s'affichent avec les détails de la mise à jour. Si vous décidez d'appliquer les mises à jour, activez la stratégie pour qu'elle télécharge automatiquement les mises à jour et les mette à disposition. Les mises à jour d'images disponibles sont alors téléchargées et mises à disposition pour le déploiement. Les mises à jour sont appliquées et prennent effet lorsque vous redémarrez l'appareil Edge.

Pour activer la stratégie de téléchargement automatique et de mise à disposition des mises à jour, effectuez les mises à jour suivantes :

Procédure

  1. Dans le fichier /etc/rpm-ostreed.conf, mettez à jour "AutomaticUpdatePolicy" en stage.
  2. Recharger le service rpm-ostreed.

    # systemctl enable rpm-ostreed-automatic.timer --now
  3. Vérifier l'état de rpm-ostree

    # rpm-ostree status

    La sortie de la commande est la suivante :

    State: idle
    AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run <time> ago
  4. Pour lancer les mises à jour, vous pouvez soit attendre que la minuterie lance les mises à jour, soit démarrer manuellement le service.

    # systemctl start rpm-ostreed-automatic.service

    Une fois les mises à jour lancées, l'état de rpm-ostree indique ce qui suit :

    # rpm-ostree status
    State: busy
    AutomaticUpdates: stage; rpm-ostreed-automatic.service: running
    Transaction: automatic (stage)

    Lorsque la mise à jour est terminée, une nouvelle répartition est mise en place dans la liste des répartitions, et la répartition démarrée à l'origine reste intacte. Vous pouvez décider de démarrer le système à l'aide de la nouvelle répartition ou d'attendre la prochaine mise à jour.

    Pour afficher la liste des déploiements, exécutez la commande rpm-ostree status.

    Voici un exemple de résultat.

    # rpm-ostree status
    State: idle
    AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run <time> ago
    Deployments:

    Pour afficher la liste des déploiements avec les détails des paquets mis à jour, exécutez la commande rpm-ostree status -v.

11.5. Rétablissement de RHEL pour les images Edge

Vous pouvez vérifier si l'image mise à jour a été déployée avec succès ou non. Si le déploiement échoue, vous pouvez revenir à une version antérieure (commit). Pour revenir à un état fonctionnel antérieur, vous pouvez soit effectuer les étapes manuellement, soit utiliser un processus automatisé.

11.5.1. Comment les images RHEL for Edge sont-elles réintégrées ?

Avec les images RHEL for Edge, seules les mises à jour transactionnelles sont appliquées au système d'exploitation. Avec les mises à jour transactionnelles, vous pouvez facilement revenir sur les mises à jour infructueuses jusqu'au dernier bon état connu, ce qui permet d'éviter toute défaillance du système pendant les mises à jour.

Vous pouvez utiliser des retours en arrière intelligents avec Greenboot pour éliminer les problèmes de choix entre la stabilité de l'application et l'application des mises à jour de sécurité.

Greenboot exploite le site rpm-ostree et exécute des contrôles de santé personnalisés au démarrage du système. En cas de problème, le système annule les modifications et préserve le dernier état de fonctionnement. Lorsque vous déployez une mise à jour rpm-ostree, elle exécute des scripts pour vérifier que les services critiques peuvent encore fonctionner après la mise à jour. Si le système ne fonctionne pas, la mise à jour revient à la dernière version fonctionnelle connue du système. Ce processus garantit que votre dispositif RHEL for Edge est dans un état opérationnel.

Voici la structure du répertoire de Greenboot :

Exemple 11.1. Structure des répertoires de Greenboot

etc
└─ greenboot
   ├─ check
   |   └─ required.d
   |   └─ init.py
   └─ green.d
   └─ red.d
/etc/greenboot/check/required.d
Contient les contrôles de santé qui ne doivent pas échouer.
/etc/greenboot/check/wanted.d
Contient les contrôles de santé susceptibles d'échouer.
/etc/greenboot/green.d
Contient les scripts à exécuter après un démarrage réussi.
/etc/greenboot/red.d
Contient les scripts à exécuter après un échec de démarrage. Le système tente de démarrer trois fois et, en cas d'échec, il exécute les scripts.

Le diagramme suivant illustre le processus de retour en arrière de l'image RHEL for Edge.

Image restoration process

11.5.2. Rétablissement manuel des images RHEL for Edge

Si le déploiement de la mise à jour de l'image RHEL for Edge échoue ou si la mise à jour ne fonctionne pas correctement, vous pouvez revenir manuellement à une version de déploiement antérieure.

Pour revenir à une version antérieure, procédez comme suit :

Procédure

  1. Exécutez la commande rollback:

    # rpm-ostree rollback

    La sortie de la commande fournit des détails sur l'ID d'engagement qui est déplacé et indique une transaction terminée avec les détails du paquet supprimé.

  2. Redémarrer le système.

    # systemctl reboot

    La commande active le commit précédent avec le contenu stable. Les modifications sont appliquées et la version précédente est restaurée.

11.5.3. Rolling back des images RHEL for Edge à l'aide d'un processus automatisé

Les contrôles Greenboot fournissent un cadre intégré au processus de démarrage et peuvent déclencher des retours en arrière à l'adresse rpm-ostree lorsqu'un contrôle de santé échoue. Pour les contrôles de santé, vous pouvez créer un script personnalisé qui indique si un contrôle de santé a réussi ou échoué. En fonction du résultat, vous pouvez décider du moment où un retour en arrière doit être déclenché.

Pour créer un script de bilan de santé, procédez comme suit :

Procédure

  1. Créez un script qui renvoie un code de sortie standard 0.

    Par exemple, le script suivant permet de s'assurer que le serveur DNS configuré est disponible :

    #!/bin/bash
    
    DNS_SERVER=$(grep ^nameserver /etc/resolv.conf | head -n 1 | cut -f2 -d" ")
    COUNT=0
    # check DNS server is available
    ping -c1 $DNS_SERVER
    while [ $? != '0' ] && [ $COUNT -lt 10 ]; do
    ((COUNT++))
    echo "Checking for DNS: Attempt $COUNT ."
    sleep 10
    ping -c 1 $DNS_SERVER
    done
  2. Inclure un fichier exécutable pour les contrôles sanitaires à l'adresse /etc/greenboot/check/required.d/.

    chmod +x check-dns.sh

    Lors du redémarrage suivant, le script est exécuté dans le cadre du processus de démarrage, avant que le système n'entre dans la cible boot-complete.target. Si les contrôles de santé sont réussis, aucune action n'est entreprise. Dans le cas contraire, le système est redémarré plusieurs fois, avant de marquer l'échec de la mise à jour et de revenir à la mise à jour précédente.

Verification steps

Pour vérifier si la passerelle par défaut est accessible, exécutez le script de contrôle de santé suivant :

  1. Créez un script qui renvoie un code de sortie standard 0.

    #!/bin/bash
    
    DEF_GW=$(ip r | awk '/^default/ {print $3}')
    SCRIPT=$(basename $0)
    
    count=10
    connected=0
    ping_timeout=5
    interval=5
    
    while [ $count -gt 0 -a $connected -eq 0 ]; do
      echo "$SCRIPT: Pinging default gateway $DEF_GW"
      ping -c 1 -q -W $ping_timeout $DEF_GW > /dev/null 2>&1 && connected=1 || sleep $interval
      ((--count))
    done
    
    if [ $connected -eq 1 ]; then
      echo "$SCRIPT: Default gateway $DEF_GW is reachable."
      exit 0
    else
      echo "$SCRIPT: Failed to ping default gateway $DEF_GW!" 1>&2
      exit 1
    fi
  2. Inclure un fichier exécutable pour les contrôles de santé dans le répertoire /etc/greenboot/check/required.d/.

    chmod +x check-gw.sh

Annexe A. Terminologie et commandes

En savoir plus sur la terminologie et les commandes de rpm ostree.

A.1. Terminologie OSTree et rpm-ostree

Voici quelques termes utiles utilisés dans le contexte des images OSTree et rpm-ostree.

Tableau A.1. Terminologie OSTree et rpm-ostree

TermeDéfinition

OSTree

Outil utilisé pour gérer les versions des systèmes d'exploitation basés sur Linux. L'arborescence d'OSTree est similaire à celle de Git et repose sur des concepts similaires.

rpm-ostree

Une image hybride ou un paquet système qui héberge les mises à jour du système d'exploitation.

Commit

Une version ou une image du système d'exploitation. Image builder génère un ostree commit pour les images RHEL for Edge. Vous pouvez utiliser ces images pour installer ou mettre à jour RHEL sur des serveurs Edge.

Refs

Représente une branche dans ostree. Les références renvoient toujours au dernier commit. Par exemple, rhel/9/x86_64/edge.

Revision (Rev)

SHA-256 pour une livraison spécifique.

Remote

Le point d'accès http ou https qui héberge le contenu d'ostree. C'est analogue au baseurl d'un dépôt dnf.

static-delta

Les mises à jour des images ostree sont toujours des mises à jour delta. Dans le cas des images RHEL for Edge, la surcharge TCP peut être plus élevée que prévu en raison des mises à jour d'un certain nombre de fichiers. Pour éviter la surcharge TCP, vous pouvez générer un delta statique entre des commits spécifiques et envoyer la mise à jour dans une seule connexion. Cette optimisation permet de faciliter les déploiements de grande envergure avec une connectivité limitée.

A.2. Commandes OSTree

Le tableau suivant présente quelques commandes OSTree que vous pouvez utiliser lors de l'installation ou de la gestion des images OSTree.

Tableau A.2. commandes d'ostree

ostree pull

ostree pull-local --repo [path] src

ostree pull-local <path> <rev> --repo=<repo-path>

ostree pull <URL> <rev> --repo=<repo-path>

résumé d'ostree

ostree summary -u --repo=<repo-path>

Voir les arbitres

ostree refs --repo ~/Code/src/osbuild-iot/build/repo/ --list

Voir les commits dans le repo

ostree log --repo=/home/gicmo/Code/src/osbuild-iot/build/repo/ <REV>

Inspecter un commit

ostree show --repo build/repo <REV>

Liste des remotes d'un repo

ostree remote list --repo <repo-path>

Résoudre un REV

ostree rev-parse --repo ~/Code/src/osbuild-iot/build/repo fedora/x86_64/osbuild-demo

ostree rev-parse --repo ~/Code/src/osbuild-iot/build/repo b3a008eceeddd0cfd

Créer un delta statique

ostree static-delta generate --repo=[path] --from=REV --to=REV

Signer un commit existing ostree avec une clé GPG

ostree gpg-sign --repo=<repo-path> --gpg-homedir <gpg_home> COMMIT KEY-ID…

A.3. rpm-ostree commandes

Le tableau suivant fournit quelques commandes rpm-ostree que vous pouvez utiliser lors de l'installation ou de la gestion des images OSTree.

Tableau A.3. rpm-ostree commandes

CommandesDescription

rpm-ostree --repo=/home/gicmo/Code/src/osbuild-iot/build/repo/ db list <REV>

Cette commande liste les paquets existant dans le commit <REV> dans le dépôt.

rpm-ostree rollback

OSTree gère une liste ordonnée d'entrées de chargeur de démarrage, appelée deployments. L'entrée à l'index 0 est l'entrée du chargeur de démarrage par défaut. Chaque entrée possède un répertoire /etc distinct, mais toutes les entrées partagent un répertoire /var unique. Vous pouvez utiliser le chargeur de démarrage pour choisir entre les entrées en appuyant sur Tab pour interrompre le démarrage. Cela permet de revenir à l'état précédent, c'est-à-dire que le déploiement par défaut remplace celui qui n'est pas par défaut.

rpm-ostree status

This command gives information about the current deployment in use. Lists the names and refspecs of all possible deployments in order, such that the first deployment in the list is the default upon boot. The deployment marked with * is the current booted deployment, and marking with 'r' indicates the most recent upgrade.

rpm-ostree db list

Utilisez cette commande pour voir quels paquets se trouvent dans le ou les commit(s). Vous devez spécifier au moins un commit, mais plusieurs ou une série de commits peuvent également être utilisés.

rpm-ostree db diff

Utilisez cette commande pour montrer comment les paquets sont différents entre les arbres de deux révisions (revs). Si aucune révision n'est fournie, la livraison démarrée est comparée à la livraison en attente. Si une seule révision est fournie, la livraison démarrée est comparée à cette révision.

rpm-ostree upgrade

Cette commande télécharge la dernière version de l'arborescence en cours et la déploie, faisant de l'arborescence en cours l'arborescence par défaut au prochain démarrage. Cette commande n'a aucun effet sur l'arborescence du système de fichiers en cours d'exécution. Vous devez redémarrer pour que les modifications soient prises en compte.

Ressources supplémentaires

  • La page de manuel [citetitle] rpm-ostree.

A.4. Terminologie de l'embarquement automatique FDO

En savoir plus sur la terminologie du FDO.

Tableau A.4. Terminologie FDO

CommandesDescription

FDO

L'embarquement des dispositifs FIDO.

Dispositif

Tout matériel, dispositif ou ordinateur.

Propriétaire

Le propriétaire final de l'appareil - une entreprise ou un service informatique.

Fabricant

Le fabricant de l'appareil.

Serveur du fabricant

Crée les informations d'identification de l'appareil.

Client fabricant

Indique l'emplacement du serveur de fabrication.

Bon de propriété (OV)

Enregistrement de la propriété d'un appareil individuel. Contient les informations suivantes :

* Propriétaire (fdo-owner-onboarding-service)

* Serveur Rendezvous - Serveur FIDO (fdo-rendezvous-server)

* Dispositif (au moins une combinaison) (fdo-manufacturing-service)

Certificat de dispositif (DC)

Clé d'identification et de rendez-vous stockée dans l'appareil au moment de sa fabrication.

Clés

Clés de configuration du serveur de fabrication

* chemin_clé

* chemin_cert

* type_clé

* mfg_string_type : numéro de série de l'appareil

* types_de_stockage_de_clés_autorisés : Système de fichiers et Trusted Platform Module (TPM) qui protège les données utilisées pour authentifier l'appareil que vous utilisez.

Serveur de rendez-vous

Lien vers un serveur utilisé par l'appareil et, par la suite, utilisé dans le cadre du processus visant à déterminer le propriétaire de l'appareil

Ressources supplémentaires

A.5. Technologies d'embarquement automatique FDO

Les technologies utilisées dans le cadre de l'embarquement automatique FDO sont les suivantes.

Tableau A.5. Terminologie OSTree et rpm-ostree

TechnologieDéfinition

UEFI

Interface micrologicielle extensible unifiée.

RHEL

Système d'exploitation Red Hat® Enterprise Linux

rpm-ostree

Améliorations basées sur l'image de fond.

Pieds verts

Healthcheck pour systemd sur rpm-ostree.

Osbuild

Système de construction basé sur un pipeline pour les artefacts du système d'exploitation.

Conteneur

Un conteneur Linux® est un ensemble d'un ou plusieurs processus isolés du reste du système.

Coreos-installer

Aide à l'installation des images RHEL, démarre les systèmes avec UEFI.

FIDO FDO

Protocole de spécification pour l'approvisionnement des dispositifs de configuration et d'accueil.

Note légale

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.