kamal-insecure 2.7.0

data/lib/kamal/configuration/docs/env.yml

@@ -0,0 +1,116 @@
+# Environment variables
+#
+# Environment variables can be set directly in the Kamal configuration or
+# read from `.kamal/secrets`.
+
+# Reading environment variables from the configuration
+#
+# Environment variables can be set directly in the configuration file.
+#
+# These are passed to the `docker run` command when deploying.
+env:
+  DATABASE_HOST: mysql-db1
+  DATABASE_PORT: 3306
+
+# Secrets
+#
+# Kamal uses dotenv to automatically load environment variables set in the `.kamal/secrets` file.
+#
+# If you are using destinations, secrets will instead be read from `.kamal/secrets.<DESTINATION>` if
+# it exists.
+#
+# Common secrets across all destinations can be set in `.kamal/secrets-common`.
+#
+# This file can be used to set variables like `KAMAL_REGISTRY_PASSWORD` or database passwords.
+# You can use variable or command substitution in the secrets file.
+#
+# ```shell
+# KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
+# RAILS_MASTER_KEY=$(cat config/master.key)
+# ```
+#
+# You can also use [secret helpers](../../commands/secrets) for some common password managers.
+#
+# ```shell
+# SECRETS=$(kamal secrets fetch ...)
+#
+# REGISTRY_PASSWORD=$(kamal secrets extract REGISTRY_PASSWORD $SECRETS)
+# DB_PASSWORD=$(kamal secrets extract DB_PASSWORD $SECRETS)
+# ```
+#
+# If you store secrets directly in `.kamal/secrets`, ensure that it is not checked into version control.
+#
+# To pass the secrets, you should list them under the `secret` key. When you do this, the
+# other variables need to be moved under the `clear` key.
+#
+# Unlike clear values, secrets are not passed directly to the container
+# but are stored in an env file on the host:
+env:
+  clear:
+    DB_USER: app
+  secret:
+    - DB_PASSWORD
+
+# Aliased secrets
+#
+# You can also alias secrets to other secrets using a `:` separator.
+#
+# This is useful when the ENV name is different from the secret name. For example, if you have two
+# places where you need to define the ENV variable `DB_PASSWORD`, but the value is different depending
+# on the context.
+#
+# ```shell
+# SECRETS=$(kamal secrets fetch ...)
+#
+# MAIN_DB_PASSWORD=$(kamal secrets extract MAIN_DB_PASSWORD $SECRETS)
+# SECONDARY_DB_PASSWORD=$(kamal secrets extract SECONDARY_DB_PASSWORD $SECRETS)
+# ```
+env:
+  secret:
+    - DB_PASSWORD:MAIN_DB_PASSWORD
+  tags:
+    secondary_db:
+      secret:
+        - DB_PASSWORD:SECONDARY_DB_PASSWORD
+accessories:
+  main_db_accessory:
+    env:
+      secret:
+        - DB_PASSWORD:MAIN_DB_PASSWORD
+  secondary_db_accessory:
+    env:
+      secret:
+        - DB_PASSWORD:SECONDARY_DB_PASSWORD
+
+# Tags
+#
+# Tags are used to add extra env variables to specific hosts.
+# See kamal docs servers for how to tag hosts.
+#
+# Tags are only allowed in the top-level env configuration (i.e., not under a role-specific env).
+#
+# The env variables can be specified with secret and clear values as explained above.
+env:
+  tags:
+    <tag1>:
+      MYSQL_USER: monitoring
+    <tag2>:
+      clear:
+        MYSQL_USER: readonly
+      secret:
+        - MYSQL_PASSWORD
+
+# Example configuration
+env:
+  clear:
+    MYSQL_USER: app
+  secret:
+    - MYSQL_PASSWORD
+  tags:
+    monitoring:
+      MYSQL_USER: monitoring
+    replica:
+      clear:
+        MYSQL_USER: readonly
+      secret:
+        - READONLY_PASSWORD

data/lib/kamal/configuration/docs/logging.yml

@@ -0,0 +1,21 @@
+# Custom logging configuration
+#
+# Set these to control the Docker logging driver and options.
+
+# Logging settings
+#
+# These go under the logging key in the configuration file.
+#
+# This can be specified at the root level or for a specific role.
+logging:
+
+  # Driver
+  #
+  # The logging driver to use, passed to Docker via `--log-driver`:
+  driver: json-file
+
+  # Options
+  #
+  # Any logging options to pass to the driver, passed to Docker via `--log-opt`:
+  options:
+    max-size: 100m

data/lib/kamal/configuration/docs/proxy.yml

@@ -0,0 +1,164 @@
+# Proxy
+#
+# Kamal uses [kamal-proxy](https://github.com/basecamp/kamal-proxy) to provide
+# gapless deployments. It runs on ports 80 and 443 and forwards requests to the
+# application container.
+#
+# The proxy is configured in the root configuration under `proxy`. These are
+# options that are set when deploying the application, not when booting the proxy.
+#
+# They are application-specific, so they are not shared when multiple applications
+# run on the same proxy.
+#
+proxy:
+
+  # Hosts
+  #
+  # The hosts that will be used to serve the app. The proxy will only route requests
+  # to this host to your app.
+  #
+  # If no hosts are set, then all requests will be forwarded, except for matching
+  # requests for other apps deployed on that server that do have a host set.
+  #
+  # Specify one of `host` or `hosts`.
+  host: foo.example.com
+  hosts:
+    - foo.example.com
+    - bar.example.com
+
+  # App port
+  #
+  # The port the application container is exposed on.
+  #
+  # Defaults to 80:
+  app_port: 3000
+
+  # SSL
+  #
+  # kamal-proxy can provide automatic HTTPS for your application via Let's Encrypt.
+  #
+  # This requires that we are deploying to one server and the host option is set.
+  # The host value must point to the server we are deploying to, and port 443 must be
+  # open for the Let's Encrypt challenge to succeed.
+  #
+  # If you set `ssl` to `true`, `kamal-proxy` will stop forwarding headers to your app,
+  # unless you explicitly set `forward_headers: true`
+  #
+  # Defaults to `false`:
+  ssl: true
+
+  # Custom SSL certificate
+  #
+  # In some cases, using Let's Encrypt for automatic certificate management is not an
+  # option, for example if you are running from more than one host.
+  #
+  # Or you may already have SSL certificates issued by a different Certificate Authority (CA).
+  #
+  # Kamal supports loading custom SSL certificates directly from secrets. You should
+  # pass a hash mapping the `certificate_pem` and `private_key_pem` to the secret names.
+  ssl:
+    certificate_pem: CERTIFICATE_PEM
+    private_key_pem: PRIVATE_KEY_PEM
+  # ### Notes
+  # - If the certificate or key is missing or invalid, deployments will fail.
+  # - Always handle SSL certificates and private keys securely. Avoid hard-coding them in source control.
+
+  # SSL redirect
+  #
+  # By default, kamal-proxy will redirect all HTTP requests to HTTPS when SSL is enabled.
+  # If you prefer that HTTP traffic is passed through to your application (along with
+  # HTTPS traffic), you can disable this redirect by setting `ssl_redirect: false`:
+  ssl_redirect: false
+
+  # Forward headers
+  #
+  # Whether to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers.
+  #
+  # If you are behind a trusted proxy, you can set this to `true` to forward the headers.
+  #
+  # By default, kamal-proxy will not forward the headers if the `ssl` option is set to `true`, and
+  # will forward them if it is set to `false`.
+  forward_headers: true
+
+  # Response timeout
+  #
+  # How long to wait for requests to complete before timing out, defaults to 30 seconds:
+  response_timeout: 10
+
+  # Path-based routing
+  #
+  # For applications that split their traffic to different services based on the request path,
+  # you can use path-based routing to mount services under different path prefixes.
+  path_prefix: '/api'
+  # By default, the path prefix will be stripped from the request before it is forwarded upstream.
+  # So in the example above, a request to /api/users/123 will be forwarded to web-1 as /users/123.
+  # To instead forward the request with the original path (including the prefix),
+  # specify --strip-path-prefix=false
+  strip_path_prefix: false
+
+  # Healthcheck
+  #
+  # When deploying, the proxy will by default hit `/up` once every second until we hit
+  # the deploy timeout, with a 5-second timeout for each request.
+  #
+  # Once the app is up, the proxy will stop hitting the healthcheck endpoint.
+  healthcheck:
+    interval: 3
+    path: /health
+    timeout: 3
+
+  # Buffering
+  #
+  # Whether to buffer request and response bodies in the proxy.
+  #
+  # By default, buffering is enabled with a max request body size of 1GB and no limit
+  # for response size.
+  #
+  # You can also set the memory limit for buffering, which defaults to 1MB; anything
+  # larger than that is written to disk.
+  buffering:
+    requests: true
+    responses: true
+    max_request_body: 40_000_000
+    max_response_body: 0
+    memory: 2_000_000
+
+  # Logging
+  #
+  # Configure request logging for the proxy.
+  # You can specify request and response headers to log.
+  # By default, `Cache-Control`, `Last-Modified`, and `User-Agent` request headers are logged:
+  logging:
+    request_headers:
+      - Cache-Control
+      - X-Forwarded-Proto
+    response_headers:
+      - X-Request-ID
+      - X-Request-Start
+
+# Enabling/disabling the proxy on roles
+#
+# The proxy is enabled by default on the primary role but can be disabled by
+# setting `proxy: false` in the primary role's configuration.
+#
+# ```yaml
+# servers:
+#   web:
+#     hosts:
+#      - ...
+#     proxy: false
+# ```
+#
+# It is disabled by default on all other roles but can be enabled by setting
+# `proxy: true` or providing a proxy configuration for that role.
+#
+# ```yaml
+# servers:
+#   web:
+#     hosts:
+#      - ...
+#   web2:
+#     hosts:
+#      - ...
+#     proxy: true
+# ```

data/lib/kamal/configuration/docs/registry.yml

@@ -0,0 +1,56 @@
+# Registry
+#
+# The default registry is Docker Hub, but you can change it using `registry/server`.
+#
+# By default, Docker Hub creates public repositories. To avoid making your images public,
+# set up a private repository before deploying, or change the default repository privacy
+# settings to private in your [Docker Hub settings](https://hub.docker.com/repository-settings/default-privacy).
+#
+# A reference to a secret (in this case, `DOCKER_REGISTRY_TOKEN`) will look up the secret
+# in the local environment:
+registry:
+  server: registry.digitalocean.com
+  username:
+    - DOCKER_REGISTRY_TOKEN
+  password:
+    - DOCKER_REGISTRY_TOKEN
+
+# Using AWS ECR as the container registry
+#
+# You will need to have the AWS CLI installed locally for this to work.
+# AWS ECR’s access token is only valid for 12 hours. In order to avoid having to manually regenerate the token every time, you can use ERB in the `deploy.yml` file to shell out to the AWS CLI command and obtain the token:
+registry:
+  server: <your aws account id>.dkr.ecr.<your aws region id>.amazonaws.com
+  username: AWS
+  password: <%= %x(aws ecr get-login-password) %>
+
+# Using GCP Artifact Registry as the container registry
+#
+# To sign into Artifact Registry, you need to
+# [create a service account](https://cloud.google.com/iam/docs/service-accounts-create#creating)
+# and [set up roles and permissions](https://cloud.google.com/artifact-registry/docs/access-control#permissions).
+# Normally, assigning the `roles/artifactregistry.writer` role should be sufficient.
+#
+# Once the service account is ready, you need to generate and download a JSON key and base64 encode it:
+#
+# ```shell
+# base64 -i /path/to/key.json | tr -d "\\n"
+# ```
+#
+# You'll then need to set the `KAMAL_REGISTRY_PASSWORD` secret to that value.
+#
+# Use the environment variable as the password along with `_json_key_base64` as the username.
+# Here’s the final configuration:
+registry:
+  server: <your registry region>-docker.pkg.dev
+  username: _json_key_base64
+  password:
+    - KAMAL_REGISTRY_PASSWORD
+
+# Validating the configuration
+#
+# You can validate the configuration by running:
+#
+# ```shell
+# kamal registry login
+# ```

data/lib/kamal/configuration/docs/role.yml

@@ -0,0 +1,53 @@
+# Roles
+#
+# Roles are used to configure different types of servers in the deployment.
+# The most common use for this is to run web servers and job servers.
+#
+# Kamal expects there to be a `web` role, unless you set a different `primary_role`
+# in the root configuration.
+
+# Role configuration
+#
+# Roles are specified under the servers key:
+servers:
+
+  # Simple role configuration
+  #
+  # This can be a list of hosts if you don't need custom configuration for the role.
+  #
+  # You can set tags on the hosts for custom env variables (see kamal docs env):
+  web:
+    - 172.1.0.1
+    - 172.1.0.2: experiment1
+    - 172.1.0.2: [ experiment1, experiment2 ]
+
+  # Custom role configuration
+  #
+  # When there are other options to set, the list of hosts goes under the `hosts` key.
+  #
+  # By default, only the primary role uses a proxy.
+  #
+  # For other roles, you can set it to `proxy: true` to enable it and inherit the root proxy
+  # configuration or provide a map of options to override the root configuration.
+  #
+  # For the primary role, you can set `proxy: false` to disable the proxy.
+  #
+  # You can also set a custom `cmd` to run in the container and overwrite other settings
+  # from the root configuration.
+  workers:
+    hosts:
+      - 172.1.0.3
+      - 172.1.0.4: experiment1
+    cmd: "bin/jobs"
+    options:
+      memory: 2g
+      cpus: 4
+    logging:
+      ...
+    proxy:
+      ...
+    labels:
+      my-label: workers
+    env:
+      ...
+    asset_path: /public

data/lib/kamal/configuration/docs/servers.yml

@@ -0,0 +1,27 @@
+# Servers
+#
+# Servers are split into different roles, with each role having its own configuration.
+#
+# For simpler deployments, though, where all servers are identical, you can just specify a list of servers.
+# They will be implicitly assigned to the `web` role.
+servers:
+  - 172.0.0.1
+  - 172.0.0.2
+  - 172.0.0.3
+
+# Tagging servers
+#
+# Servers can be tagged, with the tags used to add custom env variables (see kamal docs env).
+servers:
+  - 172.0.0.1
+  - 172.0.0.2: experiments
+  - 172.0.0.3: [ experiments, three ]
+
+# Roles
+#
+# For more complex deployments (e.g., if you are running job hosts), you can specify roles and configure each separately (see kamal docs role):
+servers:
+  web:
+    ...
+  workers:
+    ...

data/lib/kamal/configuration/docs/ssh.yml

@@ -0,0 +1,70 @@
+# SSH configuration
+#
+# Kamal uses SSH to connect and run commands on your hosts.
+# By default, it will attempt to connect to the root user on port 22.
+#
+# If you are using a non-root user, you may need to bootstrap your servers manually before using them with Kamal. On Ubuntu, you’d do:
+#
+# ```shell
+# sudo apt update
+# sudo apt upgrade -y
+# sudo apt install -y docker.io curl git
+# sudo usermod -a -G docker app
+# ```
+
+# SSH options
+#
+# The options are specified under the ssh key in the configuration file.
+ssh:
+
+  # The SSH user
+  #
+  # Defaults to `root`:
+  user: app
+
+  # The SSH port
+  #
+  # Defaults to 22:
+  port: "2222"
+
+  # Proxy host
+  #
+  # Specified in the form <host> or <user>@<host>:
+  proxy: root@proxy-host
+
+  # Proxy command
+  #
+  # A custom proxy command, required for older versions of SSH:
+  proxy_command: "ssh -W %h:%p user@proxy"
+
+  # Log level
+  #
+  # Defaults to `fatal`. Set this to `debug` if you are having SSH connection issues.
+  log_level: debug
+
+  # Keys only
+  #
+  # Set to `true` to use only private keys from the `keys` and `key_data` parameters,
+  # even if ssh-agent offers more identities. This option is intended for
+  # situations where ssh-agent offers many different identities or you
+  # need to overwrite all identities and force a single one.
+  keys_only: false
+
+  # Keys
+  #
+  # An array of file names of private keys to use for public key
+  # and host-based authentication:
+  keys: [ "~/.ssh/id.pem" ]
+
+  # Key data
+  #
+  # An array of strings, with each element of the array being
+  # a raw private key in PEM format.
+  key_data: [ "-----BEGIN OPENSSH PRIVATE KEY-----" ]
+
+  # Config
+  #
+  # Set to true to load the default OpenSSH config files (~/.ssh/config,
+  # /etc/ssh_config), to false ignore config files, or to a file path
+  # (or array of paths) to load specific configuration. Defaults to true.
+  config: true

data/lib/kamal/configuration/docs/sshkit.yml

@@ -0,0 +1,23 @@
+# SSHKit
+#
+# [SSHKit](https://github.com/capistrano/sshkit) is the SSH toolkit used by Kamal.
+#
+# The default, settings should be sufficient for most use cases, but
+# when connecting to a large number of hosts, you may need to adjust.
+
+# SSHKit options
+#
+# The options are specified under the sshkit key in the configuration file.
+sshkit:
+
+  # Max concurrent starts
+  #
+  # Creating SSH connections concurrently can be an issue when deploying to many servers.
+  # By default, Kamal will limit concurrent connection starts to 30 at a time.
+  max_concurrent_starts: 10
+
+  # Pool idle timeout
+  #
+  # Kamal sets a long idle timeout of 900 seconds on connections to try to avoid
+  # re-connection storms after an idle period, such as building an image or waiting for CI.
+  pool_idle_timeout: 300

data/lib/kamal/configuration/env/tag.rb

@@ -0,0 +1,13 @@
+class Kamal::Configuration::Env::Tag
+  attr_reader :name, :config, :secrets
+
+  def initialize(name, config:, secrets:)
+    @name = name
+    @config = config
+    @secrets = secrets
+  end
+
+  def env
+    Kamal::Configuration::Env.new(config: config, secrets: secrets)
+  end
+end

data/lib/kamal/configuration/env.rb

@@ -0,0 +1,38 @@
+class Kamal::Configuration::Env
+  include Kamal::Configuration::Validation
+
+  attr_reader :context, :clear, :secret_keys
+  delegate :argumentize, to: Kamal::Utils
+
+  def initialize(config:, secrets:, context: "env")
+    @clear = config.fetch("clear", config.key?("secret") || config.key?("tags") ? {} : config)
+    @secrets = secrets
+    @secret_keys = config.fetch("secret", [])
+    @context = context
+    validate! config, context: context, with: Kamal::Configuration::Validator::Env
+  end
+
+  def clear_args
+    argumentize("--env", clear)
+  end
+
+  def secrets_io
+    Kamal::EnvFile.new(aliased_secrets).to_io
+  end
+
+  def merge(other)
+    self.class.new \
+      config: { "clear" => clear.merge(other.clear), "secret" => secret_keys | other.secret_keys },
+      secrets: @secrets
+  end
+
+  private
+    def aliased_secrets
+      secret_keys.to_h { |key| extract_alias(key) }.transform_values { |secret_key| @secrets[secret_key] }
+    end
+
+    def extract_alias(key)
+      key_name, key_aliased_to = key.split(":", 2)
+      [ key_name, key_aliased_to || key_name ]
+    end
+end

data/lib/kamal/configuration/logging.rb

@@ -0,0 +1,33 @@
+class Kamal::Configuration::Logging
+  delegate :optionize, :argumentize, to: Kamal::Utils
+
+  include Kamal::Configuration::Validation
+
+  attr_reader :logging_config
+
+  def initialize(logging_config:, context: "logging")
+    @logging_config = logging_config || {}
+    validate! @logging_config, context: context
+  end
+
+  def driver
+    logging_config["driver"]
+  end
+
+  def options
+    logging_config.fetch("options", {})
+  end
+
+  def merge(other)
+    self.class.new logging_config: logging_config.deep_merge(other.logging_config)
+  end
+
+  def args
+    if driver.present? || options.present?
+      optionize({ "log-driver" => driver }.compact) +
+        argumentize("--log-opt", options)
+    else
+      argumentize("--log-opt", { "max-size" => "10m" })
+    end
+  end
+end