We only need to run the docker login commands for pushing and pulling
images.
So let's move the logins into those commands. This ensures we are logged
in when calling `kamal build` commands directly.
Fixes: https://github.com/basecamp/kamal/issues/919
If there are accessories defined in the configuration, we'll not require
servers to be defined as well.
This allows for accessory-only configurations which allows you to run
external images with kamal-proxy for zero-downtime deployments.
We don't manage image cleanup for accessories though so the user will
need to deal with that themselves.
Adds support for maintenance mode to Kamal.
There are two new commands:
- `kamal app maintenance` - puts the app in maintenance mode
- `kamal app live` - puts the app back in live mode
In maintenance mode, the kamal proxy will respond to requests with a
503 status code. It will use an error page built into kamal proxy.
You can use your own error page by setting `error_pages_path` in the
configuration. This will copy any 4xx.html or 5xx.html files from that
page to a volume mounted into the proxy container.
Maps in and external /home/kamal-proxy/.app-config volume that we can
use to map files to the proxy.
Can be used to store custom maintenance pages or SSL certificates.
Use the --registry, --repository and --image_version options of
`kamal proxy boot_config set` to change the kamal-proxy image used.
We'll still insist that the image version is at least as high as the
minimum.
Adds the host the container is being deployed to as KAMAL_HOST.
My use case is to more easily tag the host for metrics tagging,
but there might be other uses as well.
We cat the options file, append the proxy image and then pass it
to xargs to ensure it handles spaces correctly.
Works better than using eval which can handle spaces but tries
to evaluate things like backticks.
Fixes: https://github.com/basecamp/kamal/issues/1448
- Reset KAMAL on alias command, rather than relying on checking
"invoked_via_subcommand"
- Validate the accessories roles when loading the configuration
not later on when trying to access them
Add two new hooks pre-app-boot and post-app-boot. They are analagous
to the pre/post proxy reboot hooks.
If the boot strategy deploys in groups, then the hooks are called once
per group of hosts and `KAMAL_HOSTS` contains a comma delimited list of
the hosts in that group.
If all hosts are deployed to at once, then they are called once with
`KAMAL_HOSTS` containing all the hosts.
It is possible to have pauses between groups of hosts in the boot config,
where this is the case the pause happens after the post-app-boot hook is
called.
which will build a "dirty" image using the working directory.
This command is different from `build push` in two important ways:
- the image tags will have a suffix of `-dirty`
- the export action is "docker", pushing to the local docker image store
The command also supports the `--output` option just added to `build
push` to override that default.
This command is intended to allow developers to quickly iterate on a
docker image built from their local working directory while avoiding
any confusion with a pristine image built from a git clone, and
keeping those images on the local dev system by default.
which controls where the build result is exported.
The default value is "registry" to reflect the current behavior of
`build push`.
Any value provided to this option will be passed to the `buildx build`
command as a `--output=type=<VALUE>` flag.
For example, the following command will push to the local docker image
store:
kamal build push --output=docker
squash
The ERB runs first so it does matter if it in a comment. If the file
doesn't exist (e.g. if not using Ruby, you'll get an error).
We'll change the example to match the Rails deploy.yml template won't
have than problem.
