# Deploying encore
## Components of an encore cluster

### Redis database
Encore relies on a redis database for storing jobs data and queuing jobs. For production use, it is recommended to use a Redis Sentinel solution for high availability.

### Encore instance
An encore cluster needs one or more encore instances. The encore instances are not aware about each other, but share a redis database and a job queue.

An encore instance may process jobs or be configured to just act as API server. An instance can be configured to not process any jobs (ie act only as API server) by setting env variable `ENCORE_SETTINGS_POLL_DISABLED=true`

### Shared storage (optional)
If the cluster will be used to run chunked encoding, mounted shared storage that can be accessed by the encore instances is needed.

## Deployment
Encore instances are not aware of each other and are only linked through the shared redis database. This means adding an instance to an encore cluster just requires configuring it to use the appropriate redis database. It is also possible to combine instances deployed in different locations and through different methods into a logical 'encore cluster' just by having them use the same redis database.

### Redis
There are many options for deploying redis (or a compatible option), and the details of those fall outside of this guide. It is recommended to use a high availability option such as redis sentinel.

If using a managed redis, clients may not be allowed to issue `config` command, in which case it is necessary to configure encore with `REDIS_KEYSPACE_DISABLECONFIGNOTIFICATION=true` and manually configure keyspace notifications on the redis instance to `Ex` .

### Profiles
The encoding profiles needs to be accessible to the encore instance, either on the file system or on http. Authentication on http is currently not supported.

It is generally a good idea to keep the profiles under source control. If a non-public instance of gitlab or similar is available, it may be a good option to point the PROFILE_LOCATION URL directly to the `profile.yml` there. Otherwise the repo can be cloned to a disk where it can be accessed by encore

### Encore instances

#### Resource requirements
Requirements on CPU and memory are highly dependent on the transcoding profiles used.

#### Deploying in Kubernetes
Encore is well suited to run in kubernetes.

##### Autoscaling in kubernetes 
An efficient deployment can be achieved by using [KEDA](https://keda.sh/docs/2.17/concepts/scaling-jobs/) Scaling Jobs for creating encore worker instances based on the length of the redis queue, together with [karpenter](https://karpenter.sh/) or some other solution to scale the cluster infrastructure. A few instances of encore can be run as API servers that are always running. 

#### Deploying with docker compose
[Docker compose example file](https://github.com/Eyevinn/docker-encore/blob/main/docker-compose.yml)

#### Deploying on bare metal
Running encore directly on the server requires a recent JVM (version 21 or later), as well as having `ffmpeg`, `ffprobe`, and `mediainfo` executables in path. When those requirements have been fulfilled, encore can be started with a command like `java -jar  encore-web-0.2.8-4-boot.jar`

### Api access
Normally all encore instances provide the encore rest api. For API access, a load balancer could be run across all instances, or one or a few instances could be dedicated API instances configured with `ENCORE_SETTINGS_POLL_DISABLED=true`

### Shared storage
To be able to use chunked encoding, some kind of shared storage needs to be mounted on the same path in every encore instance. The encore instances should be configured with the env variable `ENCORE_SETTINGS_SHARED_WORK_DIR` pointing to the shared folder.

### Logs
Some way to collect logs (promtail, loki) is recommended.