先日、Fluentdのv1.18.0をリリースしました。

v1.18.0の変更点についてはFluentd v1.18.0をリリースに関する記事を参照していただくとして、このリリースから、Docker Hubで提供しているコンテナイメージの提供方法を改善し、 GitHubでリリース用のタグを打つことで、コンテナイメージをDocker Hubへとデプロイできるようにしました。

本記事ではどのようにしてそのしくみを実現したのかについて概要を説明します。

従来のコンテナイメージのデプロイ方法

これまでは、FluentdはSponsored OSSでありDocker Free Teamとして扱われていました。この状態だと、Automated BuildsとよばれるコンテナイメージをWebインターフェースから簡単にビルドできる仕組みが利用可能でした。

しかし、Sponsored OSSであり、Docker Free Teamに所属していても、いつからかAutomated BuildsのWebインタフェースが利用できなくなりました。

したがって、これまでのようにWebインタフェースから簡単にコンテナイメージをビルド・デプロイすることができなくなりました。

Dockerfileとイメージをデプロイするためのフックの設定（hub.docker.com側でWebインタフェースと連動して実行される）をメンテナンスしていましたが、その仕組みは使えなくなったのです。 Automated BuildsのWebインタフェースが利用できることを前提としたフックとなっていたので、これらを置き換える必要がでてきました。そこで、Automated Buildsに依存しない新たなやり方を模索する必要がありました。

GitHub Actionsへの移行のポイント

Fluentdのコンテナイメージとしては次の5つのタイプのイメージを提供していました。 (Windowsのコンテナイメージだけは別途手動でメンテナンスしています。)

alpine (非推奨。歴史的経緯でまだ提供している)
amd64
arm64
armhf
Windows

このうち、Windowsのコンテナイメージを除いてGitHub Actionsでコンテナイメージをビルド、アップロードするようにしました。具体的な例はdocker-build.ymlです。

基本的には次のようなことを実施しています。

特定のGitタグがpushされたらGitHub Actionsのワークフローを実行する
- 例: v1.18.0など
各イメージに応じたDockerタグの組み合わせのパターンを生成する
- 例: v1.18.0-debian-amd64-1.0, v1.18-debian-amd64-1, edge-debian-amd64など。v1.18.0-debian-amd64-1.0は特定のイメージに限定して利用するためのDockerタグで、v1.18-debian-amd64-1や edge-debian-amd64はより新しいイメージがリリースされたらそちらを参照できるようにするためのDockerタグ。
docker/build-push-action@v6 といった既存のActionを利用して、各プラットフォーム(alpine,amd64,arm64,armhf)ごとのイメージをビルドする

uses: docker/build-push-action@v6
with:
  context: ${{ env.CONTEXT }}
  provenance: false
  push: true
  platforms: linux/amd64
  tags: ${{ env.ALPINETAGS }}
  # dare to use old mediatype (application/vnd.docker.distribution.manifest.v2+json)
  outputs: oci-mediatypes=false

docker buildx imagetoolsを利用して、すでにビルドしたイメージに対してマルチアーキテクチャに対応したDockerタグを付与する

   docker buildx imagetools create -t ${{ env.REPOSITORY }}:${MULTIARCH_AMD64_TAG} \
              ${{ env.REPOSITORY }}:${AMD64TAG} \
              ${{ env.REPOSITORY }}:${ARM64TAG} \
              ${{ env.REPOSITORY }}:${ARMHFTAG}

なお、ベースイメージがすでにマルチアーキテクチャ対応のイメージであり、Dockerfileを異なるアーキテクチャ間であっても共通化できている場合には、次のようなもっとシンプルなルールでマルチアーキテクチャに対応したイメージをビルドできるでしょう。また、個別にdocker buildx imagetoolsなどを使う必要もないはずです。

uses: docker/build-push-action@v6
with:
  context: .
  file: ${{ env.DOCKERFILE }}
  provenance: false
  push: true
  platforms: linux/amd64,linux/arm64,linux/arm/v7
  tags: ${{ env.TAGS }}
  # dare to use old mediatype (application/vnd.docker.distribution.manifest.v2+json)
  outputs: oci-mediatypes=false

FluentdのDockerfileはまだそこまでできていないので、個別のアーキテクチャごとにビルドしてから、最後にDockerタグを付与しなおすということをしています。

ここまで説明した仕組みに移行することで、次のようなメリットがありました。

GitHubでタグを打つだけでデプロイが完了するので、以前のようにAutomated Buildsの管理画面で明示的にビルドしなくてもよくなった
そもそもGitタグを付与して管理されてない状態だったので、どの時点の内容でイメージがビルドされたかをトレースできるように改善された
従来、amd64とarm64のみマルチアーキテクチャ対応のDockerタグを付与していたが、今回デプロイの仕組みを整備したことで、amd64,arm64だけでなくarmhfにも対応できた

さいごに

今回は、Fluentdのコンテナイメージをタグを打つだけでデプロイできるようにした方法について概要を説明しました。今回紹介した方法は、Fluentdを含めた多種多様なdaemonsetのイメージを提供する方法としても活用しています。

クリアコードはFluentdのサポートサービスを行っています。詳しくはFluentdのサポートサービスをご覧いただき、お問い合わせフォームよりお気軽にお問い合わせください。

最新版を使ってみて何か気になる点があれば、ぜひGitHubでコミュニティーにフィードバックをお寄せください。また、日本語用Q&Aも用意しておりますので、困ったことがあればぜひ質問をお寄せください。

ククログ

Fluentdのコンテナイメージをタグを打つだけでデプロイできるようにした方法

従来のコンテナイメージのデプロイ方法

GitHub Actionsへの移行のポイント

さいごに

関連情報