Sealer Application definition

[justadogistaken]

Design

Overview

Implementation

KubefileParser

kubefileParser has the three major attributions appRootPathFunc, appConfigRootPathFunc, imageEngine. appRootPathFunc and appConfigRootPathFunc will return the path relative to the sealer rootfs. Currently they will be $ROOTFS/application/apps/[helm|kube]/$appname/ and $ROOTFS/application/configs/[helm|kube]/$appname/ respectively.

As for imageEngine, we need this to pull the FROM image(name it fromImage). Because there are some definitions of application stored in the fromImage, we need to merge the definitions of application from fromImage and current definitions of application (the merge strategy is overwrite the existing application, and reserve the other applications).

We implement the Kubefile based on Dockerfile. There are some special operations:

• Remote files: APP https://xxx AS [helm|kube]:xxx. It will be ADD https://xxx application/apps/[helm|kube]/$appname/
• Local files: APP xxx AS [helm|kube]:xxx. It will be COPY xxx application/apps/[helm|kube]/$appname/
• LAUNCH will not generate any instructions in Dockerfile.

APP could specify multiple sources, so if there are two types of sources for APP, it will generate two instructions(COPY and ADD)

TODOs:

• [x] Extract the from image for getting the image extension.
• [x] Integrate this feature to support apply.
• [ ] Image render at building.
• [ ] Env/Config.

Note

I put configurations of a app into a application/configs/[kube|helm]/[appname] and other app artifact into application/apps[kube|helm]/[appname].

I didn't complete the env or config for applications in the work. Currently the helm -f env.yaml will be rendered. I will have a detailed design for env/config. In that work, it will distinguish app-env, scripts-env and so on...

Additional

• should we provide a application cmd, to support checking info of application.

Example

1. There is a Kubefile:

FROM busybox as base
APP --files="[values.yaml, config/config.yaml]" mysql https://mysql.yaml as helm:mysql
LAUNCH --app=[mysql] --cmd="[kubectl apply -f mysql/, kubectl apply -f redis.yaml]"

2. kubefileParser will generate dockerfile and application&launch cmds dockerfile:

FROM busybox as base
copy values.yaml config/config.yaml %s
copy mysql %s
add https://mysql.yaml %s

application: {configurations, name, type} launch cmds: [ helm install -f [configPath]/values.yaml -f [configPath]/config.yaml mysql [appPath]/, kubectl apply -f mysql/, kubectl apply -f redis.yaml ]

3. dockerfile will be the input for imageEngine.Build. application&launch cmds will be stored into annotation of image.

[codecov-commenter]

Codecov Report

Base: 18.37% // Head: 19.89% // Increases project coverage by +1.52% :tada:

Coverage data is based on head (51913ef) compared to base (7b1bb6b). Patch coverage: 27.88% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1658      +/-   ##
==========================================
+ Coverage   18.37%   19.89%   +1.52%     
==========================================
  Files          66       69       +3     
  Lines        5372     6478    +1106     
==========================================
+ Hits          987     1289     +302     
- Misses       4258     5012     +754     
- Partials      127      177      +50     

Impacted Files	Coverage Δ
build/buildimage/utils.go	0.00% <0.00%> (ø)
build/kubefile/parser/file_fetcher.go	0.00% <0.00%> (ø)
build/layerutils/charts/charts.go	0.00% <ø> (ø)
cmd/sealer/cmd/utils/cluster.go	0.00% <0.00%> (ø)
pkg/cluster-runtime/installer.go	0.00% <0.00%> (ø)
pkg/cluster-runtime/utils.go	0.00% <0.00%> (ø)
pkg/clusterfile/util.go	0.00% <ø> (ø)
pkg/config/config.go	29.21% <0.00%> (-1.74%)	:arrow_down:
pkg/runtime/utils.go	12.50% <0.00%> (ø)
utils/decode.go	0.00% <ø> (ø)
... and 37 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[allencloud]

I still wish to see more illustration in the pull request description. Actually this is a quite large pr, more design info could help review a lot. @justadogistaken

[allencloud]

Thanks for your providing more details in pull request description. While, I think we should pay more energy on APPLICATION related primitives definition. And we already see the detailed implementation of your way. Design comes first, and then the implementation.

Back to your design in the picture, I feel a little bit more complicated than Dockerfile's primitives. Taking APP mysql.yml http://sealer/mysql/config.yml AS kube:mysql as an example, I think APP mysql http://sealer/mysql/config.yml is sufficient. And the APP definition grammar is:

• format APP APP_NAME [scheme]LOCATION;
• APP_NAME is the user-defined application name;
• scheme has a enum type of [file://, http://, https://], and scheme's default value is file:// which means the file location of building context.

Wish to get more feedback. @justadogistaken

[justadogistaken]

Here are my considerations for current design:

• Why declare the app type: first, I'm both ok with the order APP APP_NAME [scheme]LOCATION or APP [scheme]LOCATION APP_NAME. But I think we'd better keep the type of app, otherwise we should check the structure of source directory(values.yaml && chart && template to take it as "helm"). So I'rather make the format like APP APP_TYPE:APP_NAME [scheme]LOCATION.
• And for the configurations, I provide the options. APP --files=[schema]LOCATION --set=key=value APP_TYPE:APP_NAME [scheme]LOCATION

[allencloud]

• I'rather make the format like APP APP_TYPE:APP_NAME [scheme]LOCATION

I could understand your concern. While I insist on simplify as much as possible for the user-facing interface. With my principle, I think it is a mind-consuming way to add flag thing in APP command. @justadogistaken

[justadogistaken]

@allencloud I'm just afraid that this will need us to do application type detection, which may have potential problems. Currently our cases are not complicated. But I can't think of any issus for now.

We can remove the flag in the first version. When the use cases become more complicated, we may need to propose some limitations.

[justadogistaken]

@allencloud Let's confirm the application design of kubefile.

APP --files="[local_paths...]" app_name [local:// | http:// | https://]path...
LAUNCH --apps="[app_name...]" --cmd="[...]"

Currently, we will generate the start cmd with app_type(kube | helm) and launch. kubectl apply -f for kube. And helm install -f for helm So the problem come to how to identify the type without input from user.

Here are two solutions for me to make it.

1. We don't generate the concrete start cmd at build stage. Keep the launch info into image. Generate the concrete start cmd list at runtime.
2. We download all files and copy all local files into a shadow directory, and detect the type(according to values.yaml && templates && Charts). And translate the APP to COPY. Recognize the type in build time.

For the option 1:

• easy to implement
• hard to achieve complex verification in build time. (helm has more characteristics, we may able to provide more options, but they are not suitable for kube type)

For the option2:

• more complext to implement, key is the fetching files previously. (But it's acceptable, and we can support the local:// in the commit first)

[justadogistaken]

The current design as follows:

#HELMREPO reponame source
APP app_name [local:// | http:// | https://]path...  [helm://repo/chart:version]
LAUNCH --apps="[app_name...]"
CMDS []

The helm-related instructions will require the pre-installation of helm to users. This will strongly relies on the helm in building machine.

HELMREPO would do helm repo add reponame source on the building machine, so it might ruins the environment.

[allencloud]

Conflict happens and I have rerun the failed jobs. Have you finished all the works in this pull request ? I wish to merge this as soon as possible? @justadogistaken

[justadogistaken]

@allencloud All works are done. There may occur some problems, and we can found that while test it. (I have deployed it, and it worked)

And there is one thing I want to confirm. Image type:

• KubeInstaller: The image contains cluster runtime, which ables to install kube and applications.
• AppInstaller: No cluster runtime. Only applications can be installed.

If an image is built FROM KubeInstaller, it will be the "KubeInstaller". Otherwise it will be "AppInstaller" image.

[justadogistaken]

@sealerio/sealer-maintainers I add an option for building image. sealer build --type kube-installer | app-installer.

kube-installer:

1. It contains the the cluster runtime, which means it is able to install k8s and apps.

app-installer:

1. It does not contain the cluster runtime, it can install apps only. (Maybe it contains the cluster runtime, but it will not install k8s)

The type attribute will be inherited. If image A is typeC, Then image B is built from A, Eventually, image B is typeC too.

[kakaZhou719]

@sealerio/sealer-maintainers I add an option for building image. sealer build --type kube-installer | app-installer.

kube-installer:

1. It contains the the cluster runtime, which means it is able to install k8s and apps.

app-installer:

1. It does not contain the cluster runtime, it can install apps only. (Maybe it contains the cluster runtime, but it will not install k8s)

The type attribute will be inherited. If image A is typeC, Then image B is built from A, Eventually, image B is typeC too.

nice，It's clear to distinguish the different image types, i have a little confusion about this:

1. how about sealer build --image-type app since we take kubeinstaller as default?
2. if this attribute is inheritable, what will happens if from app to build kubeinstaller and from app to build app?

[justadogistaken]

@kakaZhou719 Your comments are valuable. For the second question, how about let's forget about "inheritable" this time? Taking the user input as image type?

[justadogistaken]

@sealerio/sealer-maintainers PTAL.

[starnop]

LGTM