Run background work with a worker

What a worker is for

A Worker is an application that takes no HTTP request: a queue consumer, a bot, any process that runs all the time in the background. It has no default route, no custom domain and no port, so nothing outside its environment reaches it.

For work at a set time, such as a nightly import, create a scheduled job.

Create a worker

Owners, admins and developers create one.

1. Open the project and choose Add resource.
2. Choose Worker as the application type.
3. Choose its source.
4. Fill Entrypoint if it must start with another command than the one its image declares.

A worker often runs the code of a web application with another command: give it the same repository or image, and your queue command as its entrypoint, such as node ace queue:work.

Change its command, size and replicas

Open the worker, then More actions and Change configuration….

• Entrypoint: a program, then its arguments. Tenkai runs it without a shell. Leave it empty to start what the image declares.
• Size: the CPU and memory each replica reserves and may use.
• Replicas: from 1 to 10. Each copy takes jobs on its own, so your queue must give each job to one consumer.
• Keep replicas on separate nodes: two replicas never run on the same node, so a node that fails stops one of them at most. See keep replicas on separate nodes.

These settings apply at the next deployment. The page then shows Redeployment required, and Apply configuration runs the active release again with them.

A worker reads its configuration from variables and can be bound to a managed service. Tenkai does not set PORT for a worker.

Deploy it

Choose Deploy on the worker, or call its deploy hook from a pipeline.

Tenkai starts the new version next to the running one and waits until each replica runs, then 15 seconds more. A replica that stops in that time fails the deployment, and the active release keeps running. Open the failed deployment in the history to read why.

The old and new versions run together for a moment. Write your jobs so that either version can run them. This also happens when you drain a node: Tenkai moves the worker to another node without stopping it.

Roll back, in the history, runs an earlier release again without a build.

Find a change made on its service

If someone scales, changes or removes the service of a worker with Docker, its Health tab shows which setting differs, and Reapply puts back what Tenkai applied. See Find what was changed outside Tenkai.

Read its logs and open a terminal

See Read the logs of a resource and open a terminal.

What a worker cannot do yet

• It cannot keep files between two deployments.

Read how workers and scheduled jobs run beside your application.