イメージの構築と管理

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

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

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

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

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

イメージを構築します。

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

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

Kiwiビルドタイプ用のイメージストアは、`srv-www`ボリューム内のファイルシステムディレクトリとして事前定義されています。

イメージファイルは`https://MANAGER-HOST/os-images/ORGANIZATION-ID/FILE-NAME`からダウンロードできます。正確な場所は、イメージ詳細ページから確認できます。

2. コンテナイメージ

2.1. 要件

コンテナ機能は、SaltクライアントがSUSE Linux Enterprise Server 12以降を実行している場合に利用可能です。始める前に、環境がこれらの要件を満たしていることを確認してください:

Dockerfileおよび設定スクリプトを含む公開されたgitリポジトリ。リポジトリは公開または非公開であり、GitHub、GitLab、またはBitBucketにホストされる必要があります。
Dockerレジストリなどの適切に設定されたイメージストア。

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

2.2. 構築ホストの作成

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

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

例えば、SUSE Linux Enterprise Server 15に基づくイメージを、SUSE Linux Enterprise Server 15（SP2以降）OSバージョンを実行しているビルドホスト上で構築します。 SUSE Linux Enterprise Server 12を基にしたイメージを、SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行しているビルドホスト上で構築します。

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

SUSE Multi-Linux Manager Web UIから、次のステップを実行してビルドホストを設定します:

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

Saltクライアントを、システム システムの概要ページからビルドホストとして指定するために選択します。

選択したクライアントの`System Details`ページから、コンテナモジュールを割り当てます。 ソフトウェア ソフトウェアチャンネルに移動し、コンテナモジュール（例: SLE-Module-Containers15-Pool`および`SLE-Module-Containers15-Updates）を有効にします。次へで続行します。

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

`System Details`タブからプロパティページを選択し、`Add-on System Types`リストから`Container Build Host`を有効にします。 プロパティの更新をクリックして確認します。
`Highstate`を適用して、必要なすべてのパッケージをインストールします。システムの詳細タブから、状態 ハイステートを選択し、ハイステートを適用をクリックします。または、SUSE Multi-Linux Managerサーバーのコマンドラインから`Highstate`を適用します:
salt '$your_client' state.highstate

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

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

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

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

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

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

`Description`と`Key`の名前を入力します。ドロップダウンメニューを使用して、このキーに関連付ける`Base Channel`を選択します。

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

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

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

すべてのビルドされたイメージは、イメージストアにプッシュされます。このセクションでは、イメージストアの作成方法について説明します。イメージストアは一般的にレジストリとして参照されます。

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

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

`Create`をクリックして、新しいストアを作成します。

`Store Type`から正しいタイプを選択します。

`Label`フィールドにイメージストアの名前を入力します。
`URI`フィールドに、コンテナレジストリホスト（内部または外部）の完全修飾ドメイン名（FQDN）としてイメージレジストリへのパスを入力します。
registry.example.com
レジストリURI を使用して、すでに使用されているレジストリのイメージストアを指定することもできます。
registry.example.com:5000/myregistry/myproject
作成をクリックして、新しいイメージストアを追加します。

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

すべてのコンテナイメージは、ビルド指示を含むイメージプロファイルを使用してビルドされます。このセクションでは、SUSE Multi-Linux Manager Web UIを使用してイメージプロファイルを作成するための情報が含まれています。

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

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

`Label`フィールドにイメージプロファイルの名前を入力します。

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

`Dockerfile`を`Image Type`として使用します。

ドロップダウンメニューを使用して、`Target Image Store`フィールドからレジストリを選択します。
Path`フィールドに、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のチェックアウトのルートディレクトリにあることが期待されます。
`Activation Key`を選択してください。アクティベーションキーは、プロファイルを使用するイメージが正しいチャンネルとパッケージに割り当てられることを保証します。

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

Create ボタンをクリックします。

2.5.1. Dockerfileソースの例

再利用可能なイメージプロファイルは 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. カスタム情報のキーと値のペアをDocker `buildargs`として使用する

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

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

2.6. イメージの構築

イメージをビルドする方法は2つあります。最初の方法は、ゼロから作成することです。そのためには、左側のナビゲーションバーからImages Buildを選択するか、Images Profilesリストのビルドアイコンをクリックして手順に従ってください。

プロシージャ:イメージのビルド

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

デフォルトの`latest`（コンテナにのみ関連する）以外のバージョンが必要な場合は、別のタグ名を追加します。

`Build Profile`と`Build Host`を選択してください。

ビルドフィールドの右側にある`Profile Summary`に注目してください。ビルドプロファイルを選択すると、選択したプロファイルに関する詳細情報がこのエリアに表示されます。

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

2.7. イメージの取り込み

イメージを取得する2番目の方法は、任意のイメージをインポートして検査することです。そのためには、左側のナビゲーションバーからImages Image Listを選択します。 `Import`ダイアログのテキストボックスに入力します。処理が完了すると、インポートされたイメージが`Image List`ページに表示されます。

プロシージャ:イメージのインポート

Images Image listからImportをクリックして、`Import Image`ダイアログを開きます。

`Import Image`ダイアログで、以下のフィールドを入力します。

イメージストア

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

イメージ名

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

イメージバージョン

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

構築ホスト

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

アクティベーションキー

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

確認のために、Importをクリックします。

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

処理が完了すると、インポートされたイメージは`Image List`に表示されます。インポートされたイメージを示すために、`Build`列には異なるアイコンが表示されます。インポートされたイメージのステータスアイコンは、イメージの`Overview`タブでも確認できます。

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

2.8.1. イメージの検査

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

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

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

BCIは、コンテナビルドホストの利用や検査にSaltバンドルを使用する場合以外のシナリオでも利用できますが、検査を動作させる必要がある場合は、あらかじめ必要なソフトウェアをすべて追加しておく必要があります。

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

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

2.8.2. 一般的な問題

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

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

3. OSイメージ

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

Kiwiビルドシステムに関する詳細は、 Kiwi documentationを参照してください。

3.1. 要件

Kiwiイメージビルディング機能は、SaltクライアントがSUSE Linux Enterprise Server 15およびSUSE Linux Enterprise Server 12を実行している場合に利用可能です。

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

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

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

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

3.2. イメージをビルドする際にHTTP/HTTPSプロキシを介してGitリポジトリにアクセスする

ビルドホストがHTTP/HTTPSプロキシを介してのみアクセス可能なgitリポジトリからソースを取得する必要がある場合、Salt状態によって呼び出されるgitクライアントは、システム全体のプロキシ設定（例えば、`/etc/sysconfig/proxy`や環境変数）を常に取得しないため、ビルド中にgitタイムアウトが発生することがあります。

非対話型ビルドのためにgitがプロキシを使用するようにするには、http.proxyエントリを持つ`/etc/gitconfig`を作成します。

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

プロキシが認証を必要とする場合は、URLに資格情報を埋め込むのではなく、資格情報ヘルパーを使用するか、資格情報ストアを使用することをお勧めします。

3.2.1. Saltを使用して自動化する

ビルドホスト上での`/etc/gitconfig`の管理は、他の管理されたシステムと同様に構成管理を通じて行うことができます。 Salt状態ファイルを作成し、構成チャネルを介してビルドホストに割り当てた後、SUSE Multi-Linux Manager UIからハイステートを適用します。

システムカスタム情報フィールドからプロキシアドレスを取得したい場合は、`custom_info:`ピラープレフィックスを使用してください。

/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のメニュー:[システム>カスタムシステム情報]に移動し、必要なキーを作成します。

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

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

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

use_kiwi_ng: Kiwi 9の使用を強制します。
use_kiwi_container: コンテナ化されたKiwi 10の使用を強制します。これを有効にするには、値を`1`に設定します。
use_bundle_build: 追加のKIWIバンドルビルドアーティファクト（PXEファイルを含む`.install.tar`や`.raw.xz`など）をサーバーにアップロードします。これを有効にするには、値を`true`に設定します。

3.3.2. サーバ設定

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

SLES 15プロファイルに正しいバージョンが使用されるようにするには、`kiwi_image`カスタム情報キーを以下の値で定義する必要があります:

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

このキーが設定されていない場合、システムはデフォルトで最新バージョン(例: registry.suse.com/bci/kiwi:10.2)を使用します。これにより、SLES 15プロファイルのビルドで問題が発生する場合があります。

3.4. 構築ホストの作成

SUSE Multi-Linux Managerを使用してすべての種類のイメージをビルドするには、ビルドホストを作成して構成します。 OSイメージビルドホストは、SaltクライアントがSUSE Linux Enterprise Server 15 (SP2以降)またはSUSE Linux Enterprise Server 12 (SP4以降)で実行されています。

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

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

例えば、SUSE Linux Enterprise Server 15に基づくイメージを、SUSE Linux Enterprise Server 15 (SP2以降)のOSバージョンで実行されているビルドホスト上でビルドする必要があります。 SUSE Linux Enterprise Server 12を基にしたイメージを、SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行しているビルドホスト上で構築します。

クロスアーキテクチャビルドは不可能です。例えば、Raspberry PI SUSE Linux Enterprise Server 15 SP3イメージを、SUSE Linux Enterprise Server 15 SP3を実行しているRaspberry PI (aarch64アーキテクチャ)ビルドホスト上でビルドする必要があります。

プロシージャ:ビルドホストをSUSE Multi-Linux Manager Web UIで構成します。

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

システム詳細 プロパティタブに移動し、Add-on System Type > `OS Image Build Host`ボックスをオンにします。

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

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

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`が必要です。

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

3.4.1. SUSE Multi-Linux Managerウェブサーバのパブリック証明書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

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

Listing 1. config.xml

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

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

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

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

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

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

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

`Create Key`をクリックします。

`Description`と`Key`名を入力し、ドロップダウンボックスを使用してキーに関連付ける`Base Channel`を選択します。

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

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

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

OSイメージは、かなりのストレージスペースを必要とする場合があります。デフォルトでは、イメージストアは`srv-www`ボリュームを使用しています。

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

イメージファイルは`https://MANAGER-HOST/os-images/ORGANIZATION-ID/FILE-NAME`からダウンロードできます。正確な場所は、イメージ詳細ページから確認できます。

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

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

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

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

`Label`フィールドに、`Image Profile`の名前を入力します。

`Kiwi`を`Image Type`として使用します。

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

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

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

`Activation Key`を選択してください。アクティベーションキーは、プロファイルを使用するイメージが正しいチャンネルとパッケージに割り当てられることを保証します。

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

作成ボタンで確定します。
ソースフォーマットオプション
リポジトリへの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
tarアーカイブへの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="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.8. イメージの構築

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

プロシージャ:イメージのビルド

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

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

`Image Profile`と`Build Host`を選択します。

ビルドフィールドの右側に`Profile Summary`が表示されます。ビルドプロファイルを選択すると、選択したプロファイルに関する詳細情報がここに表示されます。

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

ビルドサーバーは、イメージビルドプロセス中に自動マウントのいかなる形式も実行できません。該当する場合は、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. ビルドイメージのリスト

利用可能なビルド済みイメージをリストするには、イメージ イメージリストを選択します。すべてのイメージのリストが表示されます。

イメージに関する表示データには、イメージ`Name`、その`Version`、Revision、およびビルド`Status`が含まれます。イメージの更新状況を確認することもでき、イメージに利用可能なパッチやパッケージの更新のリストが表示されます。

OSイメージの場合、`Name`および`Version`フィールドはKiwiソースから取得され、成功したビルドの最後に更新されます。ビルド中またはビルド失敗後、これらのフィールドはプロファイル名に基づく一時的な名前を表示します。

`Revision`は、各成功したビルドの後に自動的に増加します。OSイメージの場合、複数のリビジョンがストアに共存できます。

コンテナイメージの場合、ストアには最新のリビジョンのみが保持されます。以前のリビジョン（パッケージ、パッチなど）に関する情報は保持されており、`Show obsolete`チェックボックスを使用してリストすることができます。

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

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

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