developers use windows, we have a test environment running on a mac, and we will eventually run a production environment on linux droplets
This sounds fine we’ve crafted the technology to minimize the amount of infrastructure required to run in various environments so it’s as easy as possible for local development too.
I understand the recommendation for go module development is to use the docker images along with the docker build tool.
This recommendation is in general because it means you don’t need to bother to configure and setup containers with Docker Compose the environment is composed of all the containers needed and are started together.
But there’s some confusion about how to manage a production environment. Apparently the compiled shared objects for go modules are not transferable from platform to platform?
No. Like any compiled language the shared object generated by the Go toolchain is architecture specific. When you use our pluginbuilder Docker image the compiled code on the host filesystem is built for the Linux x64 architecture. You can see this with:
$> file ./your-compiled-module.so
ELF 64-bit LSB shared object x86-64, version 1 (SYSV), dynamically linked
And the recommendation for a production environment is NOT to use Docker, but to use binaries.
This has come up a couple of times recently. There’s no production recommendation not to use Docker images or to suggest that native binaries are the right way. The only strong recommendation is NOT to use Docker Compose to run your server environment.
And for windows, does the docker build tool work, or is it still the case go can’t use the plugin buildmode on windows.
The Go language and compiler toolchain does not support plugins built on Windows. This is a constraint which comes from the Go team. It may change in the future but we’d recommend against Windows for your host OS with production instances anyway.