Application Cluster Image Usage Guide
Sealos provides a repository called cluster-image on GitHub for building and publishing application images for Kubernetes clusters. These images can be created by submitting code to this repository and can be published to
docker.io/labring/ as official application images. It supports building Docker container images as well as cluster images for applications.
Types of Images
The repository supports three types of image builds:
- Application Cluster Images: These are primarily for building application images using GitHub Actions and support both amd64 and arm64 architectures.
- Configuration Cluster Images: These are mainly for building configuration images using GitHub Actions. They are not container images and are not architecture-specific. They typically contain configuration scripts or customizations to default configurations.
- Docker Images: These are mainly for building container images using GitHub Actions and support both amd64 and arm64 architectures.
Workflow for Image Builds
You can trigger image builds directly in the GitHub repository by creating an issue. Here are a few examples:
/imagebuild_dockerimages helm v3.8.2 Key1=Value1,Key2=Value2
/imagebuild_configs coredns v0.0.1
/imagebuild_apps helm v3.8.2
The format of the image build commands for each type is
/imagebuild_<type> <app_name> <version> [Key=Value,...], where
<type> can be
<version> represent the application name and version respectively, and
[Key=Value,...] is optional buildArg parameters used only for the
Location of Image Configurations
You can place your configuration files in the
applications/<app_name>/<version>/ directory, including Dockerfiles, Kubefiles, and init.sh scripts, among others. The init.sh script is typically used for downloading dependencies such as Helm and kubectl-minio. You can choose to use either a Dockerfile or Kubefile to define your image build logic.
Image Build Rules
The build rules vary slightly for each type of image. Generally, you need to create different subdirectories under the application directory and place different types of files in them, which Sealos will use to build the images. The specific rules are as follows:
chartsdirectory: Place the Helm charts required for the cluster images. Kubernetes will scan the charts and fetch the images for building, and the registry directory will be placed at the same level as the Kubefile.
manifestsdirectory: Place the Kubernetes yaml configurations directly. Kubernetes will scan all the images in the manifests directory and build the registry directory, which will be placed at the same level as the Kubefile.
images/shimdirectory: Store additional image lists and build the registry directory, which will be placed at the same level as the Kubefile.
- If templates are required, place files with the
manifests. These files can be rendered by the
sealos runcommand with environment variables and the
.tmplextension will be removed. For example, a file named
aa.yaml.tmplwill be rendered as
aa.yaml. Please ensure that the file names do not conflict with existing files.
registrydirectory must be placed at the same level as the Kubefile. Otherwise, it will not be copied to the private repository of master0. Also, ensure that the registry is not stored in a chart, as it may cause slow scanning by Helm and potentially lead to OOM (out-of-memory) issues during image builds.