Customizing Docker Deployment¶

manage_server writes the base docker-compose.yml during install. Do not edit this file directly! Use docker-compose.override.yml, plus config.env (and occasional CLI overrides), to customize your deployment. The management interface loads config.env automatically.

Note

The compose template is parameterized via environment variables sourced from config.env. Removing or bypassing these variables can break the stack.

If, for some reason, you need to be using docker compose or docker stack deploy manually, you will need to export the full set of values. This can be done by piping manage_server env to a file.

Expanding Object Store Capacity¶

When using the bundled SeaweedFS object store, storage is allocated in fixed-size volumes. Two environment variables control the maximum usable storage on a single node:

ENTERPRISE_OBJECT_STORE_VOLUME_SIZE sets the maximum volume size in MB (cannot exceed 30000).
ENTERPRISE_OBJECT_STORE_MAX_VOLUMES sets the maximum number of volumes the bundled server can create.

The effective storage cap for the bundled object store is roughly VOLUME_SIZE * MAX_VOLUMES which, by default, is 30 GB * 32 or just under 1 TB.

These limits do not apply if you use an external S3-compatible object store.

Using an External Database¶

When using install, the CLI flags under "Database Options" can be used to the Enterprise server to use an external database. If you've already installed, you can do this manually by setting the following in config.env:

ENTERPRISE_DATABASE_NAME=
ENTERPRISE_DATABASE_HOST=
ENTERPRISE_DATABASE_PORT=
ENTERPRISE_DATABASE_USER=
ENTERPRISE_DATABASE_PASSWORD_FILE=

If you'd like to do this temporarily, for some reason, the start also accepts CLI flags to override these values.

Using External Object Storage¶

When using install, the CLI flags under "Object Store Options" can be used to the Enterprise server to use an external, S3-compatible object store. If you've already installed, you can do this manually by setting the following in config.env:

ENTERPRISE_OBJECT_STORE_BUCKET_NAME=
ENTERPRISE_OBJECT_STORE_URL=
ENTERPRISE_OBJECT_STORE_ACCESS_KEY_FILE=
ENTERPRISE_OBJECT_STORE_SECRET_KEY_FILE=

Using External Key-Value Store (Redis)¶

When using install, the CLI flags under "Key-Value Store Options" can be used to the Enterprise server to use an external, redis-compatible key-value store. If you've already installed, you can do this manually by setting the following in config.env:

ENTERPRISE_KV_STORE_URL=redis://host:port[/db]
# If WARP is enabled, also add:
WARP_REDIS_URL=redis://host:port[/db]

Deploying with Docker Swarm¶

A single-node Swarm is supported. Use --swarm[=<STACK_NAME>] when installing to switch from Compose to Swarm. Subsequent commands will auto-detect Swarm based on the presence of ENTERPRISE_STACK_NAME in config.env.

Danger

Multi-node/replicated Swarm is not yet supported. Running multiple replicas risks data loss until this is resolved.

Using a Non-Default Volume Location¶

Danger

Service interruption and/or data loss can occur if the volume you have mounted, such as an NFS volume, should ever become unmounted while the Enterprise server is running. Proceed at your own risk!

Warning

You should always make a backup of your data before messing with any volume locations. Please proceed with caution!

Note

In order to change volume locations for an existing server installation, the server must be reinitialized following these steps

By default, the Enterprise server stores all of its data in a Docker volume stored on the main partition of the host. This isn't always desirable, especially when your host is ephemeral or lacks a lot of local data. It is possible to specify a volume location that is not the default location by modifying the service definition template file.

If you want to store data on a local mountpoint instead of Docker-managed volumes, add an override that rebinds the volumes defined in the base compose (see the docker-compose.yml reference for more information):

volumes:
  data_db:
    driver_opts:
      type: none
      device: /mnt/bn/data_db
      o: bind
  data_object:
    driver_opts:
      type: none
      device: /mnt/bn/data_object
      o: bind
  # Include if WARP is deployed
  data_warp:
    driver_opts:
      type: none
      device: /mnt/bn/data_warp
      o: bind

Any mountpoint can be used in the device keys above, including those that are backed by network-based filesystems like NFS.