An openSUSE x86-64-based Docker image containing the kiwi-ng tool for image building. This is part of the CMS Image Management and Image Customization toolset for Shasta-based systems.
This container is part of the IMS workflow used to create new images from a kiwi recipe description. Upon successful building of a recipe, the follow on containers are expected to package and upload build artifacts to ARS.
Upon failure to build a recipe, this container sets a flag used by the follow on containers to know that the build failed.
PARAMETER_FILE_BUILD_FAILED=$IMAGE_ROOT_PARENT/build_failed
In the case of a failure, follow on containers have the option of enabling a SSH shell where the administrator can access the failed image root in order to determine the nature of the failure and how to resolve.
Kiwi-ng must be run as root in order to build and chroot into the image root being built. There are Kiwi plugins that allow Kiwi-ng to not require root access, however these plugins also require virtualization, which is not available within a docker container.
There is future work that will hopefully mitigate any concern regarding this container running as root. However, until this work is completed, the container will need to run as root.
To build and use the ims-kiwi-ng-opensuse-x86_64-builder Docker image, you will need Docker installed on your system, and a viable Kiwi image recipe. See the Kiwi Docs to learn more about creating image recipes.
Just clone this repo and cd into it. Bang! You're done.
docker build -t ims-kiwi-ng-opensuse-x86_64-builder:dev .
- Make a directory for your Kiwi image recipe and populate it:
# mkdir -p /path/to/recipe
# cp -r /my/recipe/* /path/to/recipe
- Make a directory to hold the build root generated by Kiwi
# mkdir -p /path/to/build-root
- Run the container to build the image root using the directories you created above as volumes. This step will take a while and depending on the image recipe will consume considerable memory and disk space.
# docker run --privileged=true --rm -v /path/to/recipe:/mnt/image/recipe -v /path/to/build-root:/mnt/image ims-kiwi-ng-opensuse-x86_64-builder:dev
[ INFO ]: 22:02:20 | Loading XML description
[ INFO ]: 22:02:20 | --> loaded /mnt/image/recipe/config.xml
[ INFO ]: 22:02:20 | --> Selected build type: oem
[ INFO ]: 22:02:20 | Preparing new root system
[ INFO ]: 22:02:20 | Setup root directory: /mnt/build-root/build/image-root
[ INFO ]: 22:02:21 | Setting up repository obs://Virtualization:Appliances:Builder/SLE_12_SP3
...
[ INFO ]: 22:25:07 | Result files:
[ INFO ]: 22:25:07 | --> disk_image: /mnt/build-root/my-image.x86_64-1.0.0.raw
[ INFO ]: 22:25:07 | --> image_packages: /mnt/build-root/my-image.x86_64-1.0.0.packages
[ INFO ]: 22:25:07 | --> image_verified: /mnt/build-root/my-image.x86_64-1.0.0.verified
The resulting image (raw format) will be in /path/to/build-root/ on your host
system. The image root will be in path/to/build-root/build/image-root/.
This Docker image will be deployed as part of the Shasta management plane stack via Kubernetes, specifically as a part of the Image Management Service.
Development on this repository should follow the standard CMS development process.
This repo uses some build helpers from the cms-meta-tools repo. See that repo for more details.
If you wish to perform a local build, you will first need to clone or copy the contents of the
cms-meta-tools repo to ./cms_meta_tools in the same directory as the Makefile. When building
on github, the cloneCMSMetaTools() function clones the cms-meta-tools repo into that directory.
For a local build, you will also need to manually write the .version, .docker_version (if this repo builds a docker image), and .chart_version (if this repo builds a helm chart) files. When building on github, this is done by the setVersionFiles() function.
- Eric Cozzi
- Randy Kleinman
- Add your name here if you want praise or blame later
This project is copyrighted by Hewlett Packard Enterprise Development LP and is under the MIT license. See the LICENSE file for details.
When making any modifications to a file that has a Cray/HPE copyright header, that header must be updated to include the current year.
When creating any new files in this repo, if they contain source code, they must have the HPE copyright and license text in their header, unless the file is covered under someone else's copyright/license (in which case that should be in the header). For this purpose, source code files include Dockerfiles, Ansible files, RPM spec files, and shell scripts. It does not include Jenkinsfiles, OpenAPI/Swagger specs, or READMEs.
When in doubt, provided the file is not covered under someone else's copyright or license, then it does not hurt to add ours to the header.