ArchitectureDeploy pipeline
The build step
In the state building, the engine gets an image in one of three ways.
Git and uploads: ferry-build gets the code and runs docker build.
1 / 3
The free disk check
Before a git, upload or image deploy, the engine checks the free space of two places:
- The filesystem of the data directory.
- The root directory of Docker, when Docker is on the same machine.
Below --min-free-disk (default 1 GiB), the deploy fails immediately as build_failed. The error also tells you how to free space.
not enough free disk space on <path>: … free, Ferry needs at least 1 GiBRestarts and rollbacks have no check, because they need no space.
ferry-buildfetches the commit, or extracts the archive. It detects the runtime and writes a Dockerfile for native runtimes.- It runs
docker buildwith BuildKit. Each line of output goes into the deploy log. - The engine records the commit and its message on the deploy immediately after the checkout. Thus a failed build shows them too.
- The environment of the service reaches the build as BuildKit secrets. It is never a build argument of a Dockerfile that Ferry wrote. See the security model.
- See Builds and runtimes.
- The engine pulls an image with no tag or with the tag
latestat each deploy, because the tag can move. - It pulls other tags and digests only when the image is not on the server.
- If a pull fails but a local copy exists, the engine uses the local copy.
- Then it gives the image the tag
<prefix>/<service>:<deploy id>. This is a pinned image. Restarts, rollbacks and crash replacements of this deploy run exactly this image, even after the tag moves.
A cron job has no instance that runs all the time. Its deploy goes live with its image, its command and its limits. At each run, the scheduler starts a container from it.
==> Limits: 512 MiB memory, 1 CPU per run