Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Référence Cloud-config

Les images du système d’exploitation Node construites à l’aide du SUSE® Rancher Prime: OS Manager Toolkit doivent être initialisées et configurées en utilisant yip. Yip est un petit utilitaire pour appliquer un ensemble d’actions et de configurations au système décrit avec des fichiers yaml. Yip est intégré et utilisé comme une bibliothèque dans le binaire client élémentaire (voir elemental run-stage --help). Yip regroupe les configurations et les actions à appliquer en étapes arbitraires, par exemple, l’appel de commande elemental run-stage network n’appliquerait que les actions et configurations définies pour l’étape nommée network. Notez que du point de vue de Yip, les étapes peuvent être exécutées à tout moment car elles regroupent simplement un ensemble d’actions sous un nom arbitraire.

Le SUSE® Rancher Prime: OS Manager Toolkit intègre cinq étapes prédéfinies dans le processus de démarrage de l’OS.

  1. pre-rootfs : Cette étape s’exécute au début du démarrage à l’intérieur du disque RAM d’init, juste avant de monter le périphérique racine (typiquement à /sysroot). Cette étape peut être utilisée pour définir les étapes de premier démarrage nécessaires avant de monter le périphérique racine. Un bon exemple est l’extension de la partition du périphérique racine. Exécuté dans le cadre du initrd-root-device.target.

  2. rootfs : Cette étape s’exécute au début du démarrage à l’intérieur du disque RAM d’init, juste après avoir monté le périphérique racine (typiquement à /sysroot). Cette étape peut être utilisée pour définir des étapes de premier démarrage comme la création de nouvelles partitions. Les chemins éphémères et persistants sont généralement définis à cette étape. Exécuté dans le cadre du initrd-root-fs.target.

  3. initramfs : Cette étape s’exécute également à l’intérieur du disque RAM d’init, mais à une étape ultérieure juste avant de changer de racine. Cette étape s’exécute dans un environnement dans lequel un chroot a été effectué vers le véritable périphérique racine. Cette étape est utile pour définir certains paramètres système qui pourraient être pertinents pour systemd après le changement de racine. Par exemple, des fichiers d’unité systemd supplémentaires pourraient être ajoutés ici avant que systemd du véritable périphérique racine ne soit exécuté. Exécuté dans le cadre du initrd.target.

  4. fs : Cette étape est la première exécutée après le changement de racine et elle est exécutée dans le cadre du sysinit.target qui s’exécute une fois que tous les systèmes de fichiers locaux et les points de montage définis dans fstab sont montés et prêts.

  5. network : Cette étape est exécutée dans le cadre du multi-user.target et après que le network-online.target soit atteint. Cette étape peut être utilisée pour exécuter des actions et des configurations nécessitant une connectivité réseau. Par exemple, cette étape est utilisée pour exécuter l’enregistrement du tout premier nœud et l’installation à partir d’un ISO en direct.

  6. boot : Cette étape est exécutée dans le cadre du multi-user.target et avant le getty.target. C’est l’étape par défaut pour exécuter les données cloud-config fournies en utilisant la syntaxe cloud-init prise en charge. Voir la section compatibilité cloud-init.

Par défaut, elemental lit les fichiers de configuration yaml à partir des chemins suivants dans l’ordre : /system/oem, /oem et /usr/local/cloud-config.

Dans SUSE® Rancher Prime: OS Manager Operator, toutes les ressources Kubernetes, y compris un champ cloud-config, peuvent être exprimées en syntaxe yip ou compatible cloud-init. Cela inclut des ressources telles que MachineRegistration, SeedImage et ManagedOSImage.

Contrairement à des projets similaires tels que Cloud Init, Yip ne conserve pas d’enregistrements ou de caches des étapes et des phases exécutées, toutes les étapes et leur configuration associée sont exécutées à chaque démarrage.

Hooks cloud-config du client Elemental

En plus des étapes cloud-config définies au démarrage décrites dans la section précédente, le client Elemental respecte également certaines étapes spécifiques, référencées comme hooks, pour personnaliser le comportement de ces sous-commandes : install, upgrade, reset et build-disk. Chacune de ces sous-commandes a son propre ensemble de quatre étapes cloud-config différentes exécutées à des phases analogues de l’exécution de la sous-commande spécifique.

Les hooks sont essentiellement un moyen d’apporter des modifications permanentes au système qui ne peuvent pas être facilement exprimées dans le cadre d’un conteneur OCI ou qui ne sont pas facilement réalisables avec les options de configuration du client elemental. Un bon exemple pourrait être la gestion du firmware dans la partition EFI pour les appareils Raspberry Pi.

Notez que la plupart des hooks sont exécutés dans l’environnement hôte avec des privilèges, donc ce sont potentiellement des opérations destructrices. Dans la plupart des cas, les opérations cloud-config régulières au démarrage sont suffisantes pour configurer le système. De plus, pour inclure des logiciels supplémentaires dans une image, l’option préférée est de construire une image dérivée et de ne pas abuser des hooks pour installer des logiciels supplémentaires.

Étapes des hooks

Avant les étapes : avant-installation, avant-mise à niveau, avant-réinitialisation, avant-disque Ces étapes sont exécutées une fois que les répertoires de travail et l’environnement sont préparés, mais avant de commencer l’action réelle. Dans les étapes d’installation, de mise à niveau et de réinitialisation, cela se produit une fois que toutes les partitions associées sont créées et montées, mais avant de commencer le déploiement de toute image.

Après les étapes chrootées : après-installation-chroot, après-mise à niveau-chroot, après-réinitialisation-chroot, après-disque-chroot Ces étapes sont exécutées après le déploiement du système cible dans la zone de travail dans un environnement chroot ancré à l’image déployée. Puisque cela se produit dans un environnement dans lequel un chroot a été effectué, le client élémentaire analyse les hooks présents dans l’image déployée, et non dans l’hôte. Seul /oem est partagé avec l’hôte si disponible.

Après les étapes : après-installation, après-mise à niveau, après-réinitialisation, après-disque Ces étapes sont exécutées après le déploiement du système cible dans la zone de travail depuis l’environnement hôte. À ce stade, toutes les partitions sont encore montées et disponibles en mode lecture-écriture. Cet ensemble particulier d’étapes analyse les hooks présents dans l’hôte et dans l’ensemble équivalent de chemins où un chroot a été effectué vers l’image déployée. Cependant, le hook n’est pas exécuté dans un environnement dans lequel un chroot a été effectué. Ceci est utile pour fournir des hooks dans l’image déployée.

Étapes postérieures : post-installation, post-mise à niveau, post-réinitialisation, post-disque. Ces étapes sont exécutées à la fin, avant de quitter la commande et de lancer un processus de nettoyage. À ce stade, l’image est déjà déployée et verrouillée dans un sous-volume ou un système de fichiers en lecture seule. Les partitions sont encore montées à ce stade.

Notez que les crochets d’installation ne sont pas appliqués dans le cadre du MachineRegistration.config.cloud-config. Pour fournir des crochets d’installation, ils peuvent être inclus dans le cadre du xref:[SeedImage.cloud-config], car ils doivent être présents dans le support d’installation.

Syntaxe de configuration

Yip a sa propre syntaxe, elle nécessite essentiellement de définir étapes et une liste d’étapes pour chaque étape. Les étapes sont exécutées dans l’ordre et chaque étape peut être une combinaison de différents types d’actions (par exemple, exécuter des commandes, créer des fichiers, définir un nom d’hôte, etc.).

Prenons l’exemple suivant :

stages:
  initramfs:
  - name: "Setup users"
    ensure_entities:
    - path: /etc/shadow
      entity: |
          kind: "shadow"
          username: "root"
          password: "root"
  boot:
  - files:
    - path: /tmp/script.sh
      content: |
        #!/bin/sh
        echo "test"
      permissions: 0777
      owner: 1000
      group: 100
  - commands:
    - /tmp/script.sh

Dans l’exemple ci-dessus, il y a deux étapes : initramfs et boot. L’étape initramfs initialise un utilisateur d’exemple. L’étape boot comprend deux étapes, l’une pour créer un fichier de script exécutable et la seconde qui exécute réellement le script.

Yip prend également en charge les modificateurs de suffixe .before et .after pour toute étape donnée. Par exemple, l’exécution de l’étape network entraîne d’abord l’exécution des étapes network.before trouvées dans les fichiers de configuration, puis network et enfin network.after.

Voir la référence complète des clés applicables aux étapes, documentée dans projet yip lui-même.

Ci-dessous un exemple de la configuration ci-dessus intégrée dans une ressource MachineRegistration.

Cliquez ici pour plus de détails
Exemple de MachineRegistration
apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: my-nodes
  namespace: fleet-default
spec:
  config:
    cloud-config:
      name: "A registration driven config"
      stages:
        after-install-chroot:
        - name: "Set serial console"
          commands:
          - grub2-editenv /oem/grubenv set extra_cmdline="console=ttyS0"
        initramfs:
        - name: "Setup users"
          ensure_entities:
          - path: /etc/shadow
            entity: |
                kind: "shadow"
                username: "root"
                password: "root"
        boot:
        - files:
          - path: /tmp/script.sh
            content: |
              #!/bin/sh
              echo "test"
            permissions: 0777
            owner: 1000
            group: 100
        - commands:
          - /tmp/script.sh
    elemental:
      install:
        reboot: true
        device: /dev/sda
        debug: true
  machineName: my-machine
  machineInventoryLabels:
    element: fire

Synchronisation

Lors de l’exécution d’une étape, tous les fichiers sont chargés et un graphe est calculé puis exécuté. Cela signifie que les étapes d’un même stage peuvent être exécutées dans n’importe quel ordre et indépendamment du nom de fichier.

Pour synchroniser l’exécution, l’utilisateur peut utiliser les étapes post/pré ou se référer au mot-clé after dans le syntaxe yip.

Compatibilité avec le format Cloud Init

Un sous-ensemble de la spécification officielle cloud-config est implémenté par yip. Plus précisément, les clés cloud-init prises en charge, à savoir users, ssh_authorized_keys, runcmd, hostname et write_files, sont implémentées.

Si un fichier yaml commence par #cloud-config, il est analysé comme un cloud-init standard, associé à l’étape yip boot.

Par exemple :

#cloud-config
# Note groups are delivered as list, not as comma separated values
users:
- name: "bar"
  passwd: "foo"
  groups:
  - "users"
  homedir: "/home/foo"
  shell: "/bin/bash"
  ssh_authorized_keys:
  - faaapploo
# Assigns these keys to the first user in users or root if there
# is none
ssh_authorized_keys:
- asddadfafefa
# Run these commands once the system has fully booted
# Each command is expressed as a sinlge string, no nested lists
runcmd:
- echo hello world
# Hostname
hostname: myserver
# Write arbitrary files
write_files:
- encoding: b64
  content: CiMgVGhpcyBmaWxlIGNvbnRyb2xzIHRoZSBzdGF0ZSBvZiBTRUxpbnV4
  path: /foo/bar
  permissions: "0644"
  owner: "bar"

Ci-dessous un exemple de la configuration ci-dessus intégrée dans une ressource MachineRegistration.

Cliquez ici pour plus de détails

Exemple de MachineRegistration

apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: my-nodes
  namespace: fleet-default
spec:
  config:
    cloud-config:
      users:
      - name: "bar"
        passwd: "foo"
        groups: "users"
        homedir: "/home/foo"
        shell: "/bin/bash"
        ssh_authorized_keys:
        - faaapploo
      ssh_authorized_keys:
      - asdd
      runcmd:
      - foo
      write_files:
      - encoding: b64
        content: CiMgVGhpcyBmaWxlIGNvbnRyb2xzIHRoZSBzdGF0ZSBvZiBTRUxpbnV4
        path: /foo/bar
        permissions: "0644"
        owner: "bar"
    elemental:
      install:
        reboot: true
        device: /dev/sda
        debug: true
  machineName: my-machine
  machineInventoryLabels:
    element: fire