Create an Application Package

The packaging SDK tool provides a create command to construct a new Great Bear Application Package (GBAP) tree on the local filesystem. You need to edit the created GBAP to build out the package templates and metadata with the detail required to publish your containerised application to the Great Bear platform.

Usage:
  gbear application create PATH [flags]
  gbear app create PATH [flags]

Flags:
      --helm string   A path to existing Helm chart to add as sub-chart to the created GBAP
  -h, --help          help for create

The command takes an optional PATH (defaults to current working directory) as a destination to create a GBAP file system tree.

How you operate the create command really depends upon your scenario, and common scenarios have been captured in the following supported used cases.

Application used only with Great Bear

I have a containerised application and I want to create a new GBAP which will contain an new Helm Chart exclusively developed and maintained for the GB platform. The embedded GBAP Helm Chart will be modified and version controlled as part of the GBAP tree.

Example create command for this use case:

gbear app create /myPath

Expected output:

Creating a GBAP with required fields....
Enter the chart name:
myAppChart
Enter the chart version [SemVer2 MAJOR.MINOR.PATCH], (leave empty for default: 0.0.1):
1.0.0
Enter the application name:
myApp
Enter the application description:
My App Description
Successfully created a GBAP in /myPath

Resulting GBAP Tree:

/myPath
├── Chart.yaml
├── gbear
│   └── appmetadata.yaml

The tool has created the following GBAP assets:

The root Chart.yaml, containing the entered chart name and version.
A boiler plate gbear/appmetadata.yaml, containing the entered application name and description.

You can now manually extend the GBAP tree to build out your Helm template to manage Kubernetes resources, and specialise the appmetadata to publish your existing containerised application to the GB Application Store and define GB deployment parameters. For details, see Developing an App for Great Bear.

Application used and version controlled only with Great Bear

I have a containerised application and an existing Helm Chart that I want to convert into a GBAP to be exclusively developed and maintained for the GB platform. The embedded GBAP Helm Chart will be modified and version controlled as part of the GBAP tree.

The existing Helm Chart folder contains:

myPath/
├── Chart.yaml
├── templates
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── service.yaml
└── values.yaml

Example create command for this use case:

gbear app create /myPath

Expected output:

The specified path contains an existing Helm Chart, would you like to wrap this as a GBAP [Y/N]:
Y
Creating a GBAP with required fields....
Enter the application name:
myApp
Enter the application description:
My App Description
Successfully created a GBAP in path /myPath

Resulting GBAP Tree:

myPath
├── Chart.yaml
├── gbear
│   └── appmetadata.yaml
├── templates
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── service.yaml
└── values.yaml

The tool has only created the boiler plate gbear/appmetadata.yaml, containing the entered application name and description. The GBAP root directly contains the existing Helm templates and values.yaml assets to manage Kubernetes deployment.

You can now manually edit the gbear/appmetadata.yaml to set the fields required to render your application in the Great Bear Application Store, together with any Great Bear deployment configuration options to override fields within the Chart values.yaml. For details, see Developing an App for Great Bear.

Application with existing Helm chart imported to Great Bear

I have a containerised application and Helm Chart, I’d like to keep the Helm Chart agnostic to the GB platform, it is already version controlled and maintained for generic Kubernetes deployment of my application. I want to create a GBAP which allows me to pull in my existing agnostic Helm Chart as part of the package to be published to the GB platform.

Example create command for this use case:

gbear app create /pathTo/myGBAP --helm=/pathTo/v101/myAppChart

Expected output:

Creating a GBAP with required fields....
Enter the chart name:
MyChartName
Enter the chart version [SemVer2 MAJOR.MINOR.PATCH], (leave empty for default: 0.0.1):
1.0.0
Enter the application name:
MyApp
Enter the application description:
My App Desc
Successfully created a GBAP in path /pathTo/myGBAP

Resulting GBAP tree:

/pathTo/myGBAP
├── Chart.yaml     # contains dependency of myAppChart @ version 1.0.1
|── charts
|   └── myAppChart # Physical copy of myAppChart tree @ version 1.0.1
|        ├── templates
│        |    ├── _helpers.tpl
│        |    ├── deployment.yaml
│        |    ├── service.yaml
|        └── values.yaml
├── gbear
│   └── appmetadata.yaml

The tool has created the following GBAP assets:

The root Chart.yaml, containing the entered chart name and version, together with the dependency declaration for the specified –helm Chart ‘myAppChart’. The root Chart.yaml is exclusive to the GBAP, it will be maintained and version controlled as part of the GBAP.
The specified Helm Chart ‘myAppChart’ is copied in as a sub-chart to the root GBAP Chart, allowing the source Helm Chart to be decoupled from the GBAP and maintained separately. You can use the packaging SDK tool to subsequently add updated versions of the sub-chart ‘myAppChart’ to the GBAP at a cadence aligned with your agnostic application development.
A boiler plate gbear/appmetadata.yaml, containing the entered application name and description.