Render store backends

The render store is an object store. The controller-manager writes each applied render to it. The observer reads the renders from it. This page tells how to select and configure a backend. See Pin and history for what the store contains and how convoy uses it.

Configure the store#

Set --render-store-url on convoy-controller-manager and on convoy-observer. Use the same URL on the two components and on all their replicas. An empty value disables the render store. The flag tables are on Binaries and flags.

The value is a gocloud blob URL. convoy registers these schemes:

If convoy cannot open the URL, the process stops at start.

Examples from the dev overlays#

The storage-minio overlay uses an S3-compatible MinIO in the cluster:

s3://convoy-renders?endpoint=http://minio:9000&region=us-east-1&use_path_style=true&disable_https=true&hostname_immutable=true

• endpoint sets the address of the store.
• use_path_style=true puts the bucket name in the path, not in the host name.
• disable_https=true and the http:// endpoint send the requests without TLS. Use them only in a development cluster.

The storage-file overlay uses a PersistentVolumeClaim, mounted at /var/lib/convoy/renders:

file:///var/lib/convoy/renders?create_dir=true&no_tmp_dir=true

• create_dir=true creates the directory if it does not exist.
• no_tmp_dir=true writes the temporary file next to the final file. Without it, the write goes to /tmp first. The rename then fails when the volume is a different file system.

The storage-mem overlay uses mem://.

Credentials#

convoy has no credential flags for the render store. The gocloud driver of each scheme reads the credentials:

The storage-minio overlay sets AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from a Secret on the two Deployments. Give the controller-manager and the observer credentials that can read the bucket. The controller-manager also writes and deletes objects in it.

Choose a backend#

mem://: The store is in the memory of one process. It is empty after each restart.

• The observer has its own empty store. /history is empty, and /diff?render= fails.
• Each controller-manager replica has its own store. After a failover, the new replica cannot read the renders of the previous replica.

Use mem:// only for tests.

file://: The controller-manager and the observer must mount the same volume at the same path. The storage-file overlay uses a ReadWriteOnce PersistentVolumeClaim. All pods that mount it must run on the same node. This works in a single-node development cluster. With more than one node, or more than one replica, use a volume with ReadWriteMany access, or use an object store.

s3://, gs://, azblob://: All replicas of the two components can use the same bucket. Use one of these backends when you run more than one replica. See Scaling and high availability.

Without a render store#

convoy renders and applies as usual. These functions do not work:

• /history.
• /diff?render=.
• A pin to a render that is not the current render.
• A rollback by spec.failurePolicy to the last healthy render.

See Pin and history and Render storage.