When booting non-primary role hosts we will always wait for a primary
role host to boor first.
So when booting in groups, if there are no primary role hosts in the
first batch, then booting will stall.
Sort primary role app_hosts first to avoid this.
Fixes: https://github.com/basecamp/kamal/issues/1553
Allow --metrics_port and --debug options to be set via the boot config.
--metrics_port support will come in kamal-proxy v0.8.8, so this option
doesn't work right now.
This will be updated before the next Kamal release though and we can add
integration tests for the metrics at that point.
This is for boot time configuration for the kamal proxy. Config in here
doesn't not belong in Kamal::Configuration::Proxy which is for deploy
time configuration for the app itself.
Kamal apps don't contain boot time config, because multiple apps can
share a proxy and the config could conflict.
We'll set the KAMAL_LOCK environment when calling run hooks. If set to
true we have the lock and the hook will not need to acquire it again if
it runs kamal commands.
Fixes: https://github.com/basecamp/kamal/issues/1517
Docker buildx build outputs the build logs to stderr by default.
SSHKit displays stderr logs in red, which can suggest that an error has
occurred.
Redirect the output to stdout, so it shows in green. If there is an
error, the output will be repeated in red anyway.
Fixes: https://github.com/basecamp/kamal/issues/1356
The `app exec` and `accessory exec` commands will run `docker run` if
they are not set to reuse existing containers. This might need to pull
an image so let's make sure we are logged in before running the command.
Fixes: https://github.com/basecamp/kamal/issues/1163
We hook into the SSHKit `on` method to run the pre-connect hook before
the first SSH command. This doesn't work for interactive exec commands
where ssh is called directly.
Fixes: https://github.com/basecamp/kamal/issues/1157
When booting an accessory, check for the container first and skip boot
if it exists. This allows us to rerun `kamal setup` on hosts with
accessories without raising an error.
Fixes: https://github.com/basecamp/kamal/issues/488
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.
v3 was recently released which broke the integration tests. Update them
to use the correct config file.
Set the major version to prevent this from happening when v4 is
released.
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
Somewhere along the way the docker build broke, it now needs yaml-dev
to be installed. Maybe the underlying image changed?
Update to 3.4-alpine while we are here.
- 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.
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.
We were checking before `kamal build push`, but not `kamal registry login`.
Since `kamal registry login` is called first by a deploy we don't
get the nice error message.
We only loaded the configuration once, which meant that aliases always
used the initial configuration file and destination.
We don't want to load the configuration in subcommands as it is not
passed all the options we need. But just checking if we are in a
subcommand is enough - the alias reloads and the subcommand does not.
One thing to note is that anything passed on the command line overrides
what is in the alias, so if an alias says
`other_config: config -c config/deploy2.yml` and you run
`kamal other_config -c config/deploy.yml`, it won't switch.
In Dotenv 3.1.5, `Dotenv.parse` no longer returns values that are
already in the environment.
See https://github.com/bkeepers/dotenv/issues/518
We can get the values though by setting overwrite: true, which works
with both 3.1.4 and 3.1.5.
The max-size log opt is not valid for all logging drivers, such as
syslog. Allow the option to be removed from the boot config with:
```
kamal proxy boot_config set --log-max-size=
or
kamal proxy boot_config set --log-max-size=""
```
Proxy changes:
- Add option to use custom TLS certificates (#17)
- Don't buffer SSE responses (#36)
- Allow routing to wildcard subdomains (#45)
Custom TLS certificates not supported in Kamal itself yet. Buffering
SSE responses and wildcard subdomains will work without any Kamal
changes.
Dotenv's variable substitution doesn't work the same way as commands run
in the shell. It needs values to be escaped.
```sh
$ cat /tmp/env
SECRETS=$(cat /tmp/json)
SECRETS2=$(echo $SECRETS | jq)
$ cat /tmp/json
\{\ \"foo\"\ :\ \"bar\" \}
$ SECRETS=$(cat /tmp/json)
$ SECRETS2=$(echo $SECRETS | jq)
jq: parse error: Invalid numeric literal at line 1, column 2
$ ruby -e 'require "dotenv"; puts Dotenv.parse("/tmp/env")["SECRETS2"]'
{
"foo": "bar"
}
```
Since you then can't use the shell to debug, `kamal secrets print` will
allow you to see what the secrets will be set to.
Add commands for managing proxy boot config. Since the proxy can be
shared by multiple applications, the configuration doesn't belong in
`config/deploy.yml`.
Instead you can set the config with:
```
Usage:
kamal proxy boot_config <set|get|clear>
Options:
[--publish], [--no-publish], [--skip-publish] # Publish the proxy ports on the host
# Default: true
[--http-port=N] # HTTP port to publish on the host
# Default: 80
[--https-port=N] # HTTPS port to publish on the host
# Default: 443
[--docker-options=option=value option2=value2] # Docker options to pass to the proxy container
```
By default we boot the proxy with `--publish 80:80 --publish 443:443`.
You can stop it from publishing ports, specify different ports and pass
other docker options.
The config is stored in `.kamal/proxy/options` as arguments to be passed
verbatim to docker run.
Where someone wants to set the options in their application they can do
that by calling `kamal proxy boot_config set` in a pre-deploy hook.
There's an example in the integration tests showing how to use this to
front kamal-proxy with Traefik, using an accessory.
Use localhost for app_with_roles and 127.0.0.1 for app. Confirm we can
deploy both and the respond to requests. Ensure the proxy is removed
once both have been removed.
1. Update to kamal-proxy 0.4.0 which creates and chowns
/home/kamal-proxy/.config/kamal-proxy to kamal-proxy
2. Use a docker volume rather than mapping in a directory, so docker
keeps it owned by the correct user
By default only the primary role runs the proxy. To disable the proxy
for that role, you can set `proxy: false` under it.
For other roles they default to not running the proxy, but you can
enable it by setting `proxy: true` for the role, or alternatively
setting a proxy configuration.
The proxy configuration will be merged into the root proxy configuration.
Donal McBreen