ArchitectureSecurity model
One runaway service
Each container has limits. A service with a bug cannot stop the full server.
A service leaks memory. The kernel kills its container at the memory limit, and no other process.
1 / 5
Each container that Ferry starts has a memory limit, a CPU limit, a process limit and log rotation. This applies to service instances, one-off jobs, cron runs and datastores. It does not apply to builds.
Ferry cannot stop a hostile app
Each person who can deploy can run any code on the server. The limits protect the server from a bug, not from an attack.
With the default options
| When a service… | What happens |
|---|---|
| Leaks memory | The kernel kills its container at its memory limit: 512 MiB by default, with no swap above it. The kernel does not choose another process of the host, such as ferryd, dockerd or a database. Docker restarts the container. ferryd writes the kill in the server log. ferry status and the dashboard mark the instance as OOM killed while it restarts. |
| Spins the CPU | Docker throttles it at its CPU limit: 1 CPU per container by default. The other cores stay free. On a host with 1 CPU, the default is the full host: lower --default-cpu-limit there. |
| Forks without end | It stops at 1024 processes and threads per container. fork fails in the container. The process table of the host stays untouched. |
| Logs without end | The json-file log of Docker rotates at 10 MiB × 3 files: about 30 MiB per container at most. A Docker daemon with another log driver keeps that driver, with its own limits. |
| Deploys onto a nearly full disk | The deploy, or a new datastore, fails before the build or the pull. The message names the path. Restarts and rollbacks continue to work. |
Resource limits tells how the limits work. Production setup tells how to size them.