dockerfiles: windows: update to ltsc 2025 and fix layers#10760
dockerfiles: windows: update to ltsc 2025 and fix layers#10760
Conversation
edsiper
requested review from
celalettin1286,
niedbalski and
patrick-stephens
as code owners
WalkthroughUpdated Windows Dockerfile: bumped base image to ltsc2025, MSVS toolset to 17, hardened builder TEMP handling, replaced VS Build Tools inline install with explicit vs_buildtools.exe flow, adjusted PATH handling, split vcpkg installs with cleanup, switched builder shell to CMD, and COPY'ed built /fluent-bit artifacts into runtime. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as Developer
participant Docker as Docker Engine
participant Builder as Builder Stage (ltsc2025, MSVS 17)
participant Runtime as Runtime Stage
Dev->>Docker: docker build -f dockerfiles/Dockerfile.windows .
Docker->>Builder: run builder stage
Note right of Builder: init/clean TEMP\ndownload vs_buildtools.exe + channel file\ninstall VS Build Tools\ninstall CMake, WinFlexBison, vcpkg\nvcpkg install openssl -> cleanup\nvcpkg install libyaml -> cleanup\nbuild fluent-bit (cmd shell)
Builder-->>Docker: /fluent-bit artifacts available
Docker->>Runtime: COPY --from=builder /fluent-bit -> /fluent-bit
Note right of Runtime: add runtime DLLs (vcruntime140, msvcp140, vccorlib140)\nset ENTRYPOINT/CMD/HEALTHCHECK
Dev->>Docker: docker run image
Docker->>Runtime: container starts, fluent-bit runs
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
edsiper
force-pushed
the
dockerfiles-windows-2025
branch
from
0e64c15 to
bbd0fc2
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
dockerfiles/Dockerfile.windows (2)
154-158: Likely missing MSVC runtime DLLs (e.g., vcruntime140_1.dll/concrt140.dll); prefer copying from VC redistDepending on the toolset, VS 2022-built binaries often require vcruntime140_1.dll and sometimes concrt140.dll. Relying solely on System32 may be incomplete. Recommend copying the VC143 CRT redist set from the Build Tools installation to avoid runtime failures.
-# Copy required runtime libraries -WORKDIR /fluent-bit/bin -RUN Copy-Item -Path C:\Windows\System32\msvcp140.dll -Destination /fluent-bit/bin/; ` - Copy-Item -Path C:\Windows\System32\vccorlib140.dll -Destination /fluent-bit/bin/; ` - Copy-Item -Path C:\Windows\System32\vcruntime140.dll -Destination /fluent-bit/bin/; +# Copy required MSVC runtime libraries from the VC Redist +WORKDIR /fluent-bit/bin +RUN $vcRedist = Get-ChildItem -Path \"$env:MSVS_HOME\\VC\\Redist\\MSVC\" -Directory | Sort-Object Name -Descending | Select-Object -First 1; ` + $crtDir = Join-Path $vcRedist.FullName 'x64\\Microsoft.VC143.CRT'; ` + if (-not (Test-Path $crtDir)) { throw \"VC143 CRT dir not found under $($vcRedist.FullName)\" }; ` + Copy-Item -Path (Join-Path $crtDir '*.dll') -Destination /fluent-bit/bin/ -ForceIf you prefer keeping System32 copies, at minimum add vcruntime140_1.dll and concrt140.dll (when present) and verify runtime.
167-179: Bug: single quotes in cmd shell pass literal quotes to CMake -D valuesSHELL is cmd for this RUN. In cmd.exe, single quotes aren’t string delimiters; CMake will receive paths that include literal quotes, causing misconfiguration. Use double quotes or no quotes for these -D arguments. Also, NMake doesn’t benefit from -j; optional: switch to Ninja if you want parallel builds.
RUN call "%MSVS_HOME%\VC\Auxiliary\Build\vcvars64.bat" && ` cmake -G "NMake Makefiles" ` - -DOPENSSL_ROOT_DIR='C:\dev\vcpkg\packages\openssl_x64-windows-static' ` - -DFLB_LIBYAML_DIR='C:\dev\vcpkg\packages\libyaml_x64-windows-static' ` + -DOPENSSL_ROOT_DIR="C:\dev\vcpkg\packages\openssl_x64-windows-static" ` + -DFLB_LIBYAML_DIR="C:\dev\vcpkg\packages\libyaml_x64-windows-static" ` -DFLB_SIMD=On ` -DCMAKE_BUILD_TYPE=Release ` -DFLB_SHARED_LIB=Off ` -DFLB_EXAMPLES=Off ` -DFLB_DEBUG=Off ` -DFLB_RELEASE=On ` ..\ && ` - cmake --build . --config Release -j "%BUILD_PARALLEL%" + cmake --build . --config ReleaseOptional (parallel builds): add Ninja and use it as generator:
- cmake -G "NMake Makefiles" ` + cmake -G "Ninja" ` @@ - cmake --build . --config Release + cmake --build . --config Release -j "%BUILD_PARALLEL%"And ensure ninja.exe is on PATH (from CMake bin if available, or install separately).
🧹 Nitpick comments (5)
dockerfiles/Dockerfile.windows (5)
26-26: Outdated comment still mentions ltsc2022 requirementThe comment references “requires WINDOWS_VERSION=ltsc2022” but we’re now on ltsc2025. Please update to avoid confusion.
-# Install Visual Studio Build Tools 2019 (MSVS_VERSION=16) / 2022 (MSVS_VERSION=17, requires WINDOWS_VERSION=ltsc2022) +# Install Visual Studio Build Tools 2019 (MSVS_VERSION=16) / 2022 (MSVS_VERSION=17, requires recent Windows Server Core e.g. ltsc2022+ / ltsc2025)
33-52: VS Build Tools installer flow improved; consider checksum verification and optional SDK componentThe Start-Process based flow is clean. Two optional follow-ups:
- Add SHA256 verification for vs_buildtools.exe/channel to reduce supply-chain risk.
- If you run into missing headers/libs, add a Windows SDK component, e.g. Microsoft.VisualStudio.Component.Windows10SDK.20348 (or current), though many builds won’t require it.
RUN $msvs_build_tools_dist_name=\"vs_buildtools.exe\"; ` @@ - Invoke-WebRequest -OutFile \"${msvs_build_tools_dist}\" \"${msvs_build_tools_dist_url}\"; ` - Invoke-WebRequest -OutFile \"${msvs_build_tools_channel}\" \"${msvs_build_tools_channel_url}\"; ` + Invoke-WebRequest -OutFile \"${msvs_build_tools_dist}\" \"${msvs_build_tools_dist_url}\"; ` + Invoke-WebRequest -OutFile \"${msvs_build_tools_channel}\" \"${msvs_build_tools_channel_url}\"; ` + # OPTIONAL: checksum verification (example placeholder variables) + # $expectedHash = 'SHA256_HEX_HERE' + # if ((Get-FileHash -Path \"$msvs_build_tools_dist\" -Algorithm SHA256).Hash -ne $expectedHash) { throw \"VS BuildTools checksum mismatch\" } @@ '--add Microsoft.VisualStudio.Workload.VCTools', ` + # OPTIONAL: add SDK if needed + # '--add Microsoft.VisualStudio.Component.Windows10SDK.20348', '--includeRecommended' -NoNewWindow -Wait; `
90-111: WinFlexBison extraction path may differ; make copy robustDepending on the zip layout, win_bison.exe/win_flex.exe may land under a versioned subfolder. Current Copy-Item paths assume flat extraction. Make it robust by resolving the files recursively.
- Expand-Archive \"${win_flex_bison_dist}\" -Destination \"${env:WIN_FLEX_BISON_HOME}\"; ` - Remove-Item -Force \"${win_flex_bison_dist}\"; ` - Write-Host \"Copying...\"; ` - Write-Host \"${env:WIN_FLEX_BISON_HOME}\win_bison.exe -> ${env:WIN_FLEX_BISON_HOME}\bison.exe\"; ` - Copy-Item -Path \"${env:WIN_FLEX_BISON_HOME}\win_bison.exe\" \"${env:WIN_FLEX_BISON_HOME}\bison.exe\"; ` - Write-Host \"Copying...\"; ` - Write-Host \"${env:WIN_FLEX_BISON_HOME}\win_flex.exe -> ${env:WIN_FLEX_BISON_HOME}\flex.exe\"; ` - Copy-Item -Path \"${env:WIN_FLEX_BISON_HOME}\win_flex.exe\" \"${env:WIN_FLEX_BISON_HOME}\flex.exe\"; ` + Expand-Archive \"${win_flex_bison_dist}\" -Destination \"${env:WIN_FLEX_BISON_HOME}\"; ` + Remove-Item -Force \"${win_flex_bison_dist}\"; ` + $wb = Get-ChildItem -Path \"${env:WIN_FLEX_BISON_HOME}\" -Recurse -Filter win_bison.exe | Select-Object -First 1; ` + $wf = Get-ChildItem -Path \"${env:WIN_FLEX_BISON_HOME}\" -Recurse -Filter win_flex.exe | Select-Object -First 1; ` + if (-not $wb -or -not $wf) { throw \"win_flex_bison executables not found after extraction\" }; ` + Copy-Item -Path $wb.FullName \"${env:WIN_FLEX_BISON_HOME}\bison.exe\" -Force; ` + Copy-Item -Path $wf.FullName \"${env:WIN_FLEX_BISON_HOME}\flex.exe\" -Force; `
183-194: Idempotency nit: add -Force when creating etc directoryMinor: New-Item can be made idempotent with -Force to avoid failing if the dir exists.
-RUN New-Item -Path /fluent-bit/etc/ -ItemType "directory"; ` +RUN New-Item -Path /fluent-bit/etc/ -ItemType "directory" -Force; `
222-222: Prefer ENV PATH over setx for deterministic runtime PATHsetx writes to the registry and won’t affect the current layer; it usually works at runtime, but ENV is simpler and more deterministic for containers.
-RUN setx /M PATH "%PATH%;C:\fluent-bit\bin" +ENV PATH="%PATH%;C:\fluent-bit\bin"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
dockerfiles/Dockerfile.windows(6 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 64bit, x64, x64-windows-static, 3.31.6)
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 64bit (Arm64), amd64_arm64, -DCMAKE_SYSTEM_NAME=Windows -DCMA...
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 32bit, x86, x86-windows-static, 3.31.6)
- GitHub Check: PR - Buildkit docker build test
- GitHub Check: PR - Docker windows build test, windows 2022 and 2025 (2022)
- GitHub Check: PR - Docker windows build test, windows 2022 and 2025 (2025)
- GitHub Check: PR - Classic docker build test
🔇 Additional comments (7)
dockerfiles/Dockerfile.windows (7)
14-14: Bump to ltsc2025: looks good; confirm availability on all target runnersWindows Server Core ltsc2025 base is appropriate for VS 2022 toolset. Please confirm your CI and downstream environments can pull ltsc2025 images (host OS/cluster compatibility).
21-24: Temp cleanup hardening: LGTMProactive cleanup and re-create of TEMP locations reduces layer bloat and flaky downloads.
28-28: MSVS_VERSION=17 target: LGTMVS Build Tools 2022 is the right target for ltsc2025.
58-85: CMake download/install: LGTMVersioned download with PATH export is correct. The naming fallback logic covers historical packages.
136-139: vcpkg PATH and bootstrap: LGTMPATH update and bootstrap invocation are correct, targeting the extracted root.
147-153: Split vcpkg installs with cleanup: LGTMThis reduces layer size and avoids keeping build trees longer than needed.
219-220: Explicit artifact copy from builder: LGTMThis keeps the runtime lean and decoupled from build tooling.
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
edsiper
force-pushed
the
dockerfiles-windows-2025
branch
from
bbd0fc2 to
c7c66c3
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
dockerfiles/Dockerfile.windows (2)
175-189: Fix CMake -D path quoting (single quotes break on Windows CMD) and parallel build invocation for NMakeOn Windows CMD, single quotes are literal and will be passed to CMake, making the paths invalid. Also, NMake doesn’t support -j; prefer CMAKE_BUILD_PARALLEL_LEVEL or omit parallel flag.
-SHELL ["cmd", "/S", "/C"] -RUN call "%MSVS_HOME%\VC\Auxiliary\Build\vcvars64.bat" && ` - cmake -G "NMake Makefiles" ` - -DOPENSSL_ROOT_DIR='C:\dev\vcpkg\packages\openssl_x64-windows-static' ` - -DFLB_LIBYAML_DIR='C:\dev\vcpkg\packages\libyaml_x64-windows-static' ` +SHELL ["cmd", "/S", "/C"] +RUN call "%MSVS_HOME%\VC\Auxiliary\Build\vcvars64.bat" && ` + cmake -G "NMake Makefiles" ` + -DOPENSSL_ROOT_DIR="C:\dev\vcpkg\packages\openssl_x64-windows-static" ` + -DFLB_LIBYAML_DIR="C:\dev\vcpkg\packages\libyaml_x64-windows-static" ` -DFLB_SIMD=On ` -DCMAKE_BUILD_TYPE=Release ` -DFLB_SHARED_LIB=Off ` -DFLB_EXAMPLES=Off ` -DFLB_DEBUG=Off ` -DFLB_RELEASE=On ` ..\ && ` - cmake --build . --config Release -j "%BUILD_PARALLEL%" + set CMAKE_BUILD_PARALLEL_LEVEL=%BUILD_PARALLEL% && cmake --build . --config ReleaseIf you prefer Ninja, switching the generator to Ninja would make -j effective and speed up builds.
163-168: Include VC143 CRT from VS Build Tools Redist Instead of System32Copying the VC runtime DLLs directly from C:\Windows\System32 can break on Windows Server Core images, as those CRTs often aren’t present. Since you already install the Visual Studio Build Tools into MSVS_HOME (C:\BuildTools), pull the latest CRTs from the corresponding Redist folder under that path and include both “_1” variants:
• File: dockerfiles/Dockerfile.windows
Lines: 163–168Proposed change:
-WORKDIR /fluent-bit/bin -RUN Copy-Item -Path C:\Windows\System32\msvcp140.dll -Destination /fluent-bit/bin/; ` - Copy-Item -Path C:\Windows\System32\vccorlib140.dll -Destination /fluent-bit/bin/; ` - Copy-Item -Path C:\Windows\System32\vcruntime140.dll -Destination /fluent-bit/bin/; +WORKDIR /fluent-bit/bin +RUN $redistRoot = Join-Path $env:MSVS_HOME 'VC\Redist\MSVC'; ` + $latest = Get-ChildItem $redistRoot -Directory | Sort-Object Name -Descending | Select-Object -First 1; ` + $crtDir = Join-Path $latest.FullName 'x64\Microsoft.VC143.CRT'; ` + Copy-Item (Join-Path $crtDir 'vcruntime140.dll') -Destination /fluent-bit/bin/ -Force; ` + Copy-Item (Join-Path $crtDir 'vcruntime140_1.dll') -Destination /fluent-bit/bin/ -Force; ` + Copy-Item (Join-Path $crtDir 'msvcp140.dll') -Destination /fluent-bit/bin/ -Force; ` + Copy-Item (Join-Path $crtDir 'msvcp140_1.dll') -Destination /fluent-bit/bin/ -Force; ` + if (Test-Path (Join-Path $crtDir 'concrt140.dll')) { ` + Copy-Item (Join-Path $crtDir 'concrt140.dll') -Destination /fluent-bit/bin/ -Force ` + }If you intentionally prefer System32, please confirm that all required DLLs exist in your chosen ltsc2025 base image.
🧹 Nitpick comments (4)
dockerfiles/Dockerfile.windows (4)
26-32: Update the inline comment to reflect 2025 supportThe comment still references “requires WINDOWS_VERSION=ltsc2022”; since this Dockerfile defaults to ltsc2025 now, update the note to avoid confusion.
-# Install Visual Studio Build Tools 2019 (MSVS_VERSION=16) / 2022 (MSVS_VERSION=17, requires WINDOWS_VERSION=ltsc2022) +# Install Visual Studio Build Tools 2019 (MSVS_VERSION=16) / 2022 (MSVS_VERSION=17, requires Windows Server Core with VC toolset support; tested on ltsc2025)
33-52: VS Build Tools: ensure Windows SDK is installed (headers/libs) for native buildInstalling only
Microsoft.VisualStudio.Workload.VCToolscan omit the Windows SDK headers/libs needed by MSVC. Recommend pinning a Windows SDK component to avoid build/link failures on fresh images.- '--add Microsoft.VisualStudio.Workload.VCTools', ` - '--includeRecommended' -NoNewWindow -Wait; ` + '--add Microsoft.VisualStudio.Workload.VCTools', ` + '--add Microsoft.VisualStudio.Component.Windows11SDK.22621', ` + '--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64', ` + '--includeRecommended' -NoNewWindow -Wait; `Notes:
- If you target another SDK, switch the component ID accordingly (e.g., Windows10SDK.19041).
- Keeping VC.Tools explicit reduces surprises between channel updates.
33-43: Add basic integrity checks for downloaded installers (defense-in-depth)Given you download
vs_buildtools.exe, channel file, CMake, WinFlexBison, and vcpkg over the network, consider verifying SHA256 (or signature) to reduce supply-chain risk.Example sketch (PowerShell):
# After download $expectedSha256 = '<fill_from_release_checksums>' $actual = (Get-FileHash $msvs_build_tools_dist -Algorithm SHA256).Hash if ($actual -ne $expectedSha256) { throw "SHA256 mismatch for vs_buildtools.exe" }If adding full hash verification is out of scope for this PR, capturing the expected hashes in comments is still helpful for future hardening.
231-236: Avoid PATH mutation via setx (risk of truncation); use absolute ENTRYPOINT insteadsetx truncates values around 1024 chars and modifies machine env in a way that can be brittle. Since you always know the binary path, prefer a fully-qualified ENTRYPOINT and drop PATH edits.
-RUN setx /M PATH "%PATH%;C:\fluent-bit\bin" - -ENTRYPOINT [ "fluent-bit.exe" ] +ENTRYPOINT [ "C:\\fluent-bit\\bin\\fluent-bit.exe" ] # Hadolint gets confused by Windows it seems # hadolint ignore=DL3025 -CMD [ "fluent-bit.exe", "-c", "/fluent-bit/etc/fluent-bit.conf" ] +CMD [ "C:\\fluent-bit\\bin\\fluent-bit.exe", "-c", "C:\\fluent-bit\\etc\\fluent-bit.conf" ]Alternative: use
ENV PATH=C:\fluent-bit\bin;%PATH%(but be aware of expansion nuances on Windows).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
dockerfiles/Dockerfile.windows(6 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 32bit, x86, x86-windows-static, 3.31.6)
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 64bit, x64, x64-windows-static, 3.31.6)
- GitHub Check: pr-windows-build / call-build-windows-package (Windows 64bit (Arm64), amd64_arm64, -DCMAKE_SYSTEM_NAME=Windows -DCMA...
- GitHub Check: PR - Docker windows build test, windows 2022 and 2025 (2022)
- GitHub Check: PR - Docker windows build test, windows 2022 and 2025 (2025)
- GitHub Check: PR - Buildkit docker build test
- GitHub Check: PR - Classic docker build test
🔇 Additional comments (9)
dockerfiles/Dockerfile.windows (9)
14-14: Confirm availability/host compatibility for ltsc2025Please ensure your CI/builders run on a Windows host that supports Windows Server Core ltsc2025 containers. Otherwise builds will fail to pull/run this base image.
Suggested local checks:
- docker manifest inspect mcr.microsoft.com/windows/servercore:ltsc2025
- docker buildx imagetools inspect mcr.microsoft.com/windows/servercore:ltsc2025
21-24: Temp directory hygiene looks goodPre-emptive cleanup of $env:TEMP and C:\Windows\Temp is reasonable with SilentlyContinue to avoid noisy failures.
58-85: CMake installation and PATH propagation look correctVersion detection, extraction, move, and PATH update are all sound.
90-111: WinFlexBison install and PATH update LGTMUnzipping to a fixed HOME, renaming binaries, and persistently updating PATH is clear and maintainable.
136-141: vcpkg bootstrap and PATH setup are appropriateUsing a stable tag and bootstrapping via .bat is the right approach on Windows.
147-152: Split vcpkg install + cleanup is a good space saverInstalling OpenSSL first, then cleaning buildtrees/download tools reduces layer size.
153-161: Second vcpkg install + final cleanup looks goodIncremental installs with aggressive cleanup will help keep the image lean.
192-203: Staging of configs and binary is clear and containedCreating a self-contained /fluent-bit hierarchy simplifies the final COPY. Looks good.
228-229: COPYing built artifacts from builder stage is correct and keeps runtime leanThis aligns with multi-stage best practices.
| Write-Host \"${env:WIN_FLEX_BISON_HOME}\win_flex.exe -> ${env:WIN_FLEX_BISON_HOME}\flex.exe\"; ` | ||
| Copy-Item -Path \"${env:WIN_FLEX_BISON_HOME}\win_flex.exe\" \"${env:WIN_FLEX_BISON_HOME}\flex.exe\"; ` | ||
| $env:PATH=\"${env:PATH}${env:WIN_FLEX_BISON_HOME}\"; ` | ||
| $env:PATH=\"${env:PATH};${env:WIN_FLEX_BISON_HOME}\"; ` |
There was a problem hiding this comment.
This change seems excessive (somehow PowerShell / Windows adds semicolon itself) - refer to https://github.com/fluent/fluent-bit/actions/runs/17102182820/job/48501497495 (PATH has ...;;...) :
Setting PATH... C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\cmake\bin;;C:\WinFlexBison
2 participants
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.
Summary by CodeRabbit
New Features
Chores