イメージの構築と管理

1. イメージの構築の概要

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

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

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

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

イメージを構築します。

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

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. コンテナイメージ

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. 構築ホストの作成

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から、次のステップを実行して、構築ホストを設定します。

プロシージャ: ホストの構築

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

From the System Details page of the selected client assign the containers modules. Navigate to Software Software Channels and enable the containers module (for example, SLE-Module-Containers15-Pool and SLE-Module-Containers15-Updates). Continue with Next.

Schedule the ` Software Channel Change`, and click Confirm.

From the System Details tab select Properties page, and enable Container Build Host from the Add-on System Types list. Confirm by clicking Update Properties.
Install all required packages by applying Highstate. From the system details tab select States Highstate, and click Apply Highstate. Alternatively, apply Highstate from the SUSE Multi-Linux Manager Server command line:
salt '$your_client' state.highstate

2.3. コンテナ用アクティベーションキーの作成

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

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

プロシージャ: アクティベーションキーの作成

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

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

Enter a Description and a Key name. Use the drop-down menu to select the Base Channel to associate with this key.

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

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

2.4. イメージストアの作成

すべての構築されたイメージは、イメージストアにプッシュされます。このセクションでは、イメージストアの作成について説明します。イメージストアは一般的にレジストリと呼ばれます。

プロシージャ: イメージストアの作成

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

Click Create to create a new store.

From the Store Type select the correct type.

Define a name for the image store in the Label field.
Provide the path to your image registry by filling in the URI field, as a fully qualified domain name (FQDN) for the container registry host (whether internal or external).
registry.example.com
レジストリURI を使用して、すでに使用されているレジストリのイメージストアを指定することもできます。
registry.example.com:5000/myregistry/myproject
作成をクリックして、新しいイメージストアを追加します。

2.5. イメージプロファイルの作成

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

プロシージャ: イメージプロファイルの作成

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

Provide a name for the image profile by filling in the Label field.

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

Use Dockerfile as the Image Type.

Use the drop-down menu to select your registry from the Target Image Store field.
In the Path field, type a GitHub, GitLab, or BitBucket repository URL. The path can also be a local directory on the build host. The URL should be http, https, or a token authentication URL. For GitHub or GitLab, use one of these formats:
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チェックアウトのルートディレクトリにあると想定されます。
［アクティベーションキー］を選択します。アクティベーションキーは、プロファイルを使用するイメージが正しいチャンネルとパッケージに確実に割り当てられるようにします。

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

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

2.5.1. Dockerfileソースの例

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

The ARG parameters ensure that the built image is associated with the desired repository served by SUSE Multi-Linux Manager. The ARG parameters also allow you to build image versions of SUSE Linux Enterprise Server which may differ from the version of SUSE Linux Enterprise Server used by the build host itself.

For example: The ARG repo parameter and the echo command pointing to the repository file, creates and then injects the correct path into the repository file for the desired channel version.

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

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. カスタム情報のキーと値のペアをDocker `buildargs`として使用する

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

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

2.6. イメージの構築

イメージを構築するには、2つの方法があります。 1つ目は、最初から作成する方法です。これを行うには、左側のナビゲーションバーからイメージ ビルドを選択するか、イメージ プロファイルリストのビルドアイコンをクリックして、プロシージャに従います。

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

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

Add a different tag name if you want a version other than the default latest (only relevant to containers).

Select Build Profile and Build Host.

Notice the Profile Summary to the right of the build fields. When you have selected a build profile, detailed information about the selected profile is displayed in this area.

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

2.7. イメージの取り込み

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.

プロシージャ: イメージの取り込み

From Images Image list click Import to open the Import Image dialog.

In the Import Image dialog complete these fields:

イメージストア

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

イメージ名

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

イメージバージョン

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

構築ホスト

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

アクティベーションキー

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

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

The entry for the image is created in the database, and an Inspect Image action on SUSE Multi-Linux Manager is scheduled.

When it has been processed, you can find the imported image in the Image List. It has a different icon in the Build column, to indicate that the image is imported. The status icon for the imported image can also be seen on the Overview tab for the 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を使用する以外のシナリオでも使用できますが、検査を実行する必要がある場合は、事前に必要なソフトウェアをすべて追加しておく必要があります。

To avoid such issues you must add libopenssl to the image with Dockerfile and rebuild the image.

The same can happen with libexpat.

2.8.2. 一般的な問題

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

レジストリまたはgitリポジトリにアクセスするためのHTTPS証明書はカスタム状態ファイルによってクライアントに配備する必要があります。
Dockerを使用したSSH gitアクセスは現在サポートされていません。

3. OSイメージ

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

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

3.1. 要件

The Kiwi image building feature is available for Salt clients running SUSE Linux Enterprise Server 15 and SUSE Linux Enterprise Server 12.

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

Gitリポジトリ
HTTPまたはHTTPSでホストされたtarアーカイブ
構築ホスト上のローカルディレクトリ

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

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

3.2. Accessing Git repositories via an HTTP/HTTPS proxy when building images

When a build host needs to fetch sources from a git repository that is only reachable through an HTTP/HTTPS proxy, you may see git timeouts during the build because the git client invoked by the Salt state does not always pick up system-wide proxy settings (for example /etc/sysconfig/proxy or environment variables).

To make git use the proxy for non-interactive builds create /etc/gitconfig with an http.proxy entry:

# /etc/gitconfig
[http]
    proxy = http://proxy.example.com:3128
# or for HTTPS
[http]
    proxy = https://proxy.example.com:3128

If the proxy requires authentication, prefer a credential helper or use a credential store instead of embedding credentials in the URL.

3.2.1. Automating with Salt

You can manage /etc/gitconfig on build hosts through Configuration Management, the same way as on any other managed system. Create a Salt state file and assign it to the build host via a config channel, then apply a highstate from the SUSE Multi-Linux Manager UI.

If you want to source the proxy address from a System Custom Info field, use the custom_info: pillar prefix:

/etc/gitconfig:
  file.managed:
    - user: root
    - group: root
    - mode: '0644'
    - contents: |
        [http]
            proxy = {{ salt['pillar.get']('custom_info:build_server:git_proxy', 'http://proxy.example.com:3128') }}

3.3. コンテナベースのKiwiイメージビルドサポート

SUSE Multi-Linux Managerは、既存のレガシKiwiおよびKiwiNGツールに加えて、コンテナベースのKiwiイメージビルドシステムを導入しました。

3.3.1. 設定と上書き

管理者は以下のpillar値またはカスタム値を使用してデフォルト動作を上書きできます。これらの値を設定するには、Web UI で menu:[システム>カスタムシステム情報]に移動し、必要なキーを作成します。

使用されるビルドシステムは基盤となるOSまたは特定のpillar値によって異なります。

SLE 11 / SLE 12の場合: レガシKiwi v7
SLE 15の場合: KiwiNG (v9およびコンテナ化されたKiwi 10)

管理者は以下のpillar値またはカスタム値を使用して、デフォルト動作を上書きできます。

use_kiwi_ng: force the use of Kiwi 9,
use_kiwi_container: force the use of containerized Kiwi 10. To enable this, set the value to 1.
use_bundle_build: upload additional KIWI bundle build artifacts (like .install.tar which contains PXE files, and .raw.xz) to the server. To enable this, set the value to true.

3.3.2. バージョン固有の設定

SUSE Linux Enterprise 15プロファイル用のコンテナ化されたビルドホストを使用する場合、SLES 15プロファイルはKiwi 9に依存しているのに対し、デフォルトコンテナ動作はKiwi 10を使用するため、固有の設定が必要です。

To ensure the correct version is used for SLES 15 profiles, you must define the kiwi_image custom info key with the following value:

Key: kiwi_image
Value: registry.suse.com/bci/kiwi:9

If this key is not set, the system defaults to the latest version (e.g., registry.suse.com/bci/kiwi:10.2), which may result in build issues for SLES 15 profiles.

3.4. 構築ホストの作成

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

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

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

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

プロシージャ: SUSE Multi-Linux Manager Web UIでの構築ホストの設定

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

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

プロパティの更新で確定します。

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

SUSE Linux Enterprise Server 12 build hosts require SUSE Multi-Linux Manager Client tools (SLE-Manager-Tools12-Pool and SLE-Manager-Tools12-Updates).

SUSE Linux Enterprise Server 15 build hosts require SUSE Linux Enterprise Server modules SLE-Module-DevTools15-SP4-Pool and SLE-Module-DevTools15-SP4-Updates.

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

3.4.1. SUSE Multi-Linux Manager Webサーバのパブリック証明書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.4.2. パッケージスクリプトの呼び出し例

/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

Specify the RPM package with the SUSE Multi-Linux Manager SSL certificate in the build source, and make sure your Kiwi configuration contains rhn-org-trusted-ssl-cert-osimage as a required package in the bootstrap section.

Listing 1. config.xml

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

3.5. OSイメージ用アクティベーションキーの作成

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

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

OSイメージを構築するには、デフォルトアクティベーションキー以外のチャンネルに関連付けられたアクティベーションキーが必要です。

プロシージャ: アクティベーションキーの作成

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

Click Create Key.

Enter a Description, a Key name, and use the drop-down box to select a Base Channel to associate with the key.

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

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

3.6. イメージストアの作成

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.7. イメージプロファイルの作成

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

プロシージャ: イメージプロファイルの作成

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

In the Label field, provide a name for the Image Profile.

Use Kiwi as the Image Type.

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

Enter a Config URL to the directory containing the Kiwi configuration files. For example, a git URI such as https://github.com/SUSE/manager-build-profiles#master:OSImage/SLE-Micro54. Other options are a HTTP or HTTPS hosted tar archive or a local directory on the build host. For more information, see source format options at the end of this section.

Enter Kiwi options if needed. If the Kiwi configuration files specify multiple profiles, use --profile <name> to select the active one. For other options, see Kiwi documentation.

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

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

作成ボタンで確定します。
ソースフォーマットオプション
リポジトリへの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.7.1. Kiwiソースの例

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="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.8. イメージの構築

Web UIを使用してイメージを構築または取得する2つの方法があります。 イメージ ビルドを選択するか、イメージ プロファイルリストのビルドアイコンをクリックします。

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

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

Add a different tag name if you want a version other than the default latest (applies only to containers).

Select the Image Profile and a Build Host.

A Profile Summary is displayed to the right of the build fields. When you have selected a build profile, detailed information about the selected profile is shown here.

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

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

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

イメージにインストールされているパッケージのリスト
イメージのチェックサム
イメージタイプと他のイメージの詳細

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

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

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

イメージを構築するには、いくつかの依存ステップが必要です。ビルドが失敗した場合は、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を更新する方法の詳細については、構築ホストの作成を参照してください。

3.10. 制限事項

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

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

4. ビルドイメージのリスト

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

Displayed data about images includes an image Name, its Version, Revision, and the build Status. You can also see the image update status with a listing of possible patch and package updates that are available for the image.

For OS Images, the Name and Version fields originate from Kiwi sources and are updated at the end of successful build. During building or after failed build these fields show a temporary name based on profile name.

Revision is automatically increased after each successful build. For OS Images, multiple revisions can co-exist in the store.

For Container Images the store holds only the latest revision. Information about previous revisions (packages, patches, etc.) are preserved and it is possible to list them with the Show obsolete checkbox.

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

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

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