All operations are automated as much as possible.
- Generation of each
Dockerfileand its context is automated viaMakefile. - Maintain vX.Y branch for LTS
- Deploy container images via GitHub Actions (except Windows container images)
To update versions of images following steps are required:
- Update all required versions in
Makefile. - Update all required versions in
README.md. - Edit templates
- If you need to modify some
Dockerfiles then do it via editingDockerfile.template.erb. - If you need to modify some
fluent.confs then do it via editingfluent.conf.erb
- If you need to modify some
- Regenerate all
Dockerfiles and their context (it's okay to remove previous ones completely):make src-all
- Push changes to
masterbranch.
- We use the following image versioning convension:
v<Fluentd version>-[debian|windows-<windows version>]-[arm64(for aarch64 image)]-<image major version>.<image minor version>[]parts can be omitted in some situations:- alpine image does not use distribution name:
v<Fluentd version>-<image major version>.<image minor version> - architecture name can be omitted on
x86_64. For AArch64, it must add in the image version. e.g.v<Fluentd version>-debian-arm64-<image major version>.<image minor version>
- Reset image version to
1.0when bump up Fluentd version - Bump up image major version when including breaking changes on a destination
- Bump up image minor version when updating gems on a destination
Note: This procedure requires fluent/fluentd repository's DockerHub Admin privileges.
-
Create access token with
Read & Writepermission on hub.docker.com. -
Set
DOCKER_HUB_ORGS,DOCKER_HUB_REPOSITORY,DOCKER_HUB_USERNAMEandDOCKER_HUB_ACCESS_TOKENas GitHub repository secrets. (e.g.DOCKER_HUB_ORGS=fluent,DOCKER_HUB_REPOSITORY=fluentdand so on) -
Create tag to release it! (e.g. v1.18.0-1.0 for amd64,arm64 and armhf)
- If you deploy all images, tag
v<Fluentd version>-<image major version>.<image minor version>(e.g. v1.19.1-1.0). - If you deploy specific architecture image, tag
v<Fluentd version>-debian-[arm64(for aarch64 image)]-<image major version>.<image minor version>(e.g. v1.19.1-debian-arm64-1.0).
- If you deploy all images, tag
Built tags for debian images will be published at TAGS page.
- Windows 10 Pro
- Docker Desktop for Windows
- MSYS2 (only for
makecommand) - RubyInstaller (only for
ridkcommand) - Already logined in DockerHub via
docker login
NOTE: Using the latest version of MSYS2 is recommended. Windows Docker Engine sometimes stuck due to plenty of updates for MSYS2 packages. We should keep minimum changes on the MSYS2 installation step.
PS> ridk enable
PS> make DOCKERFILE=<Fluentd version>/windows-<windows version> VERSION=v<Fluentd version>-windows-<Windows version>-1.0
PS> docker push fluent/fluentd:v<Fluentd version>-windows-<Windows version>-1.0
PS> make DOCKERFILE=<Fluentd version>/windows-<windows version> VERSION=v<Fluentd version without patchversion>-windows-<Windows version>-1
PS> docker push fluent/fluentd:v<Fluentd version without patchversion>-windows-<Windows version>-1Building Fluentd v1.12.2 and Windows Server Core 2004 image:
PS> ridk enable
PS> make DOCKERFILE=v1.12/windows-20H2 VERSION=v1.12.2-windows-20H2-1.0
PS> docker push fluent/fluentd:v1.12.2-windows-20H2-1.0
PS> make DOCKERFILE=v1.12/windows-20H2 VERSION=v1.12-windows-20H2-1
PS> docker push fluent/fluentd:v1.12-windows-20H2-1To run tests for all possible image versions, just do:
make test-all prepare-images=yesIt will build images for each Dockerfile and run those images against
test/suite.bats.
It's still possible to build, tag and push images manually. Just use:
make release-allIt will build all existing Dockerfiles, tag them with proper tags
(as README.md requires) and push them to Docker Hub.