3 Edge Image Builderを使用したスタンドアロンクラスタ #

Edge Image Builder (EIB)は、完全なエアギャップシナリオでもマシンをブートストラップできるCustomized, Ready-to-Boot (CRB)ディスクイメージの生成プロセスを効率化するツールです。EIBを使用すると、SUSE Edgeの3つのデプロイメントフットプリントすべてで使用するデプロイメントイメージを作成できます。これは、EIBが十分に柔軟であり、最小限のカスタマイズ(例: ユーザの追加やタイムゾーンの設定)から、あらゆる設定を網羅したイメージ(例: 複雑なネットワーク設定を行い、マルチノードKubernetesクラスタをデプロイして、顧客ワークロードをデプロイし、Rancher/ElementalとSUSE Managerを介して集中管理プラットフォームに登録するイメージ)までを提供できるためです。EIBはコンテナイメージ内で動作するため、プラットフォーム間できわめて容易に移植可能です、さらに、必要な依存関係をすべて備えた自己完結型であるため、EIBツールの操作に使用するシステムにインストール済みのパッケージに及ぼす影響が最小限に抑えられます。

詳細については、Edge Image Builderの紹介(第9章「Edge Image Builder」)を参照してください。

3.1 前提条件 #

SLES 15 SP5、openSUSE Leap 15.5、またはopenSUSE Tumbleweedを実行しているx86_64物理ホスト(または仮想マシン)
利用可能なコンテナランタイム(Podmanなど)
最新のSLE Micro 5.5 SelfInstall「GM2」ISOイメージのダウンロードコピー(こちらにあります)

注記

互換性のあるコンテナランタイムが利用可能であれば、他のオペレーティングシステムでも機能する可能性はありますが、他のプラットフォームでは広範なテストは行われていません。このドキュメントではPodmanに焦点を当てていますが、Dockerでも同じ機能を実現できるはずです。

3.1.1 EIBイメージの取得 #

EIBのコンテナイメージは一般に公開されており、イメージ構築ホストで次のコマンドを実行することでSUSE Edgeレジストリからダウンロードできます。

podman pull registry.suse.com/edge/edge-image-builder:1.0.2

3.2 イメージ設定ディレクトリの作成 #

EIBはコンテナ内で動作するため、ホストから設定ディレクトリをマウントして、必要な設定を指定できるようにする必要があります。ビルドプロセス中に、EIBは必要な入力ファイルやサポートアーティファクトすべてにアクセスできます。このディレクトリは、特定の構造に従う必要があります。このディレクトリがホームディレクトリに存在し、「eib」という名前であると仮定して、ディレクトリを作成してみましょう。

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

前の手順では、SLE Micro 5.5の入力イメージをホストする「base-images」ディレクトリを作成しました。ダウンロードしたイメージをこの設定ディレクトリに確実にコピーしましょう。

cp /path/to/downloads/SLE-Micro.x86_64-5.5.0-Default-SelfInstall-GM2.install.iso $CONFIG_DIR/base-images/slemicro.iso

注記

EIBの実行中に元のゴールデンイメージは変更「されません」。EIBの設定ディレクトリのルートに、目的の設定でカスタマイズされた新しいバージョンが作成されます。

この時点では、設定ディレクトリは次のようになっているはずです。

└── base-images/
    └── slemicro.iso

3.3 イメージ定義ファイルの作成 #

定義ファイルには、Edge Image Builderがサポートする設定可能なオプションの大部分が記述されています。オプションの完全な例については、こちらを参照してください。以下で説明する例よりも広範な例については、アップストリームのイメージ構築ガイドを参照することをお勧めします。まずは、OSイメージの非常に基本的な定義ファイルから始めましょう。

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
EOF

この定義では、x86_64ベースのシステム用の出力イメージを生成するように指定しています。さらに変更を加えるためのベースとして使用するイメージは、slemicro.isoという名前のisoイメージであり、$CONFIG_DIR/base-images/slemicro.isoにあることが想定されています。また、EIBがイメージの変更を完了すると、出力イメージはeib-image.isoという名前になり、デフォルトでは$CONFIG_DIRに存在することも記述されています。

これで、ディレクトリ構造は次のようになります。

├── iso-definition.yaml
└── base-images/
    └── slemicro.iso

以降のセクションでは、一般的な操作の例をいくつか紹介していきます。

3.3.1 OSユーザの設定 #

EIBを使用すると、パスワードやSSHキーなどのログイン情報を事前にユーザに設定できます(固定されたルートパスワードの設定も含む)。この例の一部として、ルートパスワードを修正します。最初の手順は、OpenSSLを使用して一方向暗号化パスワードを作成することです。

openssl passwd -6 SecurePassword

これは次のような出力になります。

$6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

次に、定義ファイルにoperatingSystemというセクションを追加し、その中にusers配列を含めます。作成したファイルは次のようになります。

apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

注記

ユーザの追加、ホームディレクトリの作成、ユーザIDの設定、ssh-key認証の追加、グループ情報の変更も行うことができます。他の例については、アップストリームのイメージ構築ガイドを参照してください。

3.3.2 RPMパッケージの設定 #

EIBの主な特徴の1つは、イメージにソフトウェアパッケージを追加するメカニズムを備えていることです。このため、インストールが完了した時点で、システムはインストールされたパッケージをすぐに利用できます。EIBでは、ユーザは以下を行うことができます。

イメージ定義のリスト内の名前でパッケージを指定する
これらのパッケージを検索するネットワークリポジトリを指定する
一覧にされたパッケージをSUSEの公式リポジトリで検索するためのSUSE Customer Center (SCC)資格情報を指定する
$CONFIG_DIR/rpmsディレクトリ経由で、ネットワークリポジトリに存在しないカスタムRPMをサイドロードする
同じディレクトリ($CONFIG_DIR/rpms/gpg-keys)経由で、サードパーティ製パッケージの検証を有効にするためにGPGキーを指定する

これにより、EIBは、イメージの構築時にパッケージ解決プロセスを実行し、ゴールデンイメージを入力として受け取り、提供されているパッケージ(リストで指定されているか、ローカルで提供されているパッケージ)をすべてプルしてインストールしようと試みます。EIBは、依存関係を含むすべてのパッケージを出力イメージ内に存在するリポジトリにダウンロードし、そのパッケージを初回ブートプロセス中にインストールするようにシステムに指示します。イメージの構築中にこのプロセスを実行することで、初回ブート時にパッケージが目的のプラットフォーム(エッジのノードなど)が正常にインストールされることが保証されます。これは、操作時に追加パッケージをネットワーク経由でプルするのではなく、イメージに事前に書き込んでおきたい環境でも便利です。たとえば、エアギャップ環境や、ネットワークが制限された環境です。

これを示すシンプルな例として、サードパーティベンダがサポートするNVIDIAリポジトリにあるnvidia-container-toolkit RPMパッケージをインストールします。

  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

生成される定義ファイルは次のようになります。

apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

上記はシンプルな例ですが、完全を期するために、イメージ生成を実行する前にNVIDIAパッケージ署名キーをダウンロードしてください。

$ mkdir -p $CONFIG_DIR/rpms/gpg-keys
$ curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey > rpms/gpg-keys/nvidia.gpg

警告

この方法でRPMを追加することは、サポートされているサードパーティコンポーネント、またはユーザが提供(および保守)するパッケージを追加することを目的としています。このメカニズムは、通常ではSLE Microでサポートされないパッケージを追加する目的では使用しないでください。このメカニズムを使用して、openSUSEのリポジトリから新しいリリースやサービスパックなどのコンポーネントを追加した場合(この操作はサポートされません)、最終的にサポート対象外の設定になるおそれがあります。特に、依存関係の解決によってオペレーティングシステムのコア部分が置き換えられる場合は、作成されたシステムが期待どおりに機能しているように見えても注意が必要です。確信が持てない場合は、SUSEの担当者に連絡してサポートを依頼し、目的の設定がサポート可能かどうかを判断してください。

注記

追加の例を含む総合的なガイドについては、アップストリームのパッケージインストールガイドを参照してください。

3.3.3 Kubernetesクラスタとユーザワークロードの設定 #

EIBのもう1つの特徴は、EIBを使用すると、「インプレースでブートストラップ」する、つまり調整のためにどのような形態の集中管理インフラストラクチャも必要としない、シングルノードとマルチノード両方の高可用性Kubernetesクラスタのデプロイメントを自動化できることです。このアプローチは主にエアギャップデプロイメント、すなわちネットワークが制限された環境のためのものですが、ネットワークに制限なく完全にアクセスできる場合であっても、スタンドアロンクラスタを迅速にブートストラップする方法として役立ちます。

この方法を使用すると、カスタマイズされたオペレーティングシステムをデプロイできるだけでなく、Kubernetesの設定を指定したり、Helmチャートを介して追加の階層化コンポーネントを指定したり、指定したKubernetesマニフェストを介してユーザワークロードを指定したりすることもできます。ただしこの方法を使用する場合、その背景にある設計理念として、ユーザがエアギャップ化を望んでいるとデフォルトで想定します。したがって、イメージ定義で指定されているすべての項目を、ユーザが指定したワークロードを含めてイメージにプルします。その際に、EIBは、提供された定義で要求されている検出済みイメージをすべてローカルにコピーし、作成されたデプロイ済みシステムの組み込みのイメージレジストリで提供します。

次の例では、既存のイメージ定義を使用してKubernetesの設定を指定します(この例では、複数のシステムとその役割が一覧にされていないため、デフォルトでシングルノードを想定します)。この設定により、シングルノードのRKE2 KubernetesクラスタをプロビジョニングするようにEIBに指示します。ユーザが指定したワークロード(マニフェストを使用)と階層化コンポーネント(Helmを使用)の両方のデプロイメントの自動化を説明するために、SUSE EdgeのHelmチャートを使用してKubeVirtをインストールし、Kubernetesマニフェストを使用してNGINXをインストールします。既存のイメージ定義に追加する必要がある設定は次のとおりです。

kubernetes:
  version: v1.28.9+rke2r1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt-chart
        version: 0.2.4
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge

作成された完全な定義ファイルは次のようになります。

apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
kubernetes:
  version: v1.28.9+rke2r1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt-chart
        version: 0.2.4
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge

注記

マルチノードデプロイメント、カスタムネットワーキング、Helmチャートのオプション/値など、オプションの他の例については、アップストリームドキュメントを参照してください。

3.3.4 ネットワークの設定 #

このクイックスタートの最後の例では、EIBで生成したイメージを使ってシステムをプロビジョニングした場合に作成されるネットワークを設定しましょう。ネットワーク設定を指定しない限り、ブート時に検出されたすべてのインタフェースでDHCPが使用されるのがデフォルトのモデルであることを理解することが重要です。ただし、これが常に望ましい設定であるとは限りません。これは特に、DHCPが利用できず静的な設定を指定する必要がある場合や、より複雑なネットワーキング構造(ボンド、LACP、VLANなど)を設定する必要がある場合、特定のパラメータ(ホスト名、DNSサーバ、ルートなど)を上書きする必要がある場合に該当します。

EIBでは、ノードごとの設定を指定することも(対象のシステムをMACアドレスで一意に識別します)、上書きによって各マシンに同一の設定を指定することもできます(システムのMACアドレスが不明な場合に便利です)。またEIDでは、Network Manager Configurator (nmc)というツールも追加で使用されます。Network Manager ConfiguratorはSUSE Edgeチームによって構築されたツールであり、nmstate.ioの宣言型ネットワークスキーマに基づいてカスタムネットワーキング設定を適用できるようにします。また、ブートしているノードをブート時に識別し、必要なネットワーク設定をサービス開始前に適用します。

ここでは、1つのインタフェースを持つシステムに静的ネットワーク設定を適用します。そのために、ネットワークの望ましい状態を、必要なnetworkディレクトリ内にある(目的のホスト名に基づく)ノード固有のファイルに記述します。

mkdir $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/host1.local.yaml
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address:
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - 192.168.122.1
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: 34:8A:B1:4B:16:E7
  ipv4:
    address:
    - ip: 192.168.122.50
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false
EOF

警告

上記の例は、テストを仮想マシン上で実行すると仮定して、デフォルトの192.168.122.0/242サブネット用に設定されています。ご使用の環境に合わせて、MACアドレスも忘れずに変更してください。同じイメージを使用して複数のノードをプロビジョニングできるため、 EIBで(nmcを介して)設定されたネットワーキングは、各ノードをMACアドレスで一意に識別できるかどうかに依存しており、その後、ブート中にnmcは正しいネットワーキング設定を各マシンに適用します。つまり、インストール先のシステムのMACアドレスを把握する必要があります。また、デフォルトの動作ではDHCPに依存しますが、configure-network.shフックを利用して、すべてのノードに共通の設定を適用することもできます。詳細については、ネットワーキングのガイド (第10章「Edgeネットワーキング」)を参照してください。

作成されるファイル構造は、次のようになります。

├── iso-definition.yaml
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

作成したネットワーク設定が解析され、必要なNetworkManager接続ファイルが自動的に生成されて、EIBが作成する新しいインストールイメージに挿入されます。これらのファイルはホストのプロビジョニング中に適用され、完全なネットワーク設定が生成されます。

注記

上記の設定のより包括的な説明と、この機能の例については、エッジネットワーキングのコンポーネント(第10章「Edgeネットワーキング」)を参照してください。

3.4 イメージの構築 #

EIBで使用するゴールデンイメージとイメージ定義ができたので、イメージを構築してみましょう。これには、podmanを使用し、定義ファイルを指定して「build」コマンドでEIBコンテナを呼び出すだけです。

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/edge-image-builder:1.0.2 \
build --definition-file iso-definition.yaml

コマンドの出力は次のようになります。

Setting up Podman API listener...
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Resolving package dependencies...
Rpm .......................... [SUCCESS]
Systemd ...................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Downloading file: dl-manifest-1.yaml 100%  (498/498 B, 5.9 MB/s)
Populating Embedded Artifact Registry... 100%  (3/3, 11 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% (782/782 MB, 98 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% (367/367 MB, 100 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100%  (34/34 MB, 101 MB/s)
Downloading file: sha256sum-amd64.txt 100%  (3.9/3.9 kB, 1.5 MB/s)
Downloading file: dl-manifest-1.yaml 100%  (498/498 B, 7.2 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Image build complete!

構築されたISOイメージは$CONFIG_DIR/eib-image.isoに保存されます。

├── iso-definition.yaml
├── eib-image.iso
├── _build
│   └── cache/
│       └── ...
│   └── build-<timestamp>/
│       └── ...
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

ビルドごとに、$CONFIG_DIR/_build/内にタイムスタンプ付きのフォルダが作成されます。このフォルダには、ビルドのログ、ビルド中に使用されたアーティファクト、およびCRBイメージに追加されたすべてのスクリプトとアーティファクトを含むcombustionディレクトリとartefactsディレクトリが含まれます。

このディレクトリの内容は次のようになります。

├── build-<timestamp>/
│   │── combustion/
│   │   ├── 05-configure-network.sh
│   │   ├── 10-rpm-install.sh
│   │   ├── 12-keymap-setup.sh
│   │   ├── 13b-add-users.sh
│   │   ├── 20-k8s-install.sh
│   │   ├── 26-embedded-registry.sh
│   │   ├── 48-message.sh
│   │   ├── network/
│   │   │   ├── host1.local/
│   │   │   │   └── eth0.nmconnection
│   │   │   └── host_config.yaml
│   │   ├── nmc
│   │   └── script
│   │── artefacts/
│   │   │── registry/
│   │   │   ├── hauler
│   │   │   ├── nginx:1.14.2-registry.tar.zst
│   │   │   ├── rancher_kubectl:v1.28.7-registry.tar.zst
│   │   │   └── registry.suse.com_suse_sles_15.5_virt-operator:1.1.1-150500.8.12.1-registry.tar.zst
│   │   │── rpms/
│   │   │   └── rpm-repo
│   │   │       ├── addrepo0
│   │   │       │   └── x86_64
│   │   │       │       ├── nvidia-container-toolkit-1.15.0-1.x86_64.rpm
│   │   │       │       ├── ...
│   │   │       ├── repodata
│   │   │       │   ├── ...
│   │   │       └── zypper-success
│   │   └── kubernetes/
│   │       ├── rke2_installer.sh
│   │       ├── registries.yaml
│   │       ├── server.yaml
│   │       ├── images/
│   │       │   ├── rke2-images-cilium.linux-amd64.tar.zst
│   │       │   └── rke2-images-core.linux-amd64.tar.zst
│   │       ├── install/
│   │       │   ├── rke2.linux-amd64.tar.gz
│   │       │   └── sha256sum-amd64.txt
│   │       └── manifests/
│   │           ├── dl-manifest-1.yaml
│   │           └── kubevirt-chart.yaml
│   ├── createrepo.log
│   ├── eib-build.log
│   ├── embedded-registry.log
│   ├── helm
│   │   └── kubevirt-chart
│   │       └── kubevirt-0.2.4.tgz
│   ├── helm-pull.log
│   ├── helm-template.log
│   ├── iso-build.log
│   ├── iso-build.sh
│   ├── iso-extract
│   │   └── ...
│   ├── iso-extract.log
│   ├── iso-extract.sh
│   ├── modify-raw-image.sh
│   ├── network-config.log
│   ├── podman-image-build.log
│   ├── podman-system-service.log
│   ├── prepare-resolver-base-tarball-image.log
│   ├── prepare-resolver-base-tarball-image.sh
│   ├── raw-build.log
│   ├── raw-extract
│   │   └── ...
│   └── resolver-image-build
│       └──...
└── cache
    └── ...

ビルドが失敗した場合、情報が含まれる最初のログはeib-build.logです。そこから、失敗したコンポーネントに移動してデバッグを行います。

この時点で、以下を行う、すぐに使用できるイメージができているはずです。

SLE Micro 5.5をデプロイする
ルートパスワードを設定する
nvidia-container-toolkitパッケージをインストールする
コンテンツをローカルに提供する組み込みのコンテナレジストリを設定する
シングルノードRKE2をインストールする
静的ネットワーキングを設定する
KubeVirtをインストールする
ユーザが指定したマニフェストをデプロイする

3.5 イメージ構築プロセスのデバッグ #

イメージ構築プロセスが失敗する場合は、アップストリームのデバッグガイドを参照してください。

3.6 新しく構築されたイメージのテスト #

新しく構築されたCRBイメージをテストする方法については、アップストリームのイメージテストガイドを参照してください。