Documentation survey

イメージの構築と管理

1. Image building overview

SUSE Multi-Linux Managerでは、システム管理者はコンテナおよびOSイメージを構築し、結果をイメージストアにプッシュできます。

Procedure: Building and pushing images

  1. イメージストアを定義します。

  2. イメージプロファイルを定義し、それをソース(gitリポジトリまたはディレクトリのいずれか)に関連付けます。

  3. イメージを構築します。

  4. イメージをイメージストアにプッシュします。

SUSE Multi-Linux Managerでは、次の2つのビルドタイプ(DockerfileおよびKiwiビルドタイプ)をサポートしています。 Kiwiビルドタイプは、システムイメージ、仮想イメージ、およびその他のイメージの構築に使用されます。

The image store for the Kiwi build type is pre-defined as a file system directory in the srv-www volume.

The image files can be downloaded from https://MANAGER-HOST/os-images/ORGANIZATION-ID/FILE-NAME. The exact location can be determined from the image details page.

2. Container images

2.1. 要件

コンテナ機能は、SUSE Linux Enterprise Server 12以降を実行しているSaltクライアントで使用できます。 開始する前に、ご使用の環境が次の要件を満たしていることを確認してください。

  • Dockerfileと設定スクリプトを含む発行済みのgitリポジトリ。 リポジトリはパブリックにもプライベートにもでき、GitHub、GitLab、またはBitBucketでホストする必要があります。

  • Dockerレジストリなどの適切に設定されたイメージストア。

コンテナの詳細については、https://documentation.suse.com/container/all/html/Container-guide/を参照してください。

2.2. Create a build host

SUSE Multi-Linux Managerでイメージを構築するには、構築ホストを作成して設定する必要があります。 コンテナビルドホストは、SUSE Linux Enterprise 12以降を実行しているSaltクライアントです。 このセクションでは、構築ホストの初期設定について説明します。

構築ホスト上のオペレーティングシステムは、ターゲットイメージ上のオペレーティングシステムと一致する必要があります。

たとえば、SUSE Linux Enterprise Server 15 (SP2以降)のOSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 15ベースのイメージを構築します。 SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 12ベースのイメージを構築します。

クロスアーキテクチャビルドはサポートされていません。

SUSE Multi-Linux Manager Web UIから、次のステップを実行して、構築ホストを設定します。

Procedure: Building a host

  1. システム  システム概要ページから、構築ホストとして指定されるSaltクライアントを選択します。

  2. 選択したクライアントの［システムの詳細］ページから、コンテナモジュールを割り当てます。 ソフトウェア  ソフトウェアチャンネルに移動して、コンテナモジュール(たとえば、［SLE-Module-Containers15-Pool］と［SLE-Module-Containers15-Updates］)を有効にします。 次へで続行します。

  3. ［ソフトウェアチャンネルの変更］をスケジュールし、確認をクリックします。

  4. ［ システムの詳細］タブから、プロパティページを選択し、［付属エンタイトルメント］リストからコンテナビルドホストを有効にします。 プロパティの更新をクリックして確定します。

  5. highstateを適用して必要なすべてのパッケージをインストールします。 システムの詳細タブで、状態  highstateを選択し、highstateの適用をクリックします。 または、SUSE Multi-Linux Managerサーバのコマンドラインからhighstateを適用します。

    salt '$your_client' state.highstate

2.3. Create an activation key for containers

SUSE Multi-Linux Managerを使用して構築されたコンテナは、イメージを構築するときに、アクティベーションキーに関連付けられたチャンネルをリポジトリとして使用します。 このセクションでは、この目的のためにアドホックアクティベーションキーを作成する方法について説明します。

コンテナを構築するには、SUSE Manager Default以外のチャンネルに関連付けられているアクティベーションキーが必要です。
Procedure: Creating an activation key

  1. システム  アクティベーションキーを選択します。

  2. キーの作成をクリックします。

  3. ［説明］と［キー］名を入力します。 ドロップダウンメニューを使用してこのキーと関連付ける［ベースチャンネル］を選択します。

  4. アクティベーションキーの作成で確定します。

詳細については、アクティベーションキーを参照してください。

2.4. Create an image store

All built images are pushed to an image store. This section contains information about creating an image store. Image store is generally referenced as a registry.

Procedure: Creating image store

  1. イメージ  ストアを選択します。

  2. ［作成］をクリックして、新しいストアを作成します。

  3. From the Store Type select the correct type.

  4. ［ラベル］フィールドにイメージストアの名前を定義します。

  5. コンテナレジストリホスト(内部か外部)の完全修飾ドメイン名(FQDN)として、［URI］フィールドに入力して、イメージレジストリへのパスを指定します。

    registry.example.com

    レジストリURI を使用して、すでに使用されているレジストリのイメージストアを指定することもできます。

    registry.example.com:5000/myregistry/myproject

  6. 作成をクリックして、新しいイメージストアを追加します。

2.5. Create an image profile

すべてのコンテナイメージは、構築手順を含む、イメージプロファイルを使用して構築されます。 このセクションでは、SUSE Multi-Linux Manager Web UIでイメージプロファイルを作成する方法について説明します。

Procedure: Creating an image profile

  1. イメージプロファイルを作成するには、イメージ  プロファイルを選択し、作成をクリックします。

  2. ［ラベル］フィールドに入力して、イメージプロファイルの名前を指定します。

    コンテナイメージタグがmyproject/myimageなどの形式である場合は、イメージストアのレジストリURIに/myprojectサフィックスが含まれていることを確認します。

  3. ［イメージタイプ］として［Dockerfile］を使用します。

  4. ドロップダウンメニューを使用して、［ ターゲットのイメージストア］フィールドからレジストリを選択します。

  5. ［パス］フィールドに、GitHub、GitLab、またはBitBucketリポジトリのURLを入力します。 パスは構築ホスト上のローカルディレクトリにすることもできます。 URLはhttp、https、またはトークン認証URLである必要があります。 GitHubまたはGitLabの場合は、以下の形式のいずれかを使用します。

    GitHubパスオプション

    • GitHubシングルユーザプロジェクトリポジトリ

      https://github.com/USER/project.git#branchname:folder

    • GitHub組織プロジェクトリポジトリ

      https://github.com/ORG/project.git#branchname:folder

    • GitHubトークン認証

      gitリポジトリがプライベートな場合、認証を含むようにプロファイルのURLを変更します。 GitHubトークンで認証するには次のURL形式を使用します。

      https://USER:<AUTHENTICATION_TOKEN>@github.com/USER/project.git#master:/container/

    • GitLabシングルユーザプロジェクトリポジトリ

      https://gitlab.example.com/USER/project.git#master:/container/

    • GitLabグループプロジェクトリポジトリ

      https://gitlab.example.com/GROUP/project.git#master:/container/

    • GitLabトークン認証

      gitリポジトリがプライベートで、パブリックにアクセスできない場合は、認証を含むようにプロファイルのgit URLを変更する必要があります。 GitLabトークンで認証するには、次のURL形式を使用します。

      https://gitlab-ci-token:<AUTHENTICATION_TOKEN>@gitlab.example.com/USER/project.git#master:/container/

    gitブランチを指定しない場合は、デフォルトでmasterブランチが使用されます。 folderが指定されていない場合、イメージソース(Dockerfileソース)はGitHubまたはGitLabチェックアウトのルートディレクトリにあると想定されます。

  6. ［アクティベーションキー］を選択します。 アクティベーションキーは、プロファイルを使用するイメージが正しいチャンネルとパッケージに確実に割り当てられるようにします。

    アクティベーションキーをイメージプロファイルに関連付けると、プロファイルを使用するすべてのイメージで正しいソフトウェアチャンネルとチャンネル内のすべてのパッケージが確実に使用されるようになります。

  7. 作成ボタンをクリックします。

2.5.1. Example Dockerfile sources

再利用できるイメージプロファイルはhttps://github.com/SUSE/manager-build-profilesで公開されています。

ARGパラメータは、構築されたイメージがSUSE Multi-Linux Managerが提供する目的のリポジトリに関連付けられていることを確認します。 ARGパラメータを使用すると、構築ホスト自体で使用されるSUSE Linux Enterprise Serverのバージョンとは異なる可能性のあるSUSE Linux Enterprise Serverのイメージバージョンを構築することもできます。

例: リポジトリファイルを示すARG repoパラメータとechoコマンドは、目的のチャンネルバージョンの正しいパスを作成し、リポジトリファイルに挿入します。

リポジトリは、イメージプロファイルに割り当てたアクティベーションキーによって決定されます。

 
FROM registry.example.com/sles12sp2
MAINTAINER Tux Administrator "tux@example.com"

### Begin: These lines are required for use with {productname}

ARG repo
ARG cert

# Add the correct certificate
RUN echo "$cert" > /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT.pem

# Update certificate trust store
RUN update-ca-certificates

# Add the repository path to the image
RUN echo "$repo" > /etc/zypp/repos.d/susemanager:dockerbuild.repo

### End: These lines are required for use with {productname}

# Add the package script
ADD add_packages.sh /root/add_packages.sh

# Run the package script
RUN /root/add_packages.sh

# After building remove the repository path from image
RUN rm -f /etc/zypp/repos.d/susemanager:dockerbuild.repo

2.5.2. Using custom info key-value pairs as Docker buildargs

カスタム情報のキーと値のペアを割り当てて、イメージプロファイルに情報を添付できます。 さらに、これらのキーと値のペアは、Dockerビルドコマンドにbuildargsとして渡されます。

使用可能なカスタム情報キーと追加のキーの作成に関する詳細については、カスタムシステム情報を参照してください。

2.6. イメージの構築

There are two ways to build an image. The first way is to create it from scratch. To do that, select Images  Build from the left navigation bar, or click the build icon in the Images  Profiles list and follow the procedure.

プロシージャ: イメージの構築

  1. イメージ  ビルドを選択します。

  2. デフォルトのlatest(コンテナにのみ関連する)以外のバージョンを使用する場合は、別のタグ名を追加します。

  3. ［Build Profile］（ビルドプロファイル）と［構築ホスト］を選択します。

    ビルドフィールドの右側にある［プロファイル概要］に注目します。 ビルドプロファイルを選択すると、選択したプロファイルに関する詳細情報がこの領域に表示されます。

  4. ビルドをスケジュールするには、ビルドボタンをクリックします。

2.7. Import an image

The second way to get an image is to import and inspect arbitrary images. To do that, select Images  Image List from the left navigation bar. Complete the text boxes of the Import dialog. When it has processed, the imported image is listed on the Image List page.

Procedure: Importing an image

  1. イメージ  イメージリストから、取り込みをクリックして、［イメージの取り込み］ダイアログを開きます。

  2. ［イメージの取り込み］ダイアログで、次のフィールドに入力します。

    イメージストア

    検査のためにイメージがプルされるレジストリ。

    イメージ名

    レジストリのイメージの名前。

    イメージバージョン

    レジストリのイメージのバージョン。

    構築ホスト

    イメージをプルして検査する構築ホスト。

    アクティベーションキー

    イメージが検査されるソフトウェアチャンネルへのパスを提供するアクティベーションキー。

  3. 確定するには、取り込みをクリックします。

イメージのエントリがデータベースに作成され、SUSE Multi-Linux ManagerのInspect Image（イメージの検査）アクションがスケジュールされます。

処理が完了すると、取り込まれたイメージがイメージリストに表示されます。 イメージが取り込まれたことを示す異なるアイコンが［ビルド］列に表示されます。 取り込まれたイメージのステータスアイコンはイメージの［概要］タブにも表示されます。

2.8. トラブルシューティング

2.8.1. イメージの検査

ベースコンテナイメージ(BCI)には、それを実行するためのすべてのソフトウェアが付属していますが、BCIは軽量であるため、検査に必要なすべてのツールとライブラリが付属していない場合があります。

コンテナイメージを検査する際に、次のようなエラーメッセージが表示されることがあります。

libssl.so.1.1: cannot open shared object file: No such file or directory

BCIは、コンテナ構築ホストと検査にSalt Bundleを使用する以外のシナリオでも使用できますが、検査を実行する必要がある場合は、事前に必要なソフトウェアをすべて追加しておく必要があります。

このような問題を回避するには、libopensslをDockerfileを含むイメージに追加し、イメージを再構築する必要があります。

同じことがlibexpatでも起こる可能性があります。

2.8.2. General issues

イメージを操作する場合の既知の問題がいくつかあります。

  • レジストリまたはgitリポジトリにアクセスするためのHTTPS証明書はカスタム状態ファイルによってクライアントに配備する必要があります。

  • Dockerを使用したSSH gitアクセスは現在サポートされていません。

3. OS images

OSイメージは、Kiwiビルトシステムによって構築されます。 出力イメージはカスタマイズ可能で、PXE、QCOW2、LiveCD、またはその他のタイプのイメージにすることがきます。

Kiwiビルドシステムの詳細については、Kiwiのドキュメントを参照してください。

3.1. 要件

Kiwiイメージ構築機能は、SUSE Linux Enterprise Server 12およびSUSE Linux Enterprise Server 11を実行しているSaltクライアントで利用できます。

Kiwiイメージ設定ファイルおよび設定スクリプトは、以下の場所のいずれかからアクセスできる必要があります。

  • Gitリポジトリ

  • HTTPまたはHTTPSでホストされたtarアーカイブ

  • 構築ホスト上のローカルディレクトリ

gitで提供される完全なKiwiリポジトリの例については、https://github.com/SUSE/manager-build-profiles/tree/master/OSImageを参照してください。

Kiwiで構築されたOSイメージを実行しているホストには、少なくとも1GBのRAMが必要です。  ディスク容量は、イメージの実際のサイズによって異なります。 詳細については、基になるシステムのドキュメントを参照してください。

3.2. Create a build host

SUSE Multi-Linux Managerであらゆる種類のイメージを構築するには、構築ホストを作成して設定します。 OSイメージ構築ホストは、SUSE Linux Enterprise Server 15 (SP2以降)またはSUSE Linux Enterprise Server 12 (SP4以降)で実行されているSaltクライアントです。

このプロシージャでは、構築ホストの初期設定について説明します。

構築ホスト上のオペレーティングシステムは、ターゲットイメージ上のオペレーティングシステムと一致する必要があります。

たとえば、SUSE Linux Enterprise Server 15 (SP2以降)のOSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 15ベースのイメージを構築します。 SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 12ベースのイメージを構築します。

クロスアーキテクチャビルドはできません。 たとえば、SUSE Linux Enterprise Server 15 SP3を実行しているRaspberry PI (aarch64アーキテクチャ)構築ホストにRaspberry PI SUSE Linux Enterprise Server 15 SP3を構築する必要があります。
Procedure: Configure the build host in the SUSE Multi-Linux Manager Web UI

  1. システム  概要ページから構築ホストとして指定するクライアントを選択します。

  2. Navigate to the System Details  Properties tab, and check the Add-on System Type > OS Image Build Host box.

  3. Confirm with Update Properties.

  4. システムの詳細  ソフトウェア  ソフトウェアチャンネルに移動し、構築ホストのバージョンに応じて必要なソフトウェアのチャンネルを有効にします。

    • SUSE Linux Enterprise Server 12構築ホストでは、SUSE Multi-Linux Managerクライアントツール(SLE-Manager-Tools12-PoolとSLE-Manager-Tools12-Updates)が必要です。

    • SUSE Linux Enterprise Server 15構築ホストでは、SUSE Linux Enterprise ServerモジュールSLE-Module-DevTools15-SP4-PoolとSLE-Module-DevTools15-SP4-Updatesが必要です。

    • スケジュールを設定して確認をクリックします。

  5. highstateを適用してKiwiと必要なすべてのパッケージをインストールします。 システムの詳細ページで、状態  highstateを選択し、highstateの適用をクリックします。 または、SUSE Multi-Linux Managerサーバのコマンドラインからhighstateを適用します。

    salt '$your_client' state.highstate

3.2.1. SUSE Multi-Linux Manager web server public certificate RPM

構築ホストのプロビジョニングでは、SUSE Multi-Linux Manager証明書RPMを構築ホストにコピーします。 この証明書はSUSE Multi-Linux Managerによって提供されるリポジトリにアクセスするために使用されます。

証明書は、mgr-package-rpm-certificate-osimageパッケージスクリプトでRPMにパッケージ化されます。 パッケージスクリプトは新しいSUSE Multi-Linux Managerのインストール中に自動的に呼び出されます。

spacewalk-certs-toolsパッケージをアップグレードすると、アップグレードシナリオではデフォルト値を使用してパッケージスクリプトが呼び出されます。 ただし、証明書パスが変更された場合や使用できない場合は、アップグレードプロシージャの完了後に、--ca-cert-full-path <path_to_certificate>を使用してパッケージスクリプトを手動で呼び出します。

3.2.2. Package script call example

/usr/sbin/mgr-package-rpm-certificate-osimage --ca-cert-full-path /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT

証明書を含むRPMパッケージは、次のようなsalt-accessibleディレクトリに保存されます。

/usr/share/susemanager/salt/images/rhn-org-trusted-ssl-cert-osimage-1.0-1.noarch.rpm

証明書を含むRPMパッケージは、ローカル構築ホストリポジトリで提供されます。

/var/lib/Kiwi/repo

ビルドソースに SUSE Multi-Linux Manager SSL証明書を含むRPMパッケージを指定し、Kiwiの設定にbootstrapセクションの必須パッケージとしてrhn-org-trusted-ssl-cert-osimageが含まれていることを確認します。

Listing 1. config.xml
...
  <packages type="bootstrap">
    ...
    <package name="rhn-org-trusted-ssl-cert-osimage" bootinclude="true"/>
  </packages>
...

3.3. Create an activation key for OS images

イメージの構築時にOSイメージがリポジトリとして使用できるチャンネルに関連付けられたアクティベーションキーを作成します。

アクティベーションキーはOSイメージの構築に必須です。

To build OS Images, you need an activation key that is associated with a channel other than Default activation key.
Procedure: Creating an activation key

  1. Web UIで、システム  アクティベーションキーを選択します。

  2. ［キーの作成］をクリックします。

  3. ［説明］、［キー］の名前を入力し、ドロップダウンボックスを使用してキーに関連付ける［ベースチャンネル］を選択します。

  4. アクティベーションキーの作成で確定します。

詳細については、アクティベーションキーを参照してください。

3.4. Create an image store

OS Images can require a significant amount of storage space. By default, the image store is using the srv-www volume.

システム、仮想、およびその他のイメージの構築に使用されるKiwiビルドタイプのイメージストアは、まだサポートされていません。

The image files can be downloaded from https://MANAGER-HOST/os-images/ORGANIZATION-ID/FILE-NAME. The exact location can be determined from the image details page.

3.5. Create an image profile

Web UIを使用してイメージプロファイルを管理します。

Procedure: Creating an image profile

  1. イメージプロファイルを作成するには、イメージ  プロファイルから選択し、作成をクリックします。

  2. ［ラベル］フィールドに、イメージプロファイルの名前を入力します。

  3. ［イメージタイプ］として［Kiwi］を使用します。

  4. イメージストアは自動的に選択されます。

  5. Kiwi設定ファイルを含むディレクトリに［設定URL］を入力します。 たとえば、https://github.com/SUSE/manager-build-profiles#master:OSImage/SLE-Micro54などのgit URIです。 その他のオプションは、HTTPまたはHTTPSでホストされたtarアーカイブ、または構築ホスト上のローカルディレクトリです。 詳細については、このセクションの最後にあるソースフォーマットオプションを参照してください。

  6. 必要に応じて［Kiwiオプション］を入力します。 Kiwi設定ファイルで複数のプロファイルが指定されている場合、--profile <name>を使用してアクティブなプロファイルを選択します。 他のオプションについては、Kiwiのドキュメントを参照してください。

  7. ［アクティベーションキー］を選択します。 アクティベーションキーにより、プロファイルを使用したイメージが正しいチャンネルとパッケージに確実に割り当てられます。

    アクティベーションキーをイメージプロファイルに関連付け、イメージプロファイルで正しいソフトウェアチャンネルとパッケージが使用されるようにします。

  8. 作成ボタンで確定します。

ソースフォーマットオプション

  • リポジトリへのgit/HTTP(S) URL

    構築するイメージのソースを含むパブリックまたはプライベートgitリポジトリへのURL。 リポジトリのレイアウトによって、URLは次のようになります。

    https://github.com/SUSE/manager-build-profiles

    URLの#文字の後にブランチを指定できます。 この例では、masterブランチを使用します。

    https://github.com/SUSE/manager-build-profiles#master

    :文字の後のイメージソースを含むディレクトリを指定できます。 この例では、OSImage/POS_Image-JeOS6を使用します。

    https://github.com/SUSE/manager-build-profiles#master:OSImage/POS_Image-JeOS6

  • tarballアーカイブへのHTTP(S) URL

    WebサーバでホストされているtarアーカイブへのURL (圧縮または非圧縮)。

    https://myimagesourceserver.example.org/MyKiwiImage.tar.gz

  • 構築ホスト上のディレクトリへのパス

    Kiwiビルドシステムソースを含むディレクトリへのパスを入力します。 このディレクトリは選択した構築ホスト上に存在する必要があります。

    /var/lib/Kiwi/MyKiwiImage

3.5.1. Example of Kiwi sources

Kiwiソースは少なくとも config.xmlで構成されています 。 通常、config.shとimages.shも存在します。 ソースにはrootサブディレクトリの下の最終イメージにインストールするファイルも含めることができます。

Kiwiビルドシステムについては、Kiwiのドキュメントを参照してください。

SUSEでは、SUSE/manager-build-profilesパブリックGitHubリポジトリで、完全に機能するイメージソースの例を提供しています。

Listing 2. JeOS config.xmlの例
<?xml version="1.0" encoding="utf-8"?>

<image schemaversion="6.1" name="POS_Image_JeOS6">
    <description type="system">
        <author>Admin User</author>
        <contact>noemail@example.com</contact>
        <specification>SUSE Linux Enterprise 12 SP3 JeOS</specification>
    </description>
    <preferences>
        <version>6.0.0</version>
        <packagemanager>zypper</packagemanager>
        <bootsplash-theme>SLE</bootsplash-theme>
        <bootloader-theme>SLE</bootloader-theme>

        <locale>en_US</locale>
        <keytable>us.map.gz</keytable>
        <timezone>Europe/Berlin</timezone>
        <hwclock>utc</hwclock>

        <rpm-excludedocs>true</rpm-excludedocs>
        <type boot="saltboot/suse-SLES12" bootloader="grub2" checkprebuilt="true" compressed="false" filesystem="ext3" fsmountoptions="acl" fsnocheck="true" image="pxe" kernelcmdline="quiet"></type>
    </preferences>
    <!--    CUSTOM REPOSITORY
    <repository type="rpm-dir">
      <source path="this://repo"/>
    </repository>
    -->
    <packages type="image">
        <package name="patterns-sles-Minimal"/>
        <package name="aaa_base-extras"/> <!-- wouldn't be SUSE without that ;-) -->
        <package name="kernel-default"/>
        <package name="venv-salt-minion"/>
        ...
    </packages>
    <packages type="bootstrap">
        ...
        <package name="sles-release"/>
        <!-- this certificate package is required to access {productname} repositories
             and is provided by {productname} automatically -->
        <package name="rhn-org-trusted-ssl-cert-osimage" bootinclude="true"/>

    </packages>
    <packages type="delete">
        <package name="mtools"/>
        <package name="initviocons"/>
        ...
    </packages>
</image>

3.6. イメージの構築

There are two ways to build or get an image using the Web UI. Either select Images  Build, or click the build icon in the Images  Profiles list.

プロシージャ: イメージの構築

  1. イメージ  ビルドを選択します。

  2. デフォルトのlatest (コンテナのみに適用)以外のバージョンが必要な場合は別のタグ名を追加します。

  3. ［イメージプロファイル］および［構築ホスト］を選択します。

    ［プロファイル概要］がビルドフィールドの右側に表示されます。 ビルドプロファイルを選択したら、選択したプロファイルに関する詳細情報がここに表示されます。

  4. ビルドをスケジュールするには、ビルドボタンをクリックします。

ビルドサーバは、イメージ構築プロセス中にどのような形式のオートマウンタも実行できません。 必要に応じて、Gnomeセッションがrootとして実行されていないことを確認します。 オートマウンタが実行されている場合、イメージのビルドは正常に終了しますが、イメージのチェックサムが異なるためエラーが発生します。

イメージが正常に構築されると、検査フェーズが開始されます。 検査フェーズ中に、SUSE Multi-Linux Managerではイメージに関する情報を収集します。

  • イメージにインストールされているパッケージのリスト

  • イメージのチェックサム

  • イメージタイプと他のイメージの詳細

構築されたイメージタイプがPXEの場合は、Saltピラーも生成されます。 イメージのピラーはデータベースに保存され、Saltサブシステムは生成されたイメージに関する詳細にアクセスできます。 詳細には、イメージファイルの場所と提供場所、イメージのチェックサム、ネットワークブートに必要な情報などが含まれます。

生成されたピラーはすべての接続されているクライアントで使用できます。

3.7. トラブルシューティング

イメージを構築するには、いくつかの依存ステップが必要です。 ビルドが失敗した場合は、Salt状態の結果とビルドログを調査することで、失敗の原因を特定できます。 ビルドが失敗した場合は、次のチェックを実行できます。

  • 構築ホストがビルドソースにアクセスできる

  • 構築ホストとSUSE Multi-Linux Managerサーバの両方にイメージ用の十分なディスク容量がある

  • アクティベーションキーには正しいチャンネルが関連付けられている

  • 使用されるビルドソースが有効である

  • SUSE Multi-Linux Managerのパブリック証明書を含むRPMパッケージは最新で/usr/share/susemanager/salt/images/rhn-org-trusted-ssl-cert-osimage-1.0-1.noarch.rpmから入手できます。 パブリック証明書RPMを更新する方法の詳細については、Create a build hostを参照してください。

3.8. 制限事項

このセクションには、イメージを操作するときのいくつかの既知の問題が含まれています。

  • HTTPソースまたはgitリポジトリへのアクセスに使用されるHTTPS証明書は、カスタム状態ファイルによってクライアントに配備するか、手動で設定する必要があります。

  • Kiwiベースのイメージの取り込みはサポートされていません。

4. List of built images

使用できるビルドイメージを一覧にするには、イメージ  イメージリストを選択します。 すべてのイメージのリストが表示されます。

イメージに関する表示されたデータには、イメージの［名前］、その［バージョン］、［リビジョン］、およびビルドの［ステータス］が含まれます。 また、イメージに使用できる可能性のあるパッチやパッケージの更新のリストを使用してイメージの更新ステータスを確認することもできます。

OSイメージの場合、［名前］および［バージョン］フィールドはkiwiソースから作成され、ビルドが成功したときに更新されます。 ビルド中またはビルドが失敗した後は、これらのフィールドにはプロファイル名に基づく一時的な名前が表示されます。

［リビジョン］はビルドが成功するたびに自動的に増えます。OSイメージの場合、複数のリビジョンがストア内に共存できます。

コンテナイメージの場合、ストアには最新リビジョンのみが保持されます。 以前のリビジョン(パッケージ、パッチなど)に関する情報は保存され、［非推奨の表示］チェックボックスを使用して一覧にすることができます。

イメージの詳細ボタンをクリックすると、詳細ビューが表示されます。 詳細ビューには、関連するパッチの正確なリスト、イメージ内にインストールされたすべてのパッケージのリスト、およびビルドログが含まれます。

削除ボタンをクリックすると、リストからイメージが削除されます。 また、関連するピラー、OSイメージストアからのファイル、および非推奨のリビジョンも削除されます。

パッチおよびパッケージリストは、ビルド後の検査状態が正常だった場合にのみ使用できます。