Skip to main content
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 registryNAME               PROVIDER    ENDPOINT                                                STATUS     AGEkore-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 clusterNAME    PROVIDER    PLAN                  ENDPOINT          STATUS     AGEdev     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 nginxEnter 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/nginxWhat is the location of the dockerfile : DockerfileCreating build for image: https://686692144405.dkr.ecr.eu-west-2.amazonaws.com/appvia/nginxWaiting 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 buildNAME     REGISTRY           IMAGE           STATUS     AGEnginx    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 logsEnumerating 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 0INFO[0000] Retrieving image manifest nginxINFO[0000] Retrieving image nginxINFO[0001] Retrieving image manifest nginxINFO[0001] Retrieving image nginxINFO[0003] Built cross stage deps: map[]INFO[0003] Retrieving image manifest nginxINFO[0003] Retrieving image nginxINFO[0004] Retrieving image manifest nginxINFO[0004] Retrieving image nginxINFO[0005] Executing 0 build triggersINFO[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 CIKORE_SERVER=https://HOST-NAMEKORE_TEAM=TEAM-NAMEKORE_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 buildsNAME                              STATUS     AGEbuild-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.

Last updated on Aug 5, 2021