Publish an Application Package

Build and Upload the Application Container Image

All container images used by the Great Bear Application Package (GBAP) must be pushed to an accessible repository as a separate action to the GBAP publish. The required container images can be pushed to a repository using one of the following options:

• (Preferred): Build and push images to a Great Bear hosted image repository. You are supplied with an image registry URL and credentials as part of your tenant provisioning on the Great Bear platform.

  1. Log in to the Great Bear system using docker. To do this, run the following command, replacing , and with the credentials provided to you by Cisco:

     docker login --username=<tenant-registry-username> --password=<tenant-registry-password> <tenant-registry-url>
     

     Alternatively, you can exclude the username and password from this command, and enter them when prompted.

  2. In order to publish an application you need to build the docker image. To do this, run the following command from the directory containing the Dockerfile, replacing , <application-name> and <version-number> to reflect the values in your Helm chart:

     docker build -t <tenant-registry-url>/<application-name>:<version-number> .
     

     Note: If you are building an application for multiple architectures, see Multi-architecture docker images.

  3. Push this image to the Great Bear repository. Run the following command, replacing , <application-name>, and <version-number> with the values used in the previous step:

     docker push <tenant-registry-url>/<application-name>:<version-number>
     

• Build and push images to your own public repository which does not require any pull secrets.

Multi-architecture docker images

If you are building an application for multiple architectures then you can use buildx to create your docker image.

1. First, use the following commands to prepare docker to use buildx:

   # create and switch to using a new buildx builder for multi-arch images
   docker buildx create --use --name=appbuilder
   

2. Next, use the following modified build command, which will create images for Intel 64-bit and Arm 64-bit architectures. Replace <application-name> and <version-number> to reflect the values in your Helm chart:

   # build images for Intel 64-bit and Arm 64-bit architectures
   docker buildx build --platform linux/amd64,linux/arm64 -t <tenant-registry-url>/<application-name>:<version-number> .
   
   
   

Log in to Great Bear

The SDK tool must be configured with your API key using the gbear login command.

Publish the Great Bear Application Package

The packaging SDK tool provides a publish command to push a validated GBAP to the Application Store hosted on the Great Bear platform.

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

Flags:
  -h, --help   help for publish
      --saveArchive string   Save published archive file to the directory specified as an absolute or relative path

This command takes an optional PATH (defaults to current working directory) to a GBAP, ensures the package is valid before publishing it to the Great Bear platform.

If the command detects any validation errors it emits ERROR messages and does not attempt to publish the GBAP.

If the GBAP is valid, it creates a compressed GBAP archive file, and publishes it to the GB platform API. By default, the created GBAP archive file is deleted from your local disk after the publish command completes. You can use the –saveArchive flag to specify a local path to store the archive file for future reference.

For details on specific publishing errors, see Troubleshooting section of this user guide.

Example 1 - Publish a GBAP in the current working directory:

cd /pathTo/myGBAP
gbear app publish

Expected output if publishing is successful:

Validating Package: /pathTo/myGBAP
-- Validating Application Metadata...
-- Validating Chart Dependencies...
***
-- Validating Kubernetes Resource Labels...
Validation Complete:
Application Metadata: Passed (Errors: 0, Warnings: 0)
Chart Dependencies: Passed (Errors: 0, Warnings: 0)
Kubernetes Resource Labels: Passed (Errors: 0, Warnings: 0)
Publishing Package Archive File: my-gb-app-0.0.1.tgz
Publish Status: Success

Resulting GBAP tree:

/pathTo/myGBAP
├── Chart.yaml     
|── charts
|   └── myAppChart 
|   |    ├── templates
│   |    |    ├── _helpers.tpl
│   |    |    ├── deployment.yaml
│   |    |    ├── service.yaml
|   |    └── values.yaml
├── gbear
│   └── appmetadata.yaml
|── Chart.lock            # Captured chart dependency version tree of the validated GBAP

Example 2 - Publish a GBAP in the specified path, using the –saveArchive flag to store the published GBAP archive file:

gbear app publish /pathTo/myGBAP --saveArchive /pathTo/archives

Expected output on if publishing is successful:

Validating Package: /pathTo/myGBAP
-- Validating Application Metadata...
-- Validating Chart Dependencies...
***
-- Validating Kubernetes Resource Labels...
Validation Complete:
Application Metadata: Passed (Errors: 0, Warnings: 0)
Chart Dependencies: Passed (Errors: 0, Warnings: 0)
Kubernetes Resource Labels: Passed (Errors: 0, Warnings: 0)
Saved Package Archive: /pathTo/archives/my-gb-app-0.0.1.tgz
Publishing Package Archive File: my-gb-app-0.0.1.tgz
Publish Status: Success

Resulting GBAP tree:

/pathTo/myGBAP
├── Chart.yaml     
|── charts
|   └── myAppChart 
|   |    ├── templates
│   |    |    ├── _helpers.tpl
│   |    |    ├── deployment.yaml
│   |    |    ├── service.yaml
|   |    └── values.yaml
├── gbear
│   └── appmetadata.yaml
|── Chart.lock            # Captured chart dependency version tree of the validated GBAP
/pathTo/archives
|── my-gb-app-0.0.1.tgz   # Compressed GBAP archive file.