kran deploy

Usagekran deploy [--version TAG] [-P|--skip-push]

Build and push the image, then render the krane templates and deploy them.

The deployment process is:

Check that docker (unless -P), the executable behind krane.command and kubectl are on PATH.
Decide the tag: --version if given, otherwise git rev-parse HEAD, with an _uncommitted_ suffix when the working tree is dirty.
docker login, with the password on standard input, when registry.username and registry.password are set.
docker build --platform ... --push, tagging <server>/<image>:<tag>.
krane render | krane deploy, with the tag as --current-sha and the full image reference as --bindings image=....

Steps 3 and 4 are skipped with -P.

Options

Option	Meaning
`--version TAG`	Use `TAG` as the image tag instead of deriving one from git
`-P`, `--skip-push`	Skip the login, build and push
`-d NAME`	Load `config/kran.NAME.yml` over `config/kran.yml`
`--dry-run`	Print the commands and run none of them

The commands it runs

$ kran deploy --dry-run
printf '%s' '[REDACTED]' | docker login ghcr.io -u acme-deploy --password-stdin
docker build --platform linux/amd64 --push -t ghcr.io/acme/storefront:9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 .
krane render -f config/deploy --current-sha 9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 --bindings image=ghcr.io/acme/storefront:9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 | KUBECONFIG=/home/dana/.kube/prod-east.yml krane deploy storefront prod-east -f config/deploy/secrets.ejson -

The third line:

krane render -f config/deploy evaluates the ERB in every template there and writes plain YAML.
--current-sha and --bindings image=... become local variables in those templates, so a Deployment can write image: <%= image %>. See krane templates.
krane deploy storefront prod-east is namespace first, context second.
-f config/deploy/secrets.ejson - passes the encrypted secrets, then - reads the rendered YAML from the pipe. Both share one -f because krane keeps only the last -f it is given. See Secrets.

krane deploy does not evaluate ERB. That is the whole reason kran pipes krane render into it instead of calling krane deploy on the template directory.

# with a builder.remote configured, both docker lines are prefixed
$ kran deploy --dry-run
printf '%s' '[REDACTED]' | DOCKER_HOST=ssh://builder@build.internal docker login ghcr.io -u acme-deploy --password-stdin
DOCKER_HOST=ssh://builder@build.internal docker build --platform linux/amd64 --push -t ghcr.io/acme/storefront:9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 .

-P, --skip-push

# only the krane pipeline, so docker is not needed either
$ kran deploy -P --dry-run
krane render -f config/deploy --current-sha 9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 --bindings image=ghcr.io/acme/storefront:9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 | KUBECONFIG=/home/dana/.kube/prod-east.yml krane deploy storefront prod-east -f config/deploy/secrets.ejson -

Use it to re-apply templates, or with --version to move a known image between environments:

kran deploy --version 9c1f4d0b7a2e58c3d6f1b8a4e70925d3c8b1a6f2 -P -d staging

It is also how you roll back: krane deploys a desired state, so rolling back is deploying the previous tag.

--version

Overrides the tag. Outside a git repository it is the only way to deploy. See Image tags.