Skip to content

Latest commit

 

History

History
121 lines (84 loc) · 4.45 KB

MAINTAINING.md

File metadata and controls

121 lines (84 loc) · 4.45 KB
Raw

How to use and maintain this project

All operations are automated as much as possible.

  • Travis CI is used only for tests.
  • Generation of each Dockerfile and its context is automated via Makefile.

Updating

To update versions of images following steps are required:

  1. Update all required versions in Makefile.
  2. Update all required versions in README.md.
  3. Edit templates
    1. If you need to modify some Dockerfiles then do it via editing Dockerfile.template.erb.
    2. If you need to modify some fluent.confs then do it via editing fluent.conf.erb
  4. Regenerate all Dockerfiles and their context (it's okay to remove previous ones completely): 
    make src-all
  5. If Dockerfiles layout was changed somehow (major version change, for example), you should check build triggers on Docker Hub and Travis CI configuration, modify them as required BEFORE push to master branch.
  6. Push changes to master branch.

Image versioning convensions

  1. We use the following image versioning convension:
    1. v<Fluentd version>-[debian|windows-<windows version>]-[arm64(for aarch64 image)]-<image major version>.<image minor version>
      1. [] parts can be omitted in some situations:
      2. alpine image does not use distribution name: v<Fluentd version>-<image major version>.<image minor version>
      3. 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>
    2. Reset image version to 1.0 when bump up Fluentd version
    3. Bump up image major version when including breaking changes on a destination
    4. Bump up image minor version when updating gems on a destination

Publish Images

Note: This procedure requires fluent/fluentd repository's DockerHub Admin privileges.

  1. Create access token with Read & Write permission on hub.docker.com.

  2. Set DOCKER_HUB_ORGS, DOCKER_HUB_REPOSITORY, DOCKER_HUB_USERNAME and DOCKER_HUB_ACCESS_TOKEN as GitHub repository secrets. (e.g. DOCKER_HUB_ORGS=fluent, DOCKER_HUB_REPOSITORY=fluentd and so on)

  3. Create tag to release it! (e.g. v1.18.0-1.0 for alpine,amd64,arm64 and armhf)

Built tags for debian and alpine images will be published at TAGS page.

Build and Publish Windows Server Core images

Prerequisites

  • Windows 10 Pro
  • Docker Desktop for Windows
  • MSYS2 (only for make command)
  • RubyInstaller (only for ridk command)
  • 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.

Build procedures

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>-1
CommandLine Example

Building 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-1

Testing

To run tests for all possible image versions, just do:

make test-all prepare-images=yes

It will build images for each Dockerfile and run those images against test/suite.bats.

Manual release

It's still possible to build, tag and push images manually. Just use:

make release-all

It will build all existing Dockerfiles, tag them with proper tags (as README.md requires) and push them to Docker Hub.