SUSE Manager 3.2 › Advanced Topics › Image Building and Management

8 Image Building and Management

8.2.1 Requirements
8.2.2 Creating a Build Host
8.2.3 Creating an Image Store
8.2.4 Creating an Image Profile
8.2.5 Example Dockerfile and add_packages Script
8.2.6 Building an Image
8.2.7 Importing an Image
8.2.8 Troubleshooting

8.1 Image Building Overview #

SUSE Manager enables system administrators to build containers, system, and virtual images. SUSE Manager helps with creating Image Stores and managing Image Profiles.

8.2 Container Images #

8.2.1 Requirements #

The containers feature is available for Salt minions running SUSE Linux Enterprise Server 12 or later. The following requirements should be met before following this guide:

You will need an existing external Github or internal Gitlab Repository containing a Dockerfile and configuration scripts (Example scripts are provided in the following sections)
Portus or another image registry properly configured.
Note: Registry Provider Solutions
If you require a private image registry you can use an open source solution such as Portus. For additional information on setting up Portus as a registry provider, see the: ** Portus Documentation

For more information on Containers or CaaS Platform review the following links:

8.2.2 Creating a Build Host #

To build all kind of images with SUSE Manager, you will need to create and configure a build host. Build hosts are Salt minions running SLES 12 or later. The following steps will guide you though the initial configuration for a build host.

From the SUSE Manager{webui} perform the following steps to configure a build host.

Select a minion that will be designated as a build host from the Systems › Overview page.
From the System Details page for the selected minion assign the containers modules by going to Software › Software Channels and enable SLE-Module-Containers12-Pool and SLE-Module-Containers12-Updates. Confirm by clicking Change Subscriptions.
From the System Details › Properties page, enable the Add-on System Type Container Build Host and confirm by selecting Update Properties.
Install all required packages by applying the Highstate. From the system’s details page select States › Highstate and select Apply Highstate. Alternatively apply a Highstate from the command line by executing state.highstate from command line of the SUSE Manager server.

8.2.2.1 Define Container Build Channels with an Activation Key #

Create an activation key associated with the channel that your images will use.

From the left navigation menu select Systems › Activation Keys.
Click Create Key.
Enter a Description] , a [guimenu]Key name. Use the drop-down menu to select the [guimenu]Base Channel`` that should be associated with this key. Confirm with Create Activation Key.

For more information, see Chapter 7, Activation Key Management.

8.2.3 Creating an Image Store #

Define a location to store all of your images by creating an Image Store.

From the left navigation menu select Images › Stores.
Click Create to create a new store.

SUSE Manager currently provides support only for the `Registry`Store 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. The FQDN of the container registry host (whether internal or external) is sufficient.
```
registry.example.com
```
Registry URI is also used to specify image store on used registry.
```
registry.example.com:5000/myregistry/myproject
```
Click Create to add the new Image Store.

8.2.4 Creating an Image Profile #

Manage Image Profiles from the Image Profile page.

Procedure: Create an Image Profile #

To create an image profile select Image › Profiles and click Create.

Provide a name for the Image Profile by filling in the Label field.
Note
Only lower case alphanumeric characters are permitted as container label. In case your container image tag is a format such as myproject/myimage, make sure your Image store registry URI contains the /myproject suffix.
Use a Dockerfile as the Image Type
Use the drop-down menu to select your registry from the Target Image Store field in case of Dockerfile image type.
Enter a Github or Gitlab repository URL (http/https/token authentication) in the Path field using one of the following formats:

Github Path Options #

Github Single User Project Repository:

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

Github Organization Project Repository:

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

Github Token Authentication
If your GIT repository is private and not publicly accessible, you need to modify the profile’s GIT URL to include some authentication. Use the following URL format to authenticate with a Github token.
```
https://USER:<AUTHENTICATION_TOKEN>@github.com/USER/project.git#master:/container/
```

Gitlab Path Options #

Gitlab Single User Project Repository

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

Gitlab Groups Project Repository

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

Gitlab Token Authentication
If your GIT repository is private and not publicly accessible, you need to modify the profile’s GIT URL to include some authentication. Use the following URL format to authenticate with a Gitlab token.
```
https://gitlab-ci-token:<AUTHENTICATION_TOKEN>@gitlab.example.com/USER/project.git#master:/container/
```
Important: Specifying a Github or Gitlab Branch
If a branch is not specified the master branch will be used by default. If a folder is not specified the image sources (Dockerfile sources) are expected to be in the root directory of the Github or Gitlab checkout.
1. Select an Activation Key (Activation Keys ensure images using a profile are assigned to the correct channel and packages).
  Note: Relationship Between Activation Keys and Image Profiles
  When you associate an activation key with an image profile you are ensuring any image using the profile will use the correct software channel and any packages in the channel.
2. Click the Create button.

8.2.5 Example Dockerfile and add_packages Script #

The following is an example Dockerfile. You specify a Dockerfile that will be used during image building when creating an image profile. A Dockerfile and any associated scripts should be stored within an internal or external Github/Gitlab repository:

Important: Required Dockerfile Lines

The following basic Dockerfile lines provide access to a specific repository version served by SUSE manager. The following example Dockerfile is used by SUSE Manager to trigger a build job on a build host minion. These ARGS ensure that the image built is associated with the desired repo version served by SUSE Manager. These ARGs also allow you to build image versions of SLES which may differ from the version of SLES used by the build host itself.

For example: The ARG repo and echo to the repository file creates and then injects the correct path into the repo file for the desired channel version . The repository version is determined by the activation key that you assigned to your Image Profile.

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

### Begin: These lines Required for use with SUSE Manager

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 required for use with SUSE Manager

# 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

The following is an example add_packages.sh script for use with your Dockerfile:

#!/bin/bash
set -e

zypper --non-interactive --gpg-auto-import-keys ref

zypper --non-interactive in python python-xml aaa_base aaa_base-extras net-tools timezone vim less sudo tar

Note: Packages Required for Inspecting Your Images

To inspect images and provide the package and product list of a container to the SUSE Manager{webui} you are required to install python and python-xml within the container. If these packages remain uninstalled, your images will still build, but the package and product list will be unavailable from the Web UI.

8.2.6 Building an Image #

There are two ways to build an image. You can select Images › Build from the left navigation bar, or click the build icon in the Images › Profiles list.

Procedure: Build an Image #

For this example select Images › Build.
Add a different tag name if you want a version other than the default latest (Only relevant to Containers).
Select the Build Profile and a Build Host
Note: Profile Summary
Notice the Profile Summary to the right of the build fields. When you have selected a build profile detailed information about the selected profile will show up in this area.
To schedule a build click the Build button.

8.2.7 Importing an Image #

You can import and inspect arbitrary images. Select Images › Images from the left navigation bar. Fill the text boxes of the Import dialog. When processed the imported image will get listed on the Images page.

Procedure: Import an Image #

From Images › Images click the Import to open the Import Image dialog.
In the Import dialog fill the following fields:
Image store
The registry from where the image will be pulled for inspection.
Image name
The name of the image in the registry.
Image version
The version of the image in the registry.
Build host
The build host that will pull and inspect the image.
Activation key
The activation key provides the path to the software channel that the image will be inspected with.
For confirmation, click Import .

At this point, the entry for the image is created in the database and an Inspect Image action on SUSE Manager is scheduled right away.

When processed find the imported image in the images list. You can recognize it because of a different icon in the Build column, which means that the image is imported (see screenshot below). The status icon for the imported image can also be seen on the overview tab for the image.

8.2.8 Troubleshooting #

The following are some known pitfalls when working with images.

HTTPS certificates to access the registry or the git repositories should be deployed to the minion by a custom state file.
SSH git access with docker is currently unsupported. You may test it, but SUSE will not provide support.
If the python and python-xml packages are not installed within your images during the build process, Salt cannot run within the container and reporting of installed packages or products will fail. This will result in an unknown update status.

Print this page

Advanced Topics

8 Image Building and Management

8.1 Image Building Overview #

8.2 Container Images #

8.2.1 Requirements #

Note: Registry Provider Solutions

8.2.2 Creating a Build Host #

8.2.2.1 Define Container Build Channels with an Activation Key #

8.2.3 Creating an Image Store #

8.2.4 Creating an Image Profile #

Procedure: Create an Image Profile #

Note

Github Path Options #

Gitlab Path Options #

Important: Specifying a Github or Gitlab Branch

Note: Relationship Between Activation Keys and Image Profiles

8.2.5 Example Dockerfile and add_packages Script #

Important: Required Dockerfile Lines

Note: Packages Required for Inspecting Your Images

8.2.6 Building an Image #

Procedure: Build an Image #

Note: Profile Summary

8.2.7 Importing an Image #

Procedure: Import an Image #

8.2.8 Troubleshooting #