Version: 0.7

Manage Container Builds (Alpha)

note

The Alpha version of container build is currently limited to ECR and EKS clusters.

The container builds feature lets you:

  • Do docker builds within the Kore environment
  • Maintain oversight on who has credentials
  • Shift the burden of managing registry tokens and the cluster permissions over to Kore

Builds are registered in Kore, linking the git repository, optional access token for private repository and registry to push the image. Kore then takes care of the build, pushes and ensures all the clusters within the team have access to pull down the image.

Get the Kore CLI#

To download and install the Kore CLI, see Get the CLI.

tip

If your CI is docker based, a more attractive alternative is to use the docker image quay.io/appvia/kore.

Access private repositories#

We currently support accessing private repositories using a personal access token. Both gitlab and github have been tested.

To access a private repository:

  1. Create a secret containing the personal access token, using one of the following commands:
  • kore create secret gitlab-token NAME

  • kore create secret github-token NAME

    When you create the build use either the --secret NAME flag or choose yes I need a secret and select it from the dropdown list.

note

You can also configure this in the UI when creating a new container build.

Create a container build#

All AWS clusters built using cloud account automation have access to a registry that is automatically provisioned by Kore.

In this example, you create a build called nginx.

To view the registry:

  1. Run the following:

    $ kore get registry
    NAME PROVIDER ENDPOINT STATUS AGE
    kore-qa-notprod ecr https://686692144405.dkr.ecr.eu-west-2.amazonaws.com Success 2d13h

To create a container build:

  1. Check that there is a cluster to run the docker build process on:

    $ kore get cluster
    NAME PROVIDER PLAN ENDPOINT STATUS AGE
    dev GKE gke-budget-cluster 34.105.157.123 Pending 9m38s
  2. Create a container build named nginx, and push the above registry:

    $ kore create build nginx
    Enter the git repository (e.g git://github.com/appvia/kore.git) : git://github.com/gambol99/docker-test.git
    โœ” Enter the container image for this build (e.g appvia/kore) : appvia/nginx
    What is the location of the dockerfile : Dockerfile
    Creating build for image: https://686692144405.dkr.ecr.eu-west-2.amazonaws.com/appvia/nginx
    Waiting for resource "container.kore.appvia.io/v1alpha1/build/nginx" to provision (background with ctrl-c)
    Successfully provisioned the resource: "nginx"
    Successfully submitted the container build to kore

    You must provide the following details for build context:

    • Source git repository. This must be in the form git://url.git regardless of ssh or https.
    • Name of resulting image to create in ECR.
    • Location of the Dockerfile.
    • Whether the repository requires credentials to clone the repository.

      tip

      If you need to change the working directory of the docker build you can use:
      --build-path /PATH

  3. List the build available in the team:

    $ kore get build
    NAME REGISTRY IMAGE STATUS AGE
    nginx kore-qa-notprod appvia/nginx Success 5m12s

Manually trigger a container build#

Once a build is registered with Kore you can use the CLI to manually trigger it for testing purposes.

For CI you must provision a service account and limit its scope to trigger container builds for one or more builds.

To trigger a container build:

  1. Run kore run build NAME. For example, to trigger the nginx build:

    $ kore run build nginx
    โ—‰ Triggering container build: nginx, branch: master (gitsha: HEAD)
    โ—‰ Image: https://686692144405.dkr.ecr.eu-west-2.amazonaws.com/appvia/nginx:latest
    โ—‰ Container build: kaniko-nginx-rrh99 is running on cluster
    โ—‰ Watching the build logs
    Enumerating objects: 6, done.
    Counting objects: 100% (6/6), done.
    Compressing objects: 100% (2/2), done.
    Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
    INFO[0000] Retrieving image manifest nginx
    INFO[0000] Retrieving image nginx
    INFO[0001] Retrieving image manifest nginx
    INFO[0001] Retrieving image nginx
    INFO[0003] Built cross stage deps: map[]
    INFO[0003] Retrieving image manifest nginx
    INFO[0003] Retrieving image nginx
    INFO[0004] Retrieving image manifest nginx
    INFO[0004] Retrieving image nginx
    INFO[0005] Executing 0 build triggers
    INFO[0005] Skipping unpacking as no commands require it.
    โ—‰ Build Time: 7.242611857s
    โ—‰ Waiting for result of container build
    โ—‰ Successfully built and pushed the container: https://686692144405.dkr.ecr.eu-west-2.amazonaws.com/appvia/nginx:latest

Create a robot account for CI#

You can create a robot and assign it the kore.build role (policy plan). This role lets CI trigger any build managed under Kore for a specific team.

To see the details of the kore.build role:

  1. Run the command kore get policyplan kore.build -o yaml.

To create a build robot/token for a team:

The following creates a robot account and assigns the robot permission to trigger all builds.

  1. Create a robot account for all builds:

    kore create robot NAME

    In this example, the robot account name is builds:

    $ kore create robot builds
    โœ” Please provides a description of use for this account: Builds deployments robot account
    โœ” Use can use the following secrets within your chosen CI
    KORE_SERVER=https://HOST-NAME
    KORE_TEAM=TEAM-NAME
    KORE_TOKEN=TOKEN-STRING

    Environment variables are returned when you create the robot.

  2. Assign the kore.build permissions to the robot account:

    kore assign plan kore.build

    Follow the prompts to select a Robot Account. For this example specify its name as builds. You can choose a specific build from the list (recommended) or all. This grants the robot account access to trigger a build or all builds. For example:

    $ kore assign plan kore.build
    ? Who should the plan apply to (i.e. users, robots)
    Team Member - allows you to limit the scope by the team member
    All Subjects - allows you to scope to all subjects
    โ–ธ Robot Account - allows you to limit the scope to a specific robot account
    All Robots - scopes the permission to all robot accounts in kore
    Subject Scope - limits the scope of the token (user, robot)
    Team Role - limits the scope by team role membership of the user
    โ†ฒ Back
    ...
    โœ” You have choosen the plan: "kore.build"
    โœ” Policy will apply to robot: builds
    โ—‰ The plan has the optional value: "build" (single)
    โœ” You have selected all as the build:
    Plan has been successfully assigned to subject/s

    A policy is now assigned for this robot to trigger all builds for this team.

  3. To view the policy created above, run:

    kore get policy --robot ROBOT-NAME

    For example:

    $ kore get policy --robot builds
    NAME STATUS AGE
    build-nginx-robot-62hrf Success 74s

Use the robot token in CI#

Once you have a robot token, in your chosen CI system, add the environment variables/secrets.

  • KORE_SERVER=HOST-NAME is the kore API server, which you can see using kore profile ls.
  • KORE_TEAM=TEAM-NAME is the team the build is in.
  • KORE_TOKEN=TOKEN-STRING is the decoded secret from the robot account

For detailed information on adding environment variables in two popular CI systems, see:

To download and install the Kore CLI, see Get the CLI.