Build and deploy Go applications on Kubernetes

ko: Easy Go Containers

Travis Build Status GitHub Actions Build Status GoDoc Go Report Card

ko is a simple, fast container image builder for Go applications.

It's ideal for use cases where your image contains a single Go application without any/many dependencies on the OS base image (e.g., no cgo, no OS package dependencies).

ko builds images by effectively executing go build on your local machine, and as such doesn't require docker to be installed. This can make it a good fit for lightweight CI/CD use cases.

ko also includes support for simple YAML templating which makes it a powerful tool for Kubernetes applications (See below).

Setup

Install

Install from Releases

VERSION=TODO # choose the latest version
OS=Linux     # or Darwin
ARCH=x86_64  # or arm64, i386, s390x
curl -L https://github.com/google/ko/releases/download/${VERSION}/ko_${VERSION}_${OS}_${ARCH}.tar.gz | tar xzf - ko
chmod +x ./ko

Install using Homebrew

brew install ko

Build and Install from Source

With Go 1.16+, build and install the latest released version:

go install github.com/google/ko

Authenticate

ko depends on the authentication configured in your Docker config (typically ~/.docker/config.json). If you can push an image with docker push, you are already authenticated for ko.

Since ko doesn't require docker, ko login also provides a surface for logging in to a container image registry with a username and password, similar to docker login.

Choose Destination

ko depends on an environment variable, KO_DOCKER_REPO, to identify where it should push images that it builds. Typically this will be a remote registry, e.g.:

  • KO_DOCKER_REPO=gcr.io/my-project, or
  • KO_DOCKER_REPO=my-dockerhub-user

Build an Image

ko publish ./cmd/app builds and pushes a container image, and prints the resulting image digest to stdout.

ko publish ./cmd/app
...
gcr.io/my-project/app-099ba5bcefdead87f92606265fb99ac0@sha256:6e398316742b7aa4a93161dce4a23bc5c545700b862b43347b941000b112ec3e

Because the output of ko publish is an image reference, you can easily pass it to other tools that expect to take an image reference:

To run the container:

docker run -p 8080:8080 $(ko publish ./cmd/app)

Or, for example, to deploy it to other services like Cloud Run:

gcloud run deploy --image=$(ko publish ./cmd/app)

Configuration

Aside from KO_DOCKER_REPO, you can configure ko's behavior using a .ko.yaml file. The location of this file can be overridden with KO_CONFIG_PATH.

Overriding Base Images

By default, ko bases images on gcr.io/distroless/static:nonroot. This is a small image that provides the bare necessities to run your Go binary.

You can override this base image in two ways:

  1. To override the base image for all images ko builds, add this line to your .ko.yaml file:
defaultBaseImage: registry.example.com/base/image
  1. To override the base image for certain importpaths:
baseImageOverrides:
  github.com/my-user/my-repo/cmd/app: registry.example.com/base/for/app
  github.com/my-user/my-repo/cmd/foo: registry.example.com/base/for/foo

Naming Images

ko provides a few different strategies for naming the image it pushes, to workaround certain registry limitations and user preferences:

Given KO_DOCKER_REPO=registry.example.com/repo, by default, ko publish ./cmd/app will produce an image named like registry.example.com/repo/app-<md5>, which includes the MD5 hash of the full import path, to avoid collisions.

  • --preserve-import-path (-P) will include the entire importpath: registry.example.com/repo/github.com/my-user/my-repo/cmd/app
  • --base (-B) will omit the MD5 portion: registry.example.com/repo/app
  • --bare will only include the KO_DOCKER_REPO: registry.example.com/repo

Local Publishing Options

ko is normally used to publish images to container image registries, identified by KO_DOCKER_REPO.

ko can also publish images to a local Docker daemon, if available, by setting KO_DOCKER_REPO=ko.local, or by passing the --local (-L) flag.

ko can also publish images to a local KinD cluster, if available, by setting KO_DOCKER_REPO=kind.local.

Multi-Platform Images

Because Go supports cross-compilation to other CPU architectures and operating systems, ko excels at producing multi-platform images.

To build and push an image for all platforms supported by the configured base image, simply add --platform=all. This will instruct ko to look up all the supported platforms in the base image, execute GOOS=<os> GOARCH=<arch> GOARM=<variant> go build for each platform, and produce a manifest list containing an image for each platform.

You can also select specific platforms, for example, --platform=linux/amd64,linux/arm64

Static Assets

ko can also bundle static assets into the images it produces.

By convention, any contents of a directory named <importpath>/kodata/ will be bundled into the image, and the path where it's available in the image will be identified by the environment variable KO_DATA_PATH.

As an example, you can bundle and serve static contents in your image:

cmd/
  app/
    main.go
    kodata/
      favicon.ico
      index.html

Then, in your main.go:

func main() {
    http.Handle("/", http.FileServer(http.Dir(os.Getenv("KO_DATA_PATH"))))
    log.Fatal(http.ListenAndServe(":8080", nil))
}

You can simulate ko's behavior outside of the container image by setting the KO_DATA_PATH environment variable yourself:

KO_DATA_PATH=cmd/app/kodata/ go run ./cmd/app

Tip: Symlinks in kodata are followed and included as well. For example, you can include Git commit information in your image with:

ln -s -r .git/HEAD ./cmd/app/kodata/

Kubernetes Integration

You could stop at just building and pushing images.

But, because building images is so easy with ko, and because building with ko only requires a string importpath to identify the image, we can integrate this with YAML generation to make Kubernetes use cases much simpler.

YAML Changes

Traditionally, you might have a Kubernetes deployment, defined in a YAML file, that runs an image:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  ...
  template:
    spec:
      containers:
      - name: my-app
        image: registry.example.com/my-app:v1.2.3

...which you apply to your cluster with kubectl apply:

kubectl apply -f deployment.yaml

With ko, you can instead reference your Go binary by its importpath, prefixed with ko://:

    ...
    spec:
      containers:
      - name: my-app
        image: ko://github.com/my-user/my-repo/cmd/app

ko resolve

With this small change, running ko resolve -f deployment.yaml will instruct ko to:

  1. scan the YAML file(s) for values with the ko:// prefix,
  2. for each unique ko://-prefixed string, execute ko publish <importpath> to build and push an image,
  3. replace ko://-prefixed string(s) in the input YAML with the fully-specified image reference of the built image(s), for example:
spec:
  containers:
    - name: my-app
      image: registry.example.com/github.com/my-user/my-repo/cmd/app@sha256:deadb33f...
  1. Print the resulting resolved YAML to stdout.

The result can be redirected to a file, to distribute to others:

ko resolve -f config/ > release.yaml

Taken together, ko resolve aims to make packaging, pushing, and referencing container images an invisible implementation detail of your Kubernetes deployment, and let you focus on writing code in Go.

ko apply

To apply the resulting resolved YAML config, you can redirect the output of ko resolve to kubectl apply:

ko resolve -f config/ | kubectl apply -f -

Since this is a relatively common use case, the same functionality is available using ko apply:

ko apply -f config/

NB: This requires that kubectl is available.

ko delete

To teardown resources applied using ko apply, you can run ko delete:

ko delete -f config/

This is purely a convenient alias for kubectl delete, and doesn't perform any builds, or delete any previously built images.

Frequently Asked Questions

How can I set ldflags?

Using -ldflags is a common way to embed version info in go binaries (In fact, we do this for ko!). Unforunately, because ko wraps go build, it's not possible to use this flag directly; however, you can use the GOFLAGS environment variable instead:

GOFLAGS="-ldflags=-X=main.version=1.2.3" ko publish .

Why are my images all created in 1970?

In order to support reproducible builds, ko doesn't embed timestamps in the images it produces by default; however, ko does respect the SOURCE_DATE_EPOCH environment variable.

For example, you can set this to the current timestamp by executing:

export SOURCE_DATE_EPOCH=$(date +%s)

or to the latest git commit's timestamp with:

export SOURCE_DATE_EPOCH=$(git log -1 --format='%ct')

Can I optimize images for eStargz support?

Yes! Set the environment variable GGCR_EXPERIMENT_ESTARGZ=1 to produce eStargz-optimized images.

Does ko support autocompletion?

Yes! ko completion generates a Bash completion script, which you can add to your bash_completion directory:

ko completion > /usr/local/etc/bash_completion.d/ko

Or, you can source it directly:

source <(ko completion)

Does ko work with Kustomize?

Yes! ko resolve -f - will read and process input from stdin, so you can have ko easily process the output of the kustomize command.

kustomize build config | ko resolve -f -

Acknowledgements

This work is based heavily on learnings from having built the Docker and Kubernetes support for Bazel. That work was presented here.

Owner
Google
Google ❤️ Open Source
Google
Comments
  • Multi-platform ko

    Multi-platform ko

    This is a sketch of what I had in mind for https://github.com/google/ko/issues/6

    For this PR, I've set the default base image for this repo to ubuntu so that you can just fetch this branch and run ko publish ./cmd/ko to test out the change. It should build a different binary for every platform and publish a manifest list instead of just a manifest.

    $ ko publish ./cmd/ko
    2019/06/17 14:04:04 Using base index.docker.io/library/ubuntu:latest for github.com/google/ko/cmd/ko
    2019/06/17 14:04:04 No matching credentials were found, falling back on anonymous
    2019/06/17 14:04:06 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:12 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:15 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:19 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:23 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:27 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:30 Publishing gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0:latest
    2019/06/17 14:04:32 existing manifest: sha256:e66f9706d017b28a5f63fd2b1a9395a43852bb8691c2a3d789bf6187ed2a83ef
    2019/06/17 14:04:32 existing manifest: sha256:6ae8959c22069d43bbaa848496237a653f4644244f638d11aa05dee555e2d7d9
    2019/06/17 14:04:32 existing manifest: sha256:d835632ac512ee32b2489d44c15ecb03a139785b2e3d475a07670288fc95242e
    2019/06/17 14:04:32 existing manifest: sha256:ce8f3571502ac3b5c86f1d527c712abd4cad953c97f24ba9b28a6505e502f1ad
    2019/06/17 14:04:32 existing manifest: sha256:5c60f74c26ec1726f06e6c35ca1a3aee0c567d37001143ec70e9cc6f5b1a763b
    2019/06/17 14:04:33 existing manifest: sha256:c1940d8d12f448cf17212cf76e012d8b8480e0b033fac5ff6068402a8f0f590f
    2019/06/17 14:04:34 gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0:latest: digest: sha256:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621 size: 1411
    2019/06/17 14:04:34 Published gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0@sha256:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621
    gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0@sha256:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621
    
    $ crane manifest gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0@sha256:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621 | jq .
    {
      "schemaVersion": 2,
      "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
      "manifests": [
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:e66f9706d017b28a5f63fd2b1a9395a43852bb8691c2a3d789bf6187ed2a83ef",
          "platform": {
            "architecture": "amd64",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:6ae8959c22069d43bbaa848496237a653f4644244f638d11aa05dee555e2d7d9",
          "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:d835632ac512ee32b2489d44c15ecb03a139785b2e3d475a07670288fc95242e",
          "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:ce8f3571502ac3b5c86f1d527c712abd4cad953c97f24ba9b28a6505e502f1ad",
          "platform": {
            "architecture": "386",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:5c60f74c26ec1726f06e6c35ca1a3aee0c567d37001143ec70e9cc6f5b1a763b",
          "platform": {
            "architecture": "ppc64le",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:c1940d8d12f448cf17212cf76e012d8b8480e0b033fac5ff6068402a8f0f590f",
          "platform": {
            "architecture": "s390x",
            "os": "linux"
          }
        }
      ]
    }
    

    I haven't actually tested pulling/running this on different platforms (I don't have any), so YMMV, but publishing works 👍

    I don't actually like this very much because I've made every package deal with a new abstraction (I've called it Steve so that we don't ever merge this) that can represent either base image or a base manifest list. A better approach would probably be to make everything deal with a manifest list to simplify things.

    When pulling base image:

    • if it's a manifest list, pass that along as the base
    • if it's an image, wrap it as a singleton manifest list

    When publishing the artifacts:

    • if it's a singleton manifest list, unwrap it and publish just the image
    • otherwise, publish it as a manifest list

    This isn't perfect (what if the user actually does want to publish a singleton manifest list?), so maybe it's not the best idea. Open to suggestions :)

  • Sign released ko binaries

    Sign released ko binaries

    Let's consider adding a signing step for ko binaries and container images with cosign? Or we should sign a checksum file as GoReleaser did ^1

    cc: @dentrax @imjasonh @jonjohnsonjr

  • Add `pkg/v1/kind` for writing images to KinD

    Add `pkg/v1/kind` for writing images to KinD

    I think we want something like: https://github.com/google/go-containerregistry/tree/master/pkg/v1/daemon

    ... but to write it directly to KinD.

    cc @BenTheElder for pointers on the best API.

    I'd love to get some mechanism like this so that we can support something like: KO_DOCKER_REPO=kind.local

  • SBOM can't be pushed to quay.io

    SBOM can't be pushed to quay.io

    $ ko version
    v0.9.4-0.20211208142815-ad0607f0a1eb
    
    $ KO_DOCKER_REPO=quay.io/imjasonh ko build ./
    2021/12/13 14:45:40 Using base golang:1.17 for github.com/google/ko
    2021/12/13 14:45:41 Building github.com/google/ko for linux/amd64
    2021/12/13 14:46:56 Publishing quay.io/imjasonh/ko-98b8c7facdad74510a7cae0cd368eb4e:latest
    2021/12/13 14:46:57 pushed blob: sha256:e4a33f5890d928895f7523a8d66d79aa990509a633e6b81d0e0006a55725f13f
    2021/12/13 14:46:59 pushed blob: sha256:1ce30adc04063fdbfb60f34e83f3ec62e91c03e4b310586239902c782f4eac7c
    Error: failed to publish images: error publishing ko://github.com/google/ko: writing sbom: PUT https://quay.io/v2/imjasonh/ko-98b8c7facdad74510a7cae0cd368eb4e/manifests/sha256-7c4c064d8ca7880b4a98674201b2c5e7c6df7fb536b5f4a470acce1a9f75f14b.sbom: MANIFEST_INVALID: manifest invalid; map[message:manifest schema version not supported]
    2021/12/13 14:46:59 error during command execution:failed to publish images: error publishing ko://github.com/google/ko: writing sbom: PUT https://quay.io/v2/imjasonh/ko-98b8c7facdad74510a7cae0cd368eb4e/manifests/sha256-7c4c064d8ca7880b4a98674201b2c5e7c6df7fb536b5f4a470acce1a9f75f14b.sbom: MANIFEST_INVALID: manifest invalid; map[message:manifest schema version not supported]
    

    If SBOM publishing was opt-in I'd say this is WAI and fine, but it's going to be a pretty bad experience for happy ko users who push to Quay (and other similar registries) when they upgrade to the next release.

    Should we log-and-continue if SBOM publishing fails?

    @mattmoor

  • Publish a `ko` image

    Publish a `ko` image

    In https://github.com/knative/build-pipeline/issues/529 and https://github.com/knative/build-pipeline/issues/528 I'm adding dogfooding CI/CD logic for publishing tekton pipelines images and yamls.

    This means I want to create a Task step or steps which invoke ko, since this is how we currently build and publish our images (via a bash script).

    To do this, I need a container with ko installed. For now I'll have a first step that installs ko, but would be great if a ko image could be published and available for folks to use.

    (Looks like #358 might be related but I'm not sure?)

  • RFC: Switch default base image to ghcr.io/distroless/static

    RFC: Switch default base image to ghcr.io/distroless/static

    The current default base image is gcr.io/distroless/static:nonroot, which we switched two about 2 years ago in https://github.com/google/ko/issues/160 (from the non-nonroot variant).

    I'd like to propose we switch the default base image to ghcr.io/distroless/static (which is also non-root), produced using apko nightly, from here https://github.com/distroless/static

    Like gcr.io/distroless/static:nonroot, ghcr.io/distroless/static is signed (keylessly!). It also includes a generated SBOM of the base image contents, and an attestation about how it was built.

    Being on GitHub Actions, its build process and logs are more visible and publicly auditable.

    Being defined in not-Bazel, in a not-Google-owned repo, makes it easier to contribute changes to it.


    If this proposal is accepted, I'd like to suggest adding a warning when defaultBaseImage is not set, saying that the change is coming in a future release.

    If you want to retain the existing base image, simply add defaultBaseImage: gcr.io/distroless/static:nonroot. To opt-in to the change before it's imposed on you automatically in a future release, defaultBaseImage: ghcr.io/distroless/static.

    Then we cut a release with that warning, wait a release, change the default base image and remove the warning.

    WDYT?

    @jonjohnsonjr @mattmoor

  • v0.8.0 tarball sha256 change?

    v0.8.0 tarball sha256 change?

    I'm attempting to update Homebrew's version of Go (Homebrew/homebrew-core#71289).

    While testing the new version, CI produced the following error:

    ==> FAILED
    ==> Downloading https://github.com/google/ko/archive/v0.8.0.tar.gz
    ==> Downloading from https://codeload.github.com/google/ko/tar.gz/v0.8.0
    Error: SHA256 mismatch
    Expected: 8ecb73697915b19ae5f3a647d877656ccaaa9f46f6c5f22e81cb8763cc0a8a18
      Actual: a1b90267574102d3fb43cab7587bbe54f221e5b79ca731781a89c7d0c1f5b2ef
        File: /Users/brew/Library/Caches/Homebrew/downloads/c4c486f4e0ec600d534026b410741c7c8c34fd303b2ff15714940e8e7eeeca56--ko-0.8.0.tar.gz
    

    I can update the sha256 associated with ko, but CI will come back to me with the following error:

    ko:

    • stable sha256 changed without the url/version also changing; please create an issue upstream to rule out malicious circumstances and to find out why the file changed.

    Could someone help understand why the tarball sha might have changed?

  • KO not authenticating against the target docker registry/repo

    KO not authenticating against the target docker registry/repo

    After successfully using KO to build the NATS channel controller and dispatcher, KO failed to deploy the image to the target registry, in this case, docker.io

    below are the execution steps to replicate this issue

    1. set KO_DOCKER_REPO = pkaisharis [account name]
    2. run ko apply -f natss/config
    3. execution results
    2019/09/24 15:00:54 Publishing index.docker.io/pkaisharis/channel_controller-c1ecaddae73c4ef9fc778b143614b0c2:latest
    2019/09/24 15:00:54 Publishing index.docker.io/pkaisharis/channel_dispatcher-c87d09956961b64d037b8b7969b36e36:latest
    2019/09/24 15:00:56 error processing import paths in "natss/config/500-dispatcher.yaml": unsupported status code 401
    

    Below is the docker.io auth config from .docker/config.json

    {
    	"auths": {
    		"https://index.docker.io/v1/": {}
    	},
    	"HttpHeaders": {
    		"User-Agent": "Docker-Client/19.03.2 (linux)"
    	},
    	"credsStore": "secretservice"
    }
    
  • ko hangs when used with ASDF installed Go

    ko hangs when used with ASDF installed Go

    I am able to reproduce either a bug, or a misconfiguration that could perhaps use a better error message of some sort.

    The reproduction is here at StevenACoffman/repro.

    Repro

    If you clone that repo and run:

    export GOPRIVATE=github.com/StevenACoffman
    cd sub
    ko publish -B --bare --local --platform=linux/amd64 --push=false .
    

    The terminal will just hang there until you hit Ctrl-c.

    At which point, it will then say:

    ^CError: error creating builder: 'builds': entry #0 does not contain a valid local import path (./.) for directory (.): err: signal: interrupt: stderr:
    2021/12/12 21:00:19 error during command execution:error creating builder: 'builds': entry #0 does not contain a valid local import path (./.) for directory (.): err: signal: interrupt: stderr:
    

    However, if you delete the .ko.yaml file in that directory and run it again, things work as you'd expect.

    rm .ko.yaml
    ko publish -B --bare --local --platform=linux/amd64 --push=false .
    

    I have tried a number of different possible values for "main" and "dir" and "id" in the .ko.yaml file, including omitting them altogether. For instance, setting the main: to the values github.com/StevenACoffman/repro/sub, ., and main don't seem to affect this hanging behavior.

    .ko.yaml contents:

    # KO_DOCKER_REPO should be either kind.local
    # (for KinD) or ko.local
    
    defaultBaseImage: gcr.io/distroless/static
    builds:
      # You can have multiple builds defined as a yaml list
      -
        # ID of the build.
        # Defaults to the project name.
        id: "my-build"
    
        # Path to project's (sub)directory containing Go code.
        # This is the working directory for the Go build command(s).
        # Default is `.`.
        dir: .
    
        # Path to main.go file or main package.
        # Notice: when used with `gomod.proxy`, this must be a package.
        #
        # Default is `.`.
        main: github.com/StevenACoffman/repro/sub
    
    
        ldflags:
          - -s 
          - -w
          - -X main.AppName=Working
    
        # Custom environment variables to be set during the builds.
        # Default is empty.
        env:
          - CGO_ENABLED=0
    

    Any help or tips would be greatly appreciated!

  • Allow comma-separated list of platforms

    Allow comma-separated list of platforms

    Fixes https://github.com/google/ko/issues/253

    Fixes https://github.com/google/ko/issues/274

    $ ko publish -B --platform=linux/amd64,linux/arm64 ./cmd/ko/
    2020/12/07 13:57:20 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/cmd/ko
    2020/12/07 13:57:21 Building github.com/google/ko/cmd/ko for linux/amd64
    2020/12/07 13:57:25 Building github.com/google/ko/cmd/ko for linux/arm64
    2020/12/07 13:57:29 Publishing gcr.io/jonjohnson-test/ko/ko:latest
    2020/12/07 13:57:30 existing blob: sha256:72164b581b02b1eb297b403bcc8fc1bfa245cb52e103a3a525a0835a58ff58e2
    2020/12/07 13:57:30 existing blob: sha256:e59bd8947ac7af2c8f4403b183326986ab554bbc262739cf5d9d596c7c7a3aca
    2020/12/07 13:57:31 pushed blob: sha256:314bd22f324d73c81d23dd94a14e3a4df6a591381e39b9164163208115c23ae4
    2020/12/07 13:57:33 pushed blob: sha256:dd714425e64113dddc2cf7a21a1b7f47c20ae29dc2072284b64fe1e7b82a5307
    2020/12/07 13:57:33 gcr.io/jonjohnson-test/ko/ko@sha256:cb6a0c6cb99e6c7b1d7dfd598484d0d25b74e15a69837f3d87c08c58ee7f88e2: digest: sha256:cb6a0c6cb99e6c7b1d7dfd598484d0d25b74e15a69837f3d87c08c58ee7f88e2 size: 751
    2020/12/07 13:57:34 existing blob: sha256:72164b581b02b1eb297b403bcc8fc1bfa245cb52e103a3a525a0835a58ff58e2
    2020/12/07 13:57:34 existing blob: sha256:d34b09c140e4b67f2c6214e24f26a68bc6b17c28d42f0dda89db38ad03488416
    2020/12/07 13:57:35 pushed blob: sha256:99af2cd1b289d3a47aba52934e2ac8c4037e92563e8a4d119b5d0e040f5b9ed3
    2020/12/07 13:57:37 pushed blob: sha256:052d3194d06e9194d60e7dcdce4c7d8e91df952f34dfddd461ce181732342db2
    2020/12/07 13:57:37 gcr.io/jonjohnson-test/ko/ko@sha256:ca19f1aa2adc983e55c1eb7d6af1ed8574991ff6762eccec8ef7b5e5d965d1ce: digest: sha256:ca19f1aa2adc983e55c1eb7d6af1ed8574991ff6762eccec8ef7b5e5d965d1ce size: 751
    2020/12/07 13:57:38 gcr.io/jonjohnson-test/ko/ko:latest: digest: sha256:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff size: 529
    2020/12/07 13:57:38 Published gcr.io/jonjohnson-test/ko/ko@sha256:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff
    gcr.io/jonjohnson-test/ko/ko@sha256:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff
    
  • ko stops building containers after Golang updates

    ko stops building containers after Golang updates

    After each minor Golang version bump (e.g. 1.13.2 -> 1.13.3), ko apply no longer builds container images but happily applies the yaml untransformed, which leads with image pull errors on the cluster. After reinstalling ko, it works again as expected.

    Ideally ko would continue to work after a Golang update, but if not, it should fail loudly and demand to be reinstalled.

  • `KO_CONFIG_PATH` pointing to a file doesn't work

    `KO_CONFIG_PATH` pointing to a file doesn't work

    It seems like setting KO_CONFIG_PATH to a file instead of a folder doesn't work. This commit seems to make it work but for some reason, it doesn't.

    On tektoncd/pipeline repo.

    $ ko version
    0.12.0
    $ cat /tmp/.ko.yaml
    defaultBaseImage: cgr.dev/chainguard/static
    baseImageOverrides:
      github.com/tektoncd/pipeline/cmd/entrypoint: ghcr.io/vdemeester/test/github.com/tektoncd/pipeline/combined-base-image@sha256:33a5146f205123032bce00d2785d62729f55d91b9d2befee37091a153a0fee18
      github.com/tektoncd/pipeline/cmd/nop: ghcr.io/vdemeester/test/github.com/tektoncd/pipeline/combined-base-image@sha256:33a5146f205123032bce00d2785d62729f55d91b9d2befee37091a153a0fee18
      github.com/tektoncd/pipeline/cmd/workingdirinit: ghcr.io/vdemeester/test/github.com/tektoncd/pipeline/combined-base-image@sha256:33a5146f205123032bce00d2785d62729f55d91b9d2befee37091a153a0fee18
      # git-init uses a base image that includes Git, and supports running either
      # as root or as user nonroot with UID 65532.
      github.com/tektoncd/pipeline/cmd/git-init: cgr.dev/chainguard/git
    $ cat .ko.yaml
    defaultBaseImage: cgr.dev/chainguard/static
    baseImageOverrides:
      # git-init uses a base image that includes Git, and supports running either
      # as root or as user nonroot with UID 65532.
      github.com/tektoncd/pipeline/cmd/git-init: cgr.dev/chainguard/git
    $ KO_CONFIG_PATH=/tmp/.ko.yaml ko resolve -f config > /tmp/foo.yaml
    # […]
    2023/01/04 10:20:09 Using base cgr.dev/chainguard/static@sha256:be400c5f4fa4d8b07fa6a4c6f0e264403f348c7b13606d49fef3f5b5e97f16d8 for github.com/tektoncd/pipeline/cmd/entrypoint
    # […]
    $ rm .ko.yaml
    $ KO_CONFIG_PATH=/tmp/.ko.yaml ko resolve -f config > /tmp/foo.yaml
    # […]
    2023/01/04 10:20:39 Using base distroless.dev/static:latest@sha256:be400c5f4fa4d8b07fa6a4c6f0e264403f348c7b13606d49fef3f5b5e97f16d8 for github.com/tektoncd/pipeline/cmd/entrypoint
    # […]
    $ KO_CONFIG_PATH=/tmp/ ko resolve -f config > /tmp/foo.yaml
    # […]
    2023/01/04 10:21:08 Using base cgr.dev/chainguard/static@sha256:be400c5f4fa4d8b07fa6a4c6f0e264403f348c7b13606d49fef3f5b5e97f16d8 for github.com/tektoncd/pipeline/cmd/webhook
    # […]
    2023/01/04 10:21:09 Using base ghcr.io/vdemeester/test/github.com/tektoncd/pipeline/combined-base-image@sha256:33a5146f205123032bce00d2785d62729f55d91b9d2befee37091a153a0fee18 for github.com/tektoncd/pipeline/cmd/entrypoint
    # […]
    $ git co .ko.yaml # trying with a .ko.yaml in path
    $ KO_CONFIG_PATH=/tmp/ ko resolve -f config > /tmp/foo.yaml
    2023/01/04 10:28:30 Using base cgr.dev/chainguard/static@sha256:be400c5f4fa4d8b07fa6a4c6f0e264403f348c7b13606d49fef3f5b5e97f16d8 for github.com/tektoncd/pipeline/cmd/webhook
    # […]
    2023/01/04 10:28:31 Using base ghcr.io/vdemeester/test/github.com/tektoncd/pipeline/combined-base-image@sha256:33a5146f205123032bce00d2785d62729f55d91b9d2befee37091a153a0fee18 for github.com/tektoncd/pipeline/cmd/entrypoint
    # […]
    

    See https://github.com/tektoncd/operator/issues/1199#issuecomment-1370650357

    cc @imjasonh @benmoss

  • [WIP] Feature: Add support for verifying base image policies.

    [WIP] Feature: Add support for verifying base image policies.

    :gift: This implements the very basics from my recent comment on #356.

    This still needs a bunch of work, but some playing with it and go run seem to demonstrate what I'd hope for.

    Things I'd like to do still:

    • [x] Add validation that warns/errors if aspects of CIP irrelevant outside K8s are used (e.g. match:, includeSpec:),
    • [x] Expand unit test coverage significantly,
    • [x] Move pkg/policy upstream to sigstore/policy-controller to facilitate using this in other projects with similar ease (e.g. kaniko, buildpacks, ...)
    • [ ] e2e tests with verification failures

    /kind feature

    Fixes: https://github.com/ko-build/ko/issues/356#issuecomment-1368273840

  • Nested config doesn't resolve build path as expected

    Nested config doesn't resolve build path as expected

    Hi, I'm struggling with using a nested config. It doesn't resolve the build path as expected and therefore the build options are not used.

    I created a minimal reproducible example here: https://github.com/bluebrown/ko-bug-nested-config

    The expected output in this project is: tag is used but I didn't manage to get the tag to be used ko.

  • enable guessing local environment os/arch by using local as option for platform flag

    enable guessing local environment os/arch by using local as option for platform flag

    Some of the tools are supporting to accept local as a value for their platform flag, such as Docker Buildx, regctl. So, can we do the same thing for ko instead of throwing an error like the following:

    $ KO_DOCKER_REPO=docker.io/devopps ko build -B  --platform local --tags buildinfo .
    Error: failed to publish images: error building "ko://github.com/developer-guy/hello-world-ko": no matching platforms in base image index
    2022/12/15 15:08:57 error during command execution:failed to publish images: error building "ko://github.com/developer-guy/hello-world-ko": no matching platforms in base image index
    

    /cc @dentrax

  • CNCF TAG-Runtime Discussion/Presentation (?)

    CNCF TAG-Runtime Discussion/Presentation (?)

    Hello ko team,

    I'm one of the co-chairs of the CNCF TAG-Runtime. I believe you had an agenda item to present the project in our meeting. For example, it would be great to learn things like the roadmap, tech, community, general overview of the project.

    Feel free to add it to our agenda or reach out to me (raravena80 at gmail.com) at your convenience.

    Thanks!

Christmas Hack Day Project: Build an Kubernetes Operator to deploy Camunda Cloud services

Camunda Cloud Operator Christmas Hack Day Project (2021): Build an Kubernetes Operator to deploy Camunda Cloud services Motiviation / Idea We currentl

May 18, 2022
Deploy, manage, and secure applications and resources across multiple clusters using CloudFormation and Shipa

CloudFormation provider Deploy, secure, and manage applications across multiple clusters using CloudFormation and Shipa. Development environment setup

Feb 12, 2022
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.

Jan 5, 2023
A simple Go app and GitHub workflow that shows how to use GitHub Actions to test, build and deploy a Go app to Docker Hub

go-pipeline-demo A repository containing a simple Go app and GitHub workflow that shows how to use GitHub Actions to test, build and deploy a Go app t

Nov 17, 2021
A tool to build, deploy, and release any environment using System Containers.
A tool to build, deploy, and release any environment using System Containers.

Bravetools Bravetools is an end-to-end System Container management utility. Bravetools makes it easy to configure, build, and deploy reproducible envi

Dec 14, 2022
A tool to build, deploy, and release any application on any platform.
A tool to build, deploy, and release any application on any platform.

Waypoint Website: https://www.waypointproject.io Tutorials: HashiCorp Learn Forum: Discuss Waypoint allows developers to define their application buil

Dec 28, 2022
Use Terraform to build and deploy configurations for Juniper SRX firewalls.
Use Terraform to build and deploy configurations for Juniper SRX firewalls.

Juniper Terraform - SRX Overview The goal of this project is to provide an example method to interact with Juniper SRX products with Terraform. ?? Ter

Mar 16, 2022
Easily deploy your Go applications with Dokku.

dokku-go-example Easily deploy your Go applications with Dokku. Features: Deploy on your own server Auto deployment HTTPS Check the full step by step

Aug 21, 2022
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration, and automating updates to configuration when there is new code to deploy.
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration, and automating updates to configuration when there is new code to deploy.

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.

Jan 8, 2023
httpserver deploy in kubernetes

httpserver deploy in kubernetes cluster What is this? The project realizes the functions of mainstream httpserver based on golang / gin, including ele

Mar 15, 2022
Digitalocean-kubernetes-challenge - Deploy a GitOps CI/CD implementation
Digitalocean-kubernetes-challenge - Deploy a GitOps CI/CD implementation

DigitalOcean Kubernetes Challenge 2021 I chose to participate in the DigitalOcean Kubernetes Challenge in order to learn more about Kubernetes and to

Nov 9, 2022
Pega-deploy - Pega deployment on Kubernetes

Pega deployment on Kubernetes This project provides Helm charts and basic exampl

Jan 30, 2022
Kubernetes OS Server - Kubernetes Extension API server exposing OS configuration like sysctl via Kubernetes API

KOSS is a Extension API Server which exposes OS properties and functionality using Kubernetes API, so it can be accessed using e.g. kubectl. At the moment this is highly experimental and only managing sysctl is supported. To make things actually usable, you must run KOSS binary as root on the machine you will be managing.

May 19, 2021
Small and easy server for web-hooks to deploy software on push from gitlab/github/hg and so on

Deployment mini-service This mini web-server is made to deploy your code without yaml-files headache. If you just need to update your code somewhere a

Dec 4, 2022
"go build" wrapper to add version info to Golang applications

govvv The simple Go binary versioning tool that wraps the go build command. Stop worrying about -ldflags and go get github.com/ahmetb/govvv now. Build

Dec 16, 2022
"go build" wrapper to add version info to Golang applications

govvv The simple Go binary versioning tool that wraps the go build command. Stop worrying about -ldflags and go get github.com/ahmetb/govvv now. Build

Dec 16, 2022
A Go based deployment tool that allows the users to deploy the web application on the server using SSH information and pem file.

A Go based deployment tool that allows the users to deploy the web application on the server using SSH information and pem file. This application is intend for non tecnhincal users they can just open the GUI and given the server details just deploy.

Oct 16, 2021
`runenv` create gcloud run deploy `--set-env-vars=` option and export shell environment from yaml file.

runenv runenv create gcloud run deploy --set-env-vars= option and export shell environment from yaml file. Motivation I want to manage Cloud Run envir

Feb 10, 2022
Automatically deploy from GitHub to Replit, lightning fast ⚡️

repl.deploy Automatically deploy from GitHub to Replit, lightning fast ⚡️ repl.deploy is split into A GitHub app, which listens for code changes and s

Dec 22, 2022