dockerfile: removed unused DLLs from image for Windows Containers

[mabrarov]

dockerfile: removed unused DLLs from image for Windows Containers.

These changes were part of #10180, but were missed when #10180 was merged. Refer to https://github.com/fluent/fluent-bit/pull/10180/files#diff-d75427907b4a97ca122ccabc30454afd418e1a1152c474d3297d1b5c0d701d14L46-L56 - there are no more explicitly installed DLLs to copy.

Note that when Fluent Bit is built with MS Visual C++, then static linkage with C/C++ runtime is used - refer to https://github.com/fluent/fluent-bit/blob/master/CMakeLists.txt#L76 - so that removed DLLs are not needed. I copied Fluent Bit binary from built docker image and checked its dependencies with https://github.com/lucasg/Dependencies to ensure that removed DLLs are not used directly by Fluent Bit binary:

$ docker build -t fluent/fluent-bit -f dockerfiles/Dockerfile.windows . && \
container_id="$(docker create fluent/fluent-bit)" && \
flb_executable="$(mktemp --suffix .exe)" && \
docker cp "${container_id}:C:\\fluent-bit\\bin\\fluent-bit.exe" "${flb_executable}" && \
docker rm -fv "${container_id}" && \
Dependencies -modules -depth 1 "${flb_executable}" && \
rm -f "${flb_executable}"
...
Successfully copied 17.4MB to C:\Users\...\AppData\Local\Temp\tmp.75D0EaxWDN.exe
905a43715bc6b6cc365d6444b10269dc436441a965e642401827f1dc4422189c
[ROOT] tmp.75D0EaxWDN.exe : C:/Users/.../AppData/Local/Temp/tmp.75D0EaxWDN.exe
[WellKnownDlls] WS2_32.dll : C:\WINDOWS\system32\WS2_32.dll
[WellKnownDlls] CRYPT32.dll : C:\WINDOWS\system32\CRYPT32.dll
[WellKnownDlls] SHLWAPI.dll : C:\WINDOWS\system32\SHLWAPI.dll
[WellKnownDlls] SHELL32.dll : C:\WINDOWS\system32\SHELL32.dll
[WellKnownDlls] ADVAPI32.dll : C:\WINDOWS\system32\advapi32.dll
[WellKnownDlls] KERNEL32.dll : C:\WINDOWS\system32\kernel32.dll
[WellKnownDlls] USER32.dll : C:\WINDOWS\system32\user32.dll
[WellKnownDlls] ole32.dll : C:\WINDOWS\system32\ole32.dll
[WellKnownDlls] OLEAUT32.dll : C:\WINDOWS\system32\OLEAUT32.dll
[WindowsFolder] bcrypt.dll : C:\WINDOWS\system32\bcrypt.dll
[WindowsFolder] IPHLPAPI.DLL : C:\WINDOWS\system32\IPHLPAPI.DLL
[WindowsFolder] wevtapi.dll : C:\WINDOWS\system32\wevtapi.dll
[WindowsFolder] NETAPI32.dll : C:\WINDOWS\system32\NETAPI32.dll
[WindowsFolder] Secur32.dll : C:\WINDOWS\system32\Secur32.dll

$ docker run --rm --entrypoint powershell fluent/fluent-bit dir 'C:\fluent-bit\bin'


    Directory: C:\fluent-bit\bin


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/22/2025  12:25 AM       17359360 fluent-bit.exe

---

Testing

• [N/A] Example configuration file for the change
• [N/A] Debug log output from testing the change
• [N/A] Attached Valgrind output that shows no leaks or memory corruption was found
• [N/A] Run local packaging test showing all targets (including any new ones) build.
• [N/A] Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• [N/A] Documentation required for this feature

Backporting

• [N/A] Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[patrick-stephens]

Any chance we can add some basic sanity tests for the container build to confirm?

[mabrarov]

Hi @patrick-stephens,

some basic sanity tests for the container build to confirm?

Isn't .github/workflows/pr-image-tests.yaml:116-119 (https://github.com/fluent/fluent-bit/actions/runs/14580963650/job/40897379281?pr=10233) sufficient for this pull request?

Thank you.

[mabrarov]

@edsiper and @patrick-stephens,

Do you have any thoughts / requirements / doubts on this pull request? Considering this pull request was part of original #10180 which was merged by @edsiper, I find missing changes being caused by merge conflict resolution issue. It is the reason I was under impression that this PR is going to be accepted soon to avoid keeping half of original #10180 in master branch. Please note that building of docker image for Windows Server Containers in master branch doesn't fail only because we are lucky and DLLs (which copying is removed in this PR) exist in builder-base image only because of installation of Visual Studio Build Tools. Base image (mcr.microsoft.com/windows/servercore:ltsc2019) of builder-base doesn't have these DLLs - command provided below doesn't find them:

docker run --rm --entrypoint powershell mcr.microsoft.com/windows/servercore:ltsc2019 dir 'C:\Windows\System32' | grep -E -i '(msvcp140|vccorlib140|vcruntime140)\.dll' 

Thank you.

[patrick-stephens]

Hi @patrick-stephens,

some basic sanity tests for the container build to confirm?

Isn't .github/workflows/pr-image-tests.yaml:116-119 (https://github.com/fluent/fluent-bit/actions/runs/14580963650/job/40897379281?pr=10233) sufficient for this pull request?

Thank you.

Ah we did add some already then should be ok.

[patrick-stephens]

@edsiper and @patrick-stephens,

Do you have any thoughts / requirements / doubts on this pull request? Considering this pull request was part of original #10180 which was merged by @edsiper, I find missing changes being caused by merge conflict resolution issue. It is the reason I was under impression that this PR is going to be accepted soon to avoid keeping half of original #10180 in master branch. Please note that building of docker image for Windows Server Containers in master branch doesn't fail only because we are lucky and DLLs (which copying is removed in this PR) exist in builder-base image only because of installation of Visual Studio Build Tools. Base image (mcr.microsoft.com/windows/servercore:ltsc2019) of builder-base doesn't have these DLLs - command provided below doesn't find them:

docker run --rm --entrypoint powershell mcr.microsoft.com/windows/servercore:ltsc2019 dir 'C:\Windows\System32' | grep -E -i '(msvcp140|vccorlib140|vcruntime140)\.dll' 

Thank you.

Have you actually used the containers after this change is the main one? It's not clear if you have so be good to include that info. I think the change is ok, but I cannot test it myself and I just want to avoid any silly issues.

[mabrarov]

Hi @patrick-stephens,

I am not production user of Windows Server Containers, but the image built on my local environment (Windows Server 2019 VM) from this pull request seems to be running same way as (even) before #10180 when using:

docker build -t fluent/fluent-bit -f dockerfiles/Dockerfile.windows . && \
docker run --rm -it fluent/fluent-bit

Thank you.