Container Build & Registry Strategy¶
Image philosophy¶
Each service is packaged as a separate Docker image: - API service, - Celery worker, - Airflow components, - auxiliary services.
Images are immutable once built.
Build process¶
- images are built in CI using pinned dependencies,
- build context is minimal,
- no secrets are baked into images.
Dependency versions are derived from:
- pdm.lock,
- exported requirements-*.txt.
Registry¶
- images are pushed to GitLab Container Registry,
- access is restricted via scoped tokens,
- image tags include commit or release identifiers.
Image tagging strategy¶
Images are tagged using the following scheme:
| Context | Tag format | Example |
|---|---|---|
| Branch build (CI) | <branch>-<short-sha> |
main-a1b2c3d |
| Release | v<major>.<minor>.<patch> |
v1.2.0 |
| Latest stable | latest (staging/prod only) |
latest |
- Branch builds are tagged with the commit SHA to ensure traceability.
- Release images are tagged with a semantic version.
- The
latesttag is only promoted after a successful staging deployment. - Image tags are immutable once pushed.
Promotion model¶
- the same image artifact is promoted across environments,
- no rebuilds between staging and production.
This ensures artifact integrity.