이미지 빌드 및 관리

1. 이미지 빌드 개요

SUSE Multi-Linux Manager을(를) 사용하면 시스템 관리자가 컨테이너와 OS 이미지를 빌드하고 결과를 이미지 저장소에 푸시할 수 있습니다.

절차: 이미지 빌드 및 푸시

이미지 저장소를 정의합니다.

이미지 프로파일을 정의하고 이를 소스(git 리포지토리 또는 디렉토리)와 연결합니다.

이미지를 빌드합니다.

이미지를 이미지 저장소로 푸시합니다.

SUSE Multi-Linux Manager은(는) 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 SP4 또는 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 관리자 기본값 이외의 채널과 연결된 활성화 키가 필요합니다.

절차: 활성화 키 생성

시스템 활성화 키를 선택합니다.

키 생성을 클릭합니다.

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을 수정합니다. 다음 URL 형식을 사용하여 GitHub 토큰으로 인증합니다.
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을 수정해야 합니다. 다음 URL 형식을 사용하여 GitLab 토큰으로 인증:
https://gitlab-ci-token:<AUTHENTICATION_TOKEN>@gitlab.example.com/USER/project.git#master:/container/
git 분기를 지정하지 않으면 기본적으로 마스터 분기가 사용됩니다. 폴더가 지정되지 않은 경우 이미지 소스(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"

### 시작: 이러한 라인은 {productname}과(와) 함께 사용하기 위해 필요합니다.

ARG repo
ARG cert

# 올바른 인증서 추가
RUN echo "$cert" > /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT.pem

# 인증서 신뢰 저장소 업데이트
RUN update-ca-certificates

# 이미지에 리포지토리 경로 추가
RUN echo "$repo" > /etc/zypp/repos.d/susemanager:dockerbuild.repo

### 끝: 이러한 라인은 {productname}과(와) 함께 사용하기 위해 필요합니다.

# 패키지 스크립트 추가
ADD add_packages.sh /root/add_packages.sh

# 패키지 스크립트 실행
RUN /root/add_packages.sh

# 빌드 후 이미지에서 리포지토리 경로 제거
RUN rm -f /etc/zypp/repos.d/susemanager:dockerbuild.repo

2.5.2. 사용자 정의 정보 키-값 쌍을 Docker `buildargs`로 사용

사용자 정의 정보 키-값 쌍을 할당하여 이미지 프로파일에 정보를 첨부할 수 있습니다. 또한, 이러한 키-값 쌍은 buildargs로 Docker 빌드 명령에 전달됩니다.

사용 가능한 사용자 정보 키 및 추가 키 생성에 대한 자세한 내용은 사용자 정의 시스템 정보에서 확인할 수 있습니다.

2.6. 이미지 빌드

이미지를 구축하는 방법은 두 가지입니다. 첫 번째 방법은 처음부터 새로 만드는 것입니다. 왼쪽 탐색 모음에서 이미지 만들기를 선택하거나 이미지 프로파일 목록에서 만들기 아이콘을 클릭한 다음 절차를 따릅니다.

절차: 이미지 빌드

이미지 빌드를 선택합니다.

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:공유 객체 파일을 열 수 없음: 해당 파일 또는 디렉토리 없음

컨테이너 빌드 호스트와 Salt 번들을 검사에 사용하는 경우 뿐만 아니라 다른 상황에서도 BCI를 사용할 수 있지만, 검사를 작동시키기 위해서는 모든 필수 소프트웨어를 미리 추가해야 합니다.

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 이미지를 실행하는 호스트에는 사용할 수 있는 1 GB 이상 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. Container-based Kiwi image build support

SUSE Multi-Linux Manager introduces a container-based Kiwi image build system, in addition to the existing legacy Kiwi and KiwiNG tools.

3.3.1. Configuration and overrides

Administrators can override the default behavior using the following pillar or custom values. To configure these, navigate to menu:[Systems>Custom System Info] in the Web UI and create the necessary keys.

The build system used depends on the underlying OS or specific pillar values:

for SLE 11 / SLE 12: legacy Kiwi v7
for SLE 15: KiwiNG (v9 and containerized Kiwi 10)

Administrators can override the default behavior using the following pillar or custom values:

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. Version-specific configurations

When using a containerized build host for SUSE Linux Enterprise 15 profiles, specific configurations are required because SLES 15 profiles rely on Kiwi 9, while the default container behavior uses 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 웹 서버 공인 인증서 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가 액세스할 수 있는 디렉토리에 저장됩니다.

/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
tar 아카이브에 대한 HTTP(S) URL

웹 서버에서 호스팅되는 tar 아카이브(압축 또는 비압축)의 URL입니다.
https://myimagesourceserver.example.org/MyKiwiImage.tar.gz
빌드 호스트 상의 디렉토리 경로

Kiwi 빌드 시스템 소스가 포함된 디렉토리 경로를 입력합니다. 이 디렉토리는 선택한 빌드 호스트에 위치해야 합니다.
/var/lib/Kiwi/MyKiwiImage

3.7.1. Kiwi 소스의 예제

Kiwi 소스는 최소한 config.xml로 구성됩니다. 일반적으로 config.sh와 image.sh도 함께 포함됩니다. 소스에는 root 하위 디렉토리의 최종 이미지에 설치할 파일도 포함될 수도 있습니다.

Kiwi 빌드 시스템에 대한 내용은 Kiwi documentation에서 확인할 수 있습니다.

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가지가 있습니다. 이미지 빌드를 선택하거나 이미지 프로파일 목록에서 빌드 아이콘을 클릭합니다.

절차: 이미지 빌드

이미지 빌드를 선택합니다.

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 세션이 없는지 확인하십시오. 자동 마운터가 실행 중인 경우 이미지 빌드가 완료되지만, 이미지의 체크섬이 달라 실패하게 됩니다.

이미지 빌드가 성공하면 검사 단계가 시작됩니다. 검사 단계에서 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 이미지 저장소의 파일 및 사용되지 않는 리비전도 삭제됩니다.

빌드가 성공한 후 상태를 검사한 경우에만 패치 및 패키지 목록을 사용할 수 있습니다.