Kipper v0.13.0
Kipper v0.13.0
Install
curl -sL https://getkipper.com/install | shManual download
| Platform | Binary |
|---|---|
| Linux x86_64 | kip-linux-amd64 |
| Linux ARM64 | kip-linux-arm64 |
| macOS Intel | kip-darwin-amd64 |
| macOS Apple Silicon | kip-darwin-arm64 |
| Windows x86_64 | kip-windows-amd64.exe |
Linux/macOS:
chmod +x kip-*
sudo mv kip-* /usr/local/bin/kipWindows: download kip-windows-amd64.exe, rename to kip.exe, and add to your PATH.
kip install needs WSL: it shares one SSH connection across hundreds of
commands, which Windows OpenSSH does not support. Every other command works
from the native binary.
What's new
An app's git token is stored in a Secret named after the token and the host it
clones from. Rotating a token writes a new object rather than overwriting the one
a build in flight is reading, and a deploy that fails partway leaves the app
cloning with the credential it already had. Once the app has moved on and nothing
is using the old object, the cluster collects it.
If something already sits at the name a deploy computes, kip checks that it holds
the token and the host that name stands for before pointing the app at it, and
says which Secret is in the way if it does not.
kip export leaves out the credential Kipper generated for an app, since the
cluster is what names it, and keeps a shared credential you declared yourself.
kip apply keeps an app on the credential the cluster already has, so a manifest
that never mentioned a token stops detaching one.
In the console, an app with several failing containers shows the first error in
the health banner and the rest behind a link, instead of a banner that grew until
it pushed the page out of shape.
Upgrading
Run kip upgrade on a cluster before this CLI deploys to it. A credential written
by kip 0.13 carries a name an older console-api does not resolve, so the cluster
goes first and the CLI second.
Apps already running are untouched. An app moves to the new naming the first time
you rotate its token.