-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Kubernetes Go binaries in Nanoserver Images #72
Comments
CC: @craiglpeters @pjh |
@weijuans-msft for what is/isn't included in nano |
This issue has been open for 30 days with no updates. |
2 similar comments
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
https://techcommunity.microsoft.com/t5/containers/what-s-new-for-windows-containers-on-windows-server-2022/ba-p/2167036 came out. Is netapi32.dll going to be a part of that? |
@jeremyje No, we didn't make any changes in the Nanoserver for Windows Server 2022 release. What are you use cases? If you are comfortable to share publicly, please email us at [email protected]. It'll be helpful to understand the use case so we can prioritize. Is this the file all you need to be added to Nanoserver container to enable the scenario here? /Windows/System32/netapi32.dll |
For Microsoft folks, internally I have created this scenario in Azure DevOps to track: 32512068. |
And this Microsoft internal tracking deliverable in ADO #32788516. |
FWIW I just ran into this as well; Sonobuoy is working on supporting Windows nodes in K8s and I initially tried nanoserver and ran into the same missing DLL. That's the only one I know causes a problem but I haven't messed with trying to add that DLL back into the image or anything. Easiest fix for us is just to use servercore instead, not sure if you have another recommendation. |
This issue has been open for 30 days with no updates. |
1 similar comment
This issue has been open for 30 days with no updates. |
We have it in our internal backlog and will evaluate with other similar related asks and prioritize. |
This issue has been open for 30 days with no updates. |
To fix the following failure: ``` panic: Failed to load netapi32.dll: The specified module could not be found. goroutine 1 [running]: syscall.(*LazyProc).mustFind(...) c:/go/src/syscall/dll_windows.go:320 syscall.(*LazyProc).Addr(...) c:/go/src/syscall/dll_windows.go:327 syscall.NetGetJoinInformation(0x0, 0xc00061fa48, 0xc00061fa44, 0x16, 0xc0000c96e0) c:/go/src/syscall/zsyscall_windows.go:1804 +0x107 os/user.isDomainJoined(0xc00061faa0, 0xf3624e, 0x0) c:/go/src/os/user/lookup_windows.go:18 +0x5a os/user.lookupFullName(0xc000063b30, 0xc, 0xc000259bc0, 0x16, 0xc0000c96e0, 0x23, 0x16, 0xc0000c96e0, 0x23, 0x1) c:/go/src/os/user/lookup_windows.go:51 +0x2d os/user.newUser(0xc000063ad0, 0xc, 0xc000063b10, 0xc, 0xc0000c9680, 0x1f, 0xc000259bc0, 0x16, 0xc000063b30, 0xc, ...) c:/go/src/os/user/lookup_windows.go:181 +0xd4 os/user.current(0x0, 0x0, 0x0) c:/go/src/os/user/lookup_windows.go:225 +0x2d8 os/user.Current.func1() c:/go/src/os/user/lookup.go:15 +0x29 sync.(*Once).doSlow(0x593ff00, 0x40b75b0) c:/go/src/sync/once.go:66 +0xf7 sync.(*Once).Do(...) c:/go/src/sync/once.go:57 os/user.Current(0xc0002599c0, 0x1b, 0x3f56005) c:/go/src/os/user/lookup.go:15 +0x105 github.com/golang/glog.init.1() C:/gomodcache/github.com/golang/[email protected]/gomodcache/github.com/golang/[email protected]/glog_file.go:63 +0x4b ``` This ugly hack is needed because the [bump of github.com/dgraph-io/ristretto from 0.0.3 to 0.1.0][1] [introduced a new dependency to `glog`][2] which is triggering the following issue with the Windows nano docker image: [3] Once [3] is solved, this hack can be reverted. [1] #8500 [2] hypermodeinc/ristretto#263 [3] microsoft/Windows-Containers#72
To fix the following failure: ``` panic: Failed to load netapi32.dll: The specified module could not be found. goroutine 1 [running]: syscall.(*LazyProc).mustFind(...) c:/go/src/syscall/dll_windows.go:320 syscall.(*LazyProc).Addr(...) c:/go/src/syscall/dll_windows.go:327 syscall.NetGetJoinInformation(0x0, 0xc00061fa48, 0xc00061fa44, 0x16, 0xc0000c96e0) c:/go/src/syscall/zsyscall_windows.go:1804 +0x107 os/user.isDomainJoined(0xc00061faa0, 0xf3624e, 0x0) c:/go/src/os/user/lookup_windows.go:18 +0x5a os/user.lookupFullName(0xc000063b30, 0xc, 0xc000259bc0, 0x16, 0xc0000c96e0, 0x23, 0x16, 0xc0000c96e0, 0x23, 0x1) c:/go/src/os/user/lookup_windows.go:51 +0x2d os/user.newUser(0xc000063ad0, 0xc, 0xc000063b10, 0xc, 0xc0000c9680, 0x1f, 0xc000259bc0, 0x16, 0xc000063b30, 0xc, ...) c:/go/src/os/user/lookup_windows.go:181 +0xd4 os/user.current(0x0, 0x0, 0x0) c:/go/src/os/user/lookup_windows.go:225 +0x2d8 os/user.Current.func1() c:/go/src/os/user/lookup.go:15 +0x29 sync.(*Once).doSlow(0x593ff00, 0x40b75b0) c:/go/src/sync/once.go:66 +0xf7 sync.(*Once).Do(...) c:/go/src/sync/once.go:57 os/user.Current(0xc0002599c0, 0x1b, 0x3f56005) c:/go/src/os/user/lookup.go:15 +0x105 github.com/golang/glog.init.1() C:/gomodcache/github.com/golang/[email protected]/gomodcache/github.com/golang/[email protected]/glog_file.go:63 +0x4b ``` This ugly hack is needed because the [bump of github.com/dgraph-io/ristretto from 0.0.3 to 0.1.0][1] [introduced a new dependency to `glog`][2] which is triggering the following issue with the Windows nano docker image: [3] Once [3] is solved, this hack can be reverted. [1] #8500 [2] hypermodeinc/ristretto#263 [3] microsoft/Windows-Containers#72
…#9006) To fix the following failure: ``` panic: Failed to load netapi32.dll: The specified module could not be found. goroutine 1 [running]: syscall.(*LazyProc).mustFind(...) c:/go/src/syscall/dll_windows.go:320 syscall.(*LazyProc).Addr(...) c:/go/src/syscall/dll_windows.go:327 syscall.NetGetJoinInformation(0x0, 0xc00061fa48, 0xc00061fa44, 0x16, 0xc0000c96e0) c:/go/src/syscall/zsyscall_windows.go:1804 +0x107 os/user.isDomainJoined(0xc00061faa0, 0xf3624e, 0x0) c:/go/src/os/user/lookup_windows.go:18 +0x5a os/user.lookupFullName(0xc000063b30, 0xc, 0xc000259bc0, 0x16, 0xc0000c96e0, 0x23, 0x16, 0xc0000c96e0, 0x23, 0x1) c:/go/src/os/user/lookup_windows.go:51 +0x2d os/user.newUser(0xc000063ad0, 0xc, 0xc000063b10, 0xc, 0xc0000c9680, 0x1f, 0xc000259bc0, 0x16, 0xc000063b30, 0xc, ...) c:/go/src/os/user/lookup_windows.go:181 +0xd4 os/user.current(0x0, 0x0, 0x0) c:/go/src/os/user/lookup_windows.go:225 +0x2d8 os/user.Current.func1() c:/go/src/os/user/lookup.go:15 +0x29 sync.(*Once).doSlow(0x593ff00, 0x40b75b0) c:/go/src/sync/once.go:66 +0xf7 sync.(*Once).Do(...) c:/go/src/sync/once.go:57 os/user.Current(0xc0002599c0, 0x1b, 0x3f56005) c:/go/src/os/user/lookup.go:15 +0x105 github.com/golang/glog.init.1() C:/gomodcache/github.com/golang/[email protected]/gomodcache/github.com/golang/[email protected]/glog_file.go:63 +0x4b ``` This ugly hack is needed because the [bump of github.com/dgraph-io/ristretto from 0.0.3 to 0.1.0][1] [introduced a new dependency to `glog`][2] which is triggering the following issue with the Windows nano docker image: [3] Once [3] is solved, this hack can be reverted. [1] #8500 [2] hypermodeinc/ristretto#263 [3] microsoft/Windows-Containers#72
…#9006) To fix the following failure: ``` panic: Failed to load netapi32.dll: The specified module could not be found. goroutine 1 [running]: syscall.(*LazyProc).mustFind(...) c:/go/src/syscall/dll_windows.go:320 syscall.(*LazyProc).Addr(...) c:/go/src/syscall/dll_windows.go:327 syscall.NetGetJoinInformation(0x0, 0xc00061fa48, 0xc00061fa44, 0x16, 0xc0000c96e0) c:/go/src/syscall/zsyscall_windows.go:1804 +0x107 os/user.isDomainJoined(0xc00061faa0, 0xf3624e, 0x0) c:/go/src/os/user/lookup_windows.go:18 +0x5a os/user.lookupFullName(0xc000063b30, 0xc, 0xc000259bc0, 0x16, 0xc0000c96e0, 0x23, 0x16, 0xc0000c96e0, 0x23, 0x1) c:/go/src/os/user/lookup_windows.go:51 +0x2d os/user.newUser(0xc000063ad0, 0xc, 0xc000063b10, 0xc, 0xc0000c9680, 0x1f, 0xc000259bc0, 0x16, 0xc000063b30, 0xc, ...) c:/go/src/os/user/lookup_windows.go:181 +0xd4 os/user.current(0x0, 0x0, 0x0) c:/go/src/os/user/lookup_windows.go:225 +0x2d8 os/user.Current.func1() c:/go/src/os/user/lookup.go:15 +0x29 sync.(*Once).doSlow(0x593ff00, 0x40b75b0) c:/go/src/sync/once.go:66 +0xf7 sync.(*Once).Do(...) c:/go/src/sync/once.go:57 os/user.Current(0xc0002599c0, 0x1b, 0x3f56005) c:/go/src/os/user/lookup.go:15 +0x105 github.com/golang/glog.init.1() C:/gomodcache/github.com/golang/[email protected]/gomodcache/github.com/golang/[email protected]/glog_file.go:63 +0x4b ``` This ugly hack is needed because the [bump of github.com/dgraph-io/ristretto from 0.0.3 to 0.1.0][1] [introduced a new dependency to `glog`][2] which is triggering the following issue with the Windows nano docker image: [3] Once [3] is solved, this hack can be reverted. [1] #8500 [2] hypermodeinc/ristretto#263 [3] microsoft/Windows-Containers#72
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
There is quite a lot of GUI-less software servers that require the Network Management API, for example licencing servers like Gemalto's, and it would be very helpful if such serves run on nanoserver. Those run on servercore containers fine, but it is hard to justify the extra 1 GB of container size. |
Any update on this issue? |
Our engineer is getting close to finish the code change. Next need to test, and also figure out a shipping vehicle. Curious what OS are folks using? Windows Server 2019? Windows Server 2022? Our current engineering process is we will first make the change in the active branch which is Windows Server vNext (general Insider builds are out; we are working on getting the container Insider builds out too). Will folks to be interested in testing with Windows Server vNext? @jterry75 @mloskot @jeremyje |
2019, but if Windows Server 2022 release delivers NanoServer improvements, then switching to 2022 is not a problem at all.
Yes, I am interested to test any new container images of NanoServer to see if they can run my software, if I can switch over from ServerCore. |
From the ABI stability support announced with Server 2022, as I recall, for process isolation a Server vNext container image will need a Server vNext host, but a Server 2022 container image will work on both 2022 and vNext hosts (and Windows 11). Is that accurate? |
@mloskot Windows Server 2022 GA'ed last Sept hence any changes to that will be released with the shipping vehicle of the monthly patches (usually the 2nd Tue of the month). In another word, currently there is no major improvement in Nano server of the Server 2022 release. But we are and will be doing more on Windows Server vNext, and if those work out, we'll back port to Server 2022. Yeah, that takes a bit time. If I had a magic wand, I would love to make it faster. Great to see the interest in Windows Server vNext Insider builds. Curious how you usually use it? Basically I could use more adoption data of the Insider builds to convince my team to prioritize this :). @TBBle Good observation! You are right, Windows Server 2022 container images will be the first that can be run on a host OS at the same version or higher version as a process isolated container. That is the host will need to be Server 2022 or higher. |
@weijuans-msft - We are also on WS2019 and WS2022 for prod (no vNext), but we could certainly test on vNext to support the changes and provide feedback. |
This issue has been open for 30 days with no updates. |
1 similar comment
This issue has been open for 30 days with no updates. |
(Don't close this yet.) |
This issue has been open for 30 days with no updates. |
…DataDog#9006) To fix the following failure: ``` panic: Failed to load netapi32.dll: The specified module could not be found. goroutine 1 [running]: syscall.(*LazyProc).mustFind(...) c:/go/src/syscall/dll_windows.go:320 syscall.(*LazyProc).Addr(...) c:/go/src/syscall/dll_windows.go:327 syscall.NetGetJoinInformation(0x0, 0xc00061fa48, 0xc00061fa44, 0x16, 0xc0000c96e0) c:/go/src/syscall/zsyscall_windows.go:1804 +0x107 os/user.isDomainJoined(0xc00061faa0, 0xf3624e, 0x0) c:/go/src/os/user/lookup_windows.go:18 +0x5a os/user.lookupFullName(0xc000063b30, 0xc, 0xc000259bc0, 0x16, 0xc0000c96e0, 0x23, 0x16, 0xc0000c96e0, 0x23, 0x1) c:/go/src/os/user/lookup_windows.go:51 +0x2d os/user.newUser(0xc000063ad0, 0xc, 0xc000063b10, 0xc, 0xc0000c9680, 0x1f, 0xc000259bc0, 0x16, 0xc000063b30, 0xc, ...) c:/go/src/os/user/lookup_windows.go:181 +0xd4 os/user.current(0x0, 0x0, 0x0) c:/go/src/os/user/lookup_windows.go:225 +0x2d8 os/user.Current.func1() c:/go/src/os/user/lookup.go:15 +0x29 sync.(*Once).doSlow(0x593ff00, 0x40b75b0) c:/go/src/sync/once.go:66 +0xf7 sync.(*Once).Do(...) c:/go/src/sync/once.go:57 os/user.Current(0xc0002599c0, 0x1b, 0x3f56005) c:/go/src/os/user/lookup.go:15 +0x105 github.com/golang/glog.init.1() C:/gomodcache/github.com/golang/[email protected]/gomodcache/github.com/golang/[email protected]/glog_file.go:63 +0x4b ``` This ugly hack is needed because the [bump of github.com/dgraph-io/ristretto from 0.0.3 to 0.1.0][1] [introduced a new dependency to `glog`][2] which is triggering the following issue with the Windows nano docker image: [3] Once [3] is solved, this hack can be reverted. [1] DataDog#8500 [2] hypermodeinc/ristretto#263 [3] microsoft/Windows-Containers#72
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
Bump |
This issue has been open for 30 days with no updates. |
1 similar comment
This issue has been open for 30 days with no updates. |
Please, don't close and instead, please, make NanoServer go for Go! |
This is in our backlog and will be considered a feature item for the next major release for Windows Server Containers. Unfortunately, I don't have a timeline to share at this time. |
Is it reasonable to equate "next major release for Windows Server Containers" with "next Windows Server LTSC"? I recognise that this isn't committed for that next major release, just wondering if there's a distinct release cadence for Windows Server Containers vs Windows Server. |
You're right. Windows Server Container releases are aligned to the Windows Server release cadence. |
Go is a statically linked language but for OS specific logic there's the need to occasionally use CGO. Kubernetes binaries tends to have a dependency on netapi32.dll specifically for lookup_windows.go in os.User function. There's logic to query Active Directory user information. For more context see golang/go#21867. It appears that the DLL was removed in Windows Server 1709.
It'd be nice if Windows Nanoserver images had the necessary support to run most Kubernetes binaries without doing the netapi32.dll copy trick. There are probably other dependencies that Kubernetes for Windows needs but this appears to be the most significant.
I think it would also be useful to understand what is and is not included in Windows Nanoserver images. Some of this information used to be documented at https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/mt588480(v=vs.85).
A nondisruptive option might be to introduce a Nanoserver variant that includes the DLLs necessary to run Go binaries with http://golang.org/x/sys/windows linked in and offer it here, https://hub.docker.com/publishers/microsoftowner.
The text was updated successfully, but these errors were encountered: