Services

Some applications need a program next to them that is not PHP: a model that recognises names in text, a converter, a search engine. A service runs it in a container of its own, in the same Scaleway project and region as the application.

In brewless.yml#

Name the service under the environment, with the directory that holds its Dockerfile:

environments:
  production:
    services:
      gliner:
        build: services/gliner
        memory: 4096
        cpu: 2240
        timeout: 300

A service name has lowercase letters and digits, starts with a letter and has no dashes; web, release and worker are taken. Without sizes a service gets 1024 MB, 560 thousandths of a vCPU, a timeout of 60 seconds and at most one replica, and it sleeps when nobody calls it (min: 0). See brewless.yml for the bounds.

Putting it live#

brewless service:push production gliner

This builds the Dockerfile with Docker on your own machine, for linux/amd64, and uploads the image straight into a private bucket of your Scaleway project. A job in that project pushes it into your project's own registry, and Brewless makes the container gliner next to the web container, or gives the one there the new image. The image is never public and never passes through Brewless. The same image is not pushed twice: its tag is the identifier Docker gave it.

The container listens on the port in the PORT variable (8080). Brewless gives it one more variable, SERVICE_TOKEN: a secret it makes once in your Secret Manager and never replaces. The service has to refuse every request that does not carry it.

Note

Brewless does not build services in your project, as it does your application: a job there runs without privileges and cannot run a Dockerfile. That is why the image of a service is built where Docker is: on your machine.

How the application reaches it#

The next deploy gives the web, release and worker containers two variables per service: GLINER_URL, the address of the service's container, and GLINER_TOKEN, the same secret the service holds. Send the secret with every call, for example as Authorization: Bearer <GLINER_TOKEN>. The application calls the service directly; Brewless is not in between.

A deploy is refused while brewless.yml names a service that does not run yet: push it first. The variables go next to the environment's own variables, so a deploy with a service also needs those kept through Brewless (push them once with brewless env:push).

Changing the sizes of a service in brewless.yml takes effect at the next brewless service:push. Taking a service out of the file stops the application getting its variables at the next deploy; the container itself keeps running until you remove it in your Scaleway console.