I have recently tried to update to Nakama 2.7.0 to leverage the go 1.13 module support.
I ran into an issue after building the Golang shared object and trying to start Nakama.
I experienced the problem in a slightly bigger code base and started stripping things down until I had the smallest possible reproduction.
I got to the point where I made a new folder containing just the minimal example.
- Windows 10 64bit
- Nakama 2.7.0
- Plugin build image: heroiclabs/nakama-pluginbuilder:2.7.0
docker run --rm -v %cd%:/tempbuild -w /tempbuild heroiclabs/nakama-pluginbuilder:2.7.0 build --buildmode=plugin -trimpath -o ./modules/plugin_project.so
- Server running in standard docker-compose.yml with version 2.7.0 of Nakama
Using the 2.7.0 version of the plugin builder image I was unable to build the example out of the box. I believe this is due to commit fe4f8f0aa40aae7a5ce378f9e1a8c13f9f978433 where a few commands were removed form the build/pluginbuilder/Dockerfile Making it seemingly impossible to build without a go.mod file which brings in the necessary dependencies.
I believe it was mentioned in Gitter that the page is a bit outdated but I think mentioning the need for the go.mod with Nakama 2.7.0 and up would be very helpful.
This was resolved by running go mod init <module_name> in the root of the folder and rebuilding.
Running docker-compose up in the test folder where the docker-compose.yml is produces an output which I will attach as a file due to its size. nakama_golang_output.txt (20.3 KB)
Here is a screenshot of the folder structure, files and some of the more relevant contents. I tried to zip the folder and upload it but it is not a supported file type. Although it is just the nakama go example so I do not see how it could cause issues.
Needless to say server fails to start.
You’re right on your 1st point, Go modules built for Nakama 2.7.0 and up will require a
go.mod file. This is being documented as we speak and will appear in the readme soon. It’s part of our efforts to ensure plugin builds work as universally as possible, in both binary builds and docker.
Issue 2 is interesting, I’m not sure we’ve seen this reported so far on any platform. It looks somewhat like a memory corruption issue which can indicate a problem with your local Docker environment. Have you tried the usual steps of restarting docker, checking it’s up to date etc?
Indeed, I went through those steps restarting computer as well.
I also double checked with a couple of colleagues and if the issue was specific to my Windows machine or not. As part of my trouble shooting I ran the exact same flow / commands on Mac OS and it all worked fine there.
Bumping the mini test project down to use Nakama 2.6.0 images and removing the go.mod file makes it work.
All of this leads me to believe that there is an issue somewhere in the chain of Nakama 2.7.0, Go 1.13, Docker and Windows.
I am not ruling out the possibility that this could be an issue in the configuration of our Windows machines that somehow is influencing the Docker VM environment. In fact I believe it is quite likely. However I do not have a working Windows environment to trouble shoot and compare with.
I will keep this thread updated with any new findings.
Quick update on this.
In testing at home it was determined that using the Docker 2.7.0 images on Windows does in fact work and everything is fine.
Comparing my home setup with my work setup the main differences I can see is windows version and IT policy.
At work we are on Windows 10 1803 and at home I am on Windows 10 1903.
I can not test this theory at the moment but hopefully it helps someone. Note that this was also tested using Nakama 2.7.0 built with Go 1.13 and not Go 1.13.1.
Thanks @igeorgievsd. I think as we’ve identified together that this issue is platform and version specific on Windows. I’ll lock this thread and if any other questions come up about Go custom code builds it can be opened on a new post.
I also recommend to any developers and studios who use the Go runtime support in Nakama server to check out our updated README on it: