Multi-platform image

[jdongo-aneo]

Is your feature request related to a problem? Please describe.
When dynamically deploy fluentbit on a system that I don't know in advanced, It is challenging to manage the tags for windows (windows-2022-3.1.9) and linux based systems (3.1.9) to satisfy this requirements.

Describe the solution you'd like
A simple solution, which is not difficult to build is the use of multi-platform images. For exemple, the 3.1.9 can be used for a multi-plateform image combining linux and windows based images. using this tag, docker will pull the correct version for the running system.

[patrick-stephens]

Hmm, I'd argue it is quite difficult to build a multi-platform image efficiently :)

Yes you could just do it with the build-push-action but that brings a whole load of extra time to build each target and failure cases (if any of the pushes fail you have to restart the whole build job again). I'm not sure that's even possible on a single runner, it likely needs dedicated runners for each platform. Therefore you have to fall back to building the "hard way", i.e. build+push an image by digest then construct a manifest of the digests.

If we can combine the various images into a single multi-platform manifest in the same way we do now for Linux architectures that would probably be ideal. It might take a bit longer though - the Windows images always take an age to build - so we likely only want to do on release or push to master. It might be better to take the digests we currently have and just use them directly in a new top-level manifest.

We may have to be careful with support for the existing images: I'd be wary of existing registries/mirroring/etc. coping with Windows images in the previously Linux-only manifest. In a similar way to attestation breaking old registries too.

[jdongo-aneo]

Thanks for your response. Looking at the size of the 2 images, for sure, windows will delay the building.

If we can combine the various images into a single multi-platform manifest in the same way we do now for Linux architectures that would probably be ideal

I agree with this approach. That's what we are currently doing and pushing the image to a private ecr, but it would be better if done directly in fluent-bit repo.
docker buildx imagetools create ${local.fluent_bit_repository_uri}:${local.fluent_bit_image_tag} --tag ${local.fluent_bit_repository_uri}:${local.fluent_bit_image_tag} --append ${var.fluent_bit.image_name}:windows-2022-${local.fluent_bit_image_tag}