You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Keep the core base as small as reasonably possible.
15
-
- Put heavy operational tooling (Percona Toolkit, AWS CLI) into a separate image that builds on top of the base.
16
-
-Most services are being merged into Lupo, so we only need two images for now.
17
-
-Operational simplicity remains the top priority.
14
+
- Keep the core base to the **intersection** of shared needs across Canis services.
15
+
- Put Lupo-heavy operational tooling (Percona Toolkit, AWS CLI) in the tools image.
16
+
-Service-specific packages and scripts stay in each app's Dockerfile.
17
+
-Match existing fleet contracts (SSH, Passenger env, NTP, Shoryuken guards) so adoption is a thin Dockerfile change.
18
18
19
-
## Quick Start
19
+
## Quick start
20
20
21
-
The release workflow will automatically build and push both images to **both Docker Hub (`datacite/...`) and GHCR (`ghcr.io/datacite/...`)** using `github.ref_name` (the tag, e.g. `v1.2.3`) + the commit hash.
22
-
23
-
### Build both images locally (for testing)
21
+
### Build both images locally
24
22
25
23
```bash
26
-
# 1. Build the slim core base
24
+
# 1. Slim core base
27
25
docker buildx build \
28
26
--platform linux/amd64 \
29
27
--tag canis-base:local \
30
28
--load \
31
29
-f Dockerfile .
32
30
33
-
# 2. Build the tools variant on top of the local base
31
+
# 2. Tools variant on top of the local base
34
32
docker buildx build \
35
33
--platform linux/amd64 \
36
34
--tag canis-base-tools:local \
@@ -41,149 +39,84 @@ docker buildx build \
41
39
42
40
### Usage in application Dockerfiles
43
41
44
-
**Lupo (and other heavy services):**
42
+
**Lupo:**
45
43
46
44
```dockerfile
47
-
FROM ghcr.io/datacite/canis-base-tools:v1.2.3
45
+
FROM ghcr.io/datacite/canis-base-tools:1.2.3
48
46
```
49
47
50
-
For maximum reproducibility you can also pin to the exact hash:
48
+
**Other Canis services:**
51
49
52
50
```dockerfile
53
-
FROM ghcr.io/datacite/canis-base-tools:7f3a2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f
51
+
FROM ghcr.io/datacite/canis-base:1.2.3
54
52
```
55
53
56
-
**Lighter services:**
57
-
58
-
```dockerfile
59
-
FROM ghcr.io/datacite/canis-base:v1.2.3
60
-
```
54
+
Pin to a full commit SHA for maximum reproducibility if needed.
61
55
62
56
## What's in each image
63
57
64
-
**`canis-base`** (slim core)
65
-
-`phusion/passenger-ruby40` base (Ubuntu 24.04)
66
-
- Ruby 4.0 + rubygems 3.5.6 + bundler 2.6.9
67
-
- Passenger + Nginx setup
68
-
- Common native gem build dependencies (mysql2, nokogiri, etc.)
- SSH enabled; `PUBLIC_KEY` installed for **root** at startup
66
+
- Baked shared config/scripts (see below)
67
+
- Guarded Shoryuken runit service
68
+
69
+
**`canis-base-tools`** (on top of base)
74
70
- Percona Toolkit 3.7.1 + Perl DBI libraries
75
-
- AWS CLI v2 (used by Lupo for Passenger → CloudWatch metrics)
76
-
- dockerize
77
-
78
-
## Common `vendor/docker/` files (now in the base)
79
-
80
-
Previously, every app duplicated files in their own `vendor/docker/`. We have centralized the common ones here so they match the naming and structure used in other DataCite repos (lupo, levriero, volpino, etc.).
81
-
82
-
The following files are now provided by the base image (baked in during the base image build) from `vendor/docker/`:
Not in either image (add in the app when needed): MySQL client headers, ImageMagick/graphics libs, Chrome, dockerize, migrate-on-boot scripts.
89
74
90
-
**How to customize:**
91
-
- If your service needs a different version of any of these, simply `COPY` your own file from your app's `vendor/docker/` in your Dockerfile *after* the `FROM` line. It will override the baked-in version from the base.
92
-
- Service-specific files (e.g. custom `webapp.conf` / `webapp.conf.template`, Lupo's `70_nginx_templates.sh`, Volpino's `70_precompile.sh`, Lupo's metrics script) should remain in your app's own `vendor/docker/`.
75
+
## Baked `vendor/docker/` files
93
76
94
-
See `vendor/docker/` in this repo for the exact current versions of the shared files. This naming makes it easy to compare with the files in your app repo.
77
+
| Source | Destination | Behavior |
78
+
|--------|-------------|----------|
79
+
|`00_app_env.conf`|`/etc/nginx/conf.d/00_app_env.conf`|`passenger_app_env development;` (overridable via `PASSENGER_APP_ENV`) |
80
+
|`ntp.conf`|`/etc/ntp.conf`| Amazon NTP pool (fleet standard) |
|`shoryuken.sh`|`/etc/service/shoryuken/run`| Starts only if `AWS_REGION` is set and `DISABLE_QUEUE_WORKER` is unset |
95
83
96
-
## Tagging Strategy (Semantic Versioning)
84
+
**Migrations are not in the base.** Apps that migrate on boot should keep their own `90_migrate.sh` and `COPY` it into `/etc/my_init.d/`.
97
85
98
-
All DataCite images follow semantic versioning.
86
+
**Overrides:**`COPY` your own file after `FROM` to replace a baked path. Keep service-only files in the app (`webapp.conf`, metrics, nginx templates, precompile, etc.).
99
87
100
-
Releases are driven by git tags (e.g. `1.2.3`).
88
+
## Runtime env conventions
101
89
102
-
The workflow uses `github.ref_name` (the tag name) for the semantic version and `github.sha` for the full commit hash.
90
+
| Variable | Role |
91
+
|----------|------|
92
+
|`PUBLIC_KEY`| SSH public key for root |
93
+
|`PASSENGER_APP_ENV`| Overrides Passenger app env (default development via conf) |
94
+
|`AWS_REGION`| Required for Shoryuken to start |
95
+
|`DISABLE_QUEUE_WORKER`| If set (any non-empty value), Shoryuken does not start |
96
+
|`SERVER_ROLE`| Used by app-owned migrate scripts (not the base) |
103
97
104
-
For each release the following tags are pushed for both images:
98
+
## Tagging
105
99
106
-
-`latest`
107
-
-`1.2.3` (from `github.ref_name`)
108
-
-`<full 40-character commit SHA>` (the hash)
109
-
110
-
Example production pins:
100
+
Releases are driven by git tags. Tags pushed for both images typically include `latest`, the version tag, and the commit SHA. Prefer pinning apps to a version tag:
111
101
112
102
```dockerfile
113
-
# Recommended (human readable + reproducible)
114
-
FROM ghcr.io/datacite/canis-base-tools:1.2.3
115
-
116
-
# Maximum reproducibility (pin to the exact hash)
117
-
FROM ghcr.io/datacite/canis-base-tools:7f3a2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
103
+
FROM ghcr.io/datacite/canis-base:1.2.3
118
104
```
119
105
120
-
The `canis-base-tools`image is always built against the **exact same commit** of `canis-base`(via the build arg using the SHA). This guarantees that `canis-base-tools:1.2.3` was built on top of `canis-base:1.2.3` (same tree).
106
+
`canis-base-tools` is built against the same commit of `canis-base`for a given release.
121
107
122
108
## Ruby version
123
109
124
-
Both images only support **Ruby 4.x**.
125
-
126
-
## Example Usage
127
-
128
-
### Lupo (or other heavy services)
129
-
130
-
```dockerfile
131
-
# syntax=docker/dockerfile:1.7
132
-
FROM ghcr.io/datacite/canis-base-tools:1.2.3
133
-
134
-
LABEL maintainer="support@datacite.org"
110
+
Both images support **Ruby 4.x** only. Services still on Ruby 3 need to finish that upgrade before adopting this base (or use an interim approach).
0 commit comments