Configuration

Using .env file to load required environment variables

MRSK uses dotenv to automatically load environment variables set in the .env file present in the application root. This file can be used to set variables like MRSK_REGISTRY_PASSWORD or database passwords. But for this reason you must ensure that .env files are not checked into Git or included in your Dockerfile! The format is just key-value like:

MRSK_REGISTRY_PASSWORD=pw
DB_PASSWORD=secret123

Using a generated .env file

1Password as a secret store

If you’re using a centralized secret store, like 1Password, you can create .env.erb as a template which looks up the secrets. Example of a .env.erb file:

<% if (session_token = `op signin --account my-one-password-account --raw`.strip) != "" %># Generated by mrsk envify
GITHUB_TOKEN=<%= `gh config get -h github.com oauth_token`.strip %>
MRSK_REGISTRY_PASSWORD=<%= `op read "op://Vault/Docker Hub/password" -n --session  #{session_token}` %>
RAILS_MASTER_KEY=<%= `op read "op://Vault/My App/RAILS_MASTER_SECRET" -n --session #{session_token}` %>
MYSQL_ROOT_PASSWORD=<%= `op read "op://Vault/My App/MYSQL_ROOT_PASSWORD" -n --session #{session_token}` %>
<% else raise ArgumentError, "Session token missing" end %>

This template can safely be checked into git. Then everyone deploying the app can run mrsk envify when they setup the app for the first time or passwords change to get the correct .env file.

If you need separate env variables for different destinations, you can set them with .env.destination.erb for the template, which will generate .env.staging when run with mrsk envify -d staging.

Bitwarden as a secret store

If you are using open source secret store like bitwarden, you can create .env.erb as a template which looks up the secrets.

You can store SOME_SECRET in a secure note in bitwarden vault:

$ bw list items --search SOME_SECRET | jq
? Master password: [hidden]

[
  {
    "object": "item",
    "id": "123123123-1232-4224-222f-234234234234",
    "organizationId": null,
    "folderId": null,
    "type": 2,
    "reprompt": 0,
    "name": "SOME_SECRET",
    "notes": "yyy",
    "favorite": false,
    "secureNote": {
      "type": 0
    },
    "collectionIds": [],
    "revisionDate": "2023-02-28T23:54:47.868Z",
    "creationDate": "2022-11-07T03:16:05.828Z",
    "deletedDate": null
  }
]

… and extract the id of SOME_SECRET from the json above and use in the erb below.

Example .env.erb file:

<% if (session_token=`bw unlock --raw`.strip) != "" %># Generated by mrsk envify
SOME_SECRET=<%= `bw get notes 123123123-1232-4224-222f-234234234234 --session #{session_token}` %>
<% else raise ArgumentError, "session_token token missing" end %>

Then everyone deploying the app can run mrsk envify and mrsk will generate .env

Using another registry than Docker Hub

The default registry is Docker Hub, but you can change it using registry/server:

registry:
  server: registry.digitalocean.com
  username:
    - DOCKER_REGISTRY_TOKEN
  password:
    - DOCKER_REGISTRY_TOKEN

A reference to secret DOCKER_REGISTRY_TOKEN will look for ENV["DOCKER_REGISTRY_TOKEN"] on the machine running MRSK.

Using a different SSH user than root

The default SSH user is root, but you can change it using ssh/user:

ssh:
  user: app

If you are using non-root user, you need to bootstrap your servers manually, before using them with MRSK. On Ubuntu, you’d do:

sudo apt update
sudo apt upgrade -y
sudo apt install -y docker.io curl git
sudo usermod -a -G docker ubuntu

Using a proxy SSH host

If you need to connect to server through a proxy host, you can use ssh/proxy:

ssh:
  proxy: "192.168.0.1" # defaults to root as the user

Or with specific user:

ssh:
  proxy: "app@192.168.0.1"

Also if you need specific proxy command to connect to the server:

ssh:
  proxy_command: aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p' --region=us-east-1 ## ssh via aws ssm

Using env variables

You can inject env variables into the app containers using env:

env:
  DATABASE_URL: mysql2://db1/hey_production/
  REDIS_URL: redis://redis1:6379/1

Using secret env variables

If you have env variables that are secret, you can divide the env block into clear and secret:

env:
  clear:
    DATABASE_URL: mysql2://db1/hey_production/
    REDIS_URL: redis://redis1:6379/1
  secret:
    - DATABASE_PASSWORD
    - REDIS_PASSWORD

The list of secret env variables will be expanded at run time from your local machine. So a reference to a secret DATABASE_PASSWORD will look for ENV["DATABASE_PASSWORD"] on the machine running MRSK. Just like with build secrets.

If the referenced secret ENVs are missing, the configuration will be halted with a KeyError exception.

Note: Marking an ENV as secret currently only redacts its value in the output for MRSK. The ENV is still injected in the clear into the container at runtime.

Using volumes

You can add custom volumes into the app containers using volumes:

volumes:
  - "/local/path:/container/path"

MRSK env variables

The following env variables are set when your container runs:

MRSK_CONTAINER_NAME : this contains the current container name and version

Using different roles for servers

If your application uses separate hosts for running jobs or other roles beyond the default web running, you can specify these hosts in a dedicated role with a new entrypoint command like so:

servers:
  web:
    - 192.168.0.1
    - 192.168.0.2
  job:
    hosts:
      - 192.168.0.3
      - 192.168.0.4
    cmd: bin/jobs

Note: Traefik will only by default be installed and run on the servers in the web role (and on all servers if no roles are defined). If you need Traefik on hosts in other roles than web, add traefik: true:

servers:
  web:
    - 192.168.0.1
    - 192.168.0.2
  web2:
    traefik: true
    hosts:
      - 192.168.0.3
      - 192.168.0.4

Using container labels

You can specialize the default Traefik rules by setting labels on the containers that are being started:

labels:
  traefik.http.routers.hey-web.rule: Host(`app.hey.com`)

Traefik rules are in the “service-role-destination” format. The default role will be web if no rule is specified. If the destination is not specified, it is not included. To give an example, the above rule would become “traefik.http.routers.hey-web.rule” if it was for the “staging” destination.

Note: The backticks are needed to ensure the rule is passed in correctly and not treated as command substitution by Bash!

This allows you to run multiple applications on the same server sharing the same Traefik instance and port. See doc.traefik.io for a full list of available routing rules.

The labels can also be applied on a per-role basis:

servers:
  web:
    - 192.168.0.1
    - 192.168.0.2
  job:
    hosts:
      - 192.168.0.3
      - 192.168.0.4
    cmd: bin/jobs
    labels:
      my-label: "50"

Using shell expansion

You can use shell expansion to interpolate values from the host machine into labels and env variables with the ${} syntax. Anything within the curly braces will be executed on the host machine and the result will be interpolated into the label or env variable.

labels:
  host-machine: "${cat /etc/hostname}"

env:
  HOST_DEPLOYMENT_DIR: "${PWD}"

Note: Any other occurrence of $ will be escaped to prevent unwanted shell expansion!

Using container options

You can specialize the options used to start containers using the options definitions:

servers:
  web:
    - 192.168.0.1
    - 192.168.0.2
  job:
    hosts:
      - 192.168.0.3
      - 192.168.0.4
    cmd: bin/jobs
    options:
      cap-add: true
      cpu-count: 4

That’ll start the job containers with docker run ... --cap-add --cpu-count 4 ....

Configuring logging

You can configure the logging driver and options passed to Docker using logging:

logging:
  driver: awslogs
  options:
    awslogs-region: "eu-central-2"
    awslogs-group: "my-app"

If nothing is configured, the default option max-size=10m is used for all containers. The default logging driver of Docker is json-file.

Using a different stop wait time

On a new deploy, each old running container is gracefully shut down with a SIGTERM, and after a grace period of 10 seconds a SIGKILL is sent. You can configure this value via the stop_wait_time option:

stop_wait_time: 30

Using remote builder for native multi-arch

If you’re developing on ARM64 (like Apple Silicon), but you want to deploy on AMD64 (x86 64-bit), you can use multi-architecture images. By default, MRSK will setup a local buildx configuration that does this through QEMU emulation. But this can be quite slow, especially on the first build.

If you want to speed up this process by using a remote AMD64 host to natively build the AMD64 part of the image, while natively building the ARM64 part locally, you can do so using builder options:

builder:
  local:
    arch: arm64
    host: unix:///Users/<%= `whoami`.strip %>/.docker/run/docker.sock
  remote:
    arch: amd64
    host: ssh://root@192.168.0.1

Note: You must have Docker running on the remote host being used as a builder. This instance should only be shared for builds using the same registry and credentials.

Using remote builder for single-arch

If you’re developing on ARM64 (like Apple Silicon), want to deploy on AMD64 (x86 64-bit), but don’t need to run the image locally (or on other ARM64 hosts), you can configure a remote builder that just targets AMD64. This is a bit faster than building with multi-arch, as there’s nothing to build locally.

builder:
  remote:
    arch: amd64
    host: ssh://root@192.168.0.1

Using native builder when multi-arch isn’t needed

If you’re developing on the same architecture as the one you’re deploying on, you can speed up the build by forgoing both multi-arch and remote building:

builder:
  multiarch: false

This is also a good option if you’re running MRSK from a CI server that shares architecture with the deployment servers.

Using a different Dockerfile or context when building

If you need to pass a different Dockerfile or context to the build command (e.g. if you’re using a monorepo or you have different Dockerfiles), you can do so in the builder options:

# Use a different Dockerfile
builder:
  dockerfile: Dockerfile.xyz

# Set context
builder:
  context: ".."

# Set Dockerfile and context
builder:
  dockerfile: "../Dockerfile.xyz"
  context: ".."

Using build secrets for new images

Some images need a secret passed in during build time, like a GITHUB_TOKEN, to give access to private gem repositories. This can be done by having the secret in ENV, then referencing it in the builder configuration:

builder:
  secrets:
    - GITHUB_TOKEN

This build secret can then be referenced in the Dockerfile:

# Copy Gemfiles
COPY Gemfile Gemfile.lock ./

# Install dependencies, including private repositories via access token (then remove bundle cache with exposed GITHUB_TOKEN)
RUN --mount=type=secret,id=GITHUB_TOKEN \
  BUNDLE_GITHUB__COM=x-access-token:$(cat /run/secrets/GITHUB_TOKEN) \
  bundle install && \
  rm -rf /usr/local/bundle/cache

Traefik command arguments

Customize the Traefik command line using args:

traefik:
  args:
    accesslog: true
    accesslog.format: json

This starts the Traefik container with --accesslog=true --accesslog.format=json arguments.

Traefik host port binding

Traefik binds to port 80 by default. Specify an alternative port using host_port:

traefik:
  host_port: 8080

Traefik version, upgrades, and custom images

MRSK runs the traefik:v2.9 image to track Traefik 2.9.x releases.

To pin Traefik to a specific version or an image published to your registry, specify image:

traefik:
  image: traefik:v2.10.0-rc1

This is useful for downgrading Traefik if there’s an unexpected breaking change in a minor version release, upgrading Traefik to test forthcoming releases, or running your own Traefik-derived image.

MRSK has not been tested for compatibility with Traefik 3 betas. Please do!

Traefik container configuration

Pass additional Docker configuration for the Traefik container using options:

traefik:
  options:
    publish:
      - 8080:8080
    volumes:
      - /tmp/example.json:/tmp/example.json
    memory: 512m

This starts the Traefik container with --volume /tmp/example.json:/tmp/example.json --publish 8080:8080 --memory 512m arguments to docker run.

Traefik container labels

Add labels to Traefik Docker container.

traefik:
  labels:
    traefik.enable: true
    traefik.http.routers.dashboard.rule: Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))
    traefik.http.routers.dashboard.service: api@internal
    traefik.http.routers.dashboard.middlewares: auth
    traefik.http.middlewares.auth.basicauth.users: test:$2y$05$H2o72tMaO.TwY1wNQUV1K.fhjRgLHRDWohFvUZOJHBEtUXNKrqUKi # test:password

This labels Traefik container with --label traefik.http.routers.dashboard.middlewares=\"auth\" and so on.

Traefik alternate entrypoints

You can configure multiple entrypoints for Traefik like so:

service: myservice

labels:
  traefik.tcp.routers.other.rule: 'HostSNI(`*`)'
  traefik.tcp.routers.other.entrypoints: otherentrypoint
  traefik.tcp.services.other.loadbalancer.server.port: 9000
  traefik.http.routers.myservice.entrypoints: web
  traefik.http.services.myservice.loadbalancer.server.port: 8080

traefik:
  options:
    publish:
      - 9000:9000
  args:
    entrypoints.web.address: ':80'
    entrypoints.otherentrypoint.address: ':9000'

Configuring build args for new images

Build arguments that aren’t secret can also be configured:

builder:
  args:
    RUBY_VERSION: 3.2.0

This build argument can then be used in the Dockerfile:

ARG RUBY_VERSION
FROM ruby:$RUBY_VERSION-slim as base

Using accessories for database, cache, search services

You can manage your accessory services via MRSK as well. Accessories are long-lived services that your app depends on. They are not updated when you deploy.

accessories:
  mysql:
    image: mysql:5.7
    host: 1.1.1.3
    port: 3306
    env:
      clear:
        MYSQL_ROOT_HOST: '%'
      secret:
        - MYSQL_ROOT_PASSWORD
    volumes:
      - /var/lib/mysql:/var/lib/mysql
    options:
      cpus: 4
      memory: "2GB"
  redis:
    image: redis:latest
    roles:
      - web
    port: "36379:6379"
    volumes:
      - /var/lib/redis:/data
  internal-example:
    image: registry.digitalocean.com/user/otherservice:latest
    host: 1.1.1.5
    port: 44444

The hosts that the accessories will run on can be specified by hosts or roles:

  # Single host
  mysql:
    host: 1.1.1.1
  # Multiple hosts
  redis:
    hosts:
      - 1.1.1.1
      - 1.1.1.2
  # By role
  monitoring:
    roles:
      - web
      - jobs

Now run mrsk accessory start mysql to start the MySQL server on 1.1.1.3. See mrsk accessory for all the commands possible.

Accessory images must be public or tagged in your private registry.

Using Cron

You can use a specific container to run your Cron jobs:

servers:
  cron:
    hosts:
      - 192.168.0.1
    cmd:
      bash -c "cat config/crontab | crontab - && cron -f"

This assumes the Cron settings are stored in config/crontab.

Using audit broadcasts

If you’d like to broadcast audits of deploys, rollbacks, etc to a chatroom or elsewhere, you can configure the audit_broadcast_cmd setting with the path to a bin file that will be passed the audit line as the first argument:

audit_broadcast_cmd:
  bin/audit_broadcast

The broadcast command could look something like:

#!/usr/bin/env bash
curl -q -d content="[My App] ${1}" https://3.basecamp.com/XXXXX/integrations/XXXXX/buckets/XXXXX/chats/XXXXX/lines

That’ll post a line like follows to a preconfigured chatbot in Basecamp:

[My App] [dhh] Rolled back to version d264c4e92470ad1bd18590f04466787262f605de

Custom healthcheck

MRSK defaults to checking the health of your application again /up on port 3000 up to 7 times. You can tailor the behaviour with the healthcheck setting:

healthcheck:
  path: /healthz
  port: 4000
  max_attempts: 7

This will ensure your application is configured with a traefik label for the healthcheck against /healthz and that the pre-deploy healthcheck that MRSK performs is done against the same path on port 4000.

The healthcheck also allows for an optional max_attempts setting, which will attempt the healthcheck up to the specified number of times before failing the deploy. This is useful for applications that take a while to start up. The default is 7.