在Windows Server 2008上部署Go Web项目

Question

My project: go - 1.12.5; gin-gonic; vue-cli - 3.8.2.

On windows server 2008 go under the local account, run main.exe - works well. But when log off my account, all local account programs are closed, including my go server.

The first thing I did was try to configure IIS for my GO. Nothing good came of it.

Then I tried to run main.exe from the SYSTEM account psexec -s c:afd\main.exe. When log off the process does not close. But the frontend is in my account and SYSTEM does not see the local files (js, html, css) of my project

Tell me how to start the Go server, to after log off my project did not stop life

Answer 1

Two ways to approach it.

1. Go with ISS (or another web server).

   Should you pick this option, you have further choices:

   • Leave your project's code as is, but

     • Make sure it's able to be told which socket to listen for connections on—so that you can tell it to listen, say, on localhost:8080. For instance, teach your program to accept a command-line parameter for that—such as -listen or whatever.
     • Configure IIS in a way so that it reverse-proxies incoming HTTP requests on a certain virtual host and/or path prefix to a running instance of your server. You'll have to make the IIS configuration—the socket it proxies the requests to—and the way IIS starts your program agree with each other.

   • Rework the code to use FastCGI protocol instead. This basically amounts to using net/fastcgi instead of net/http.

     The upside is that IIS (even its dirt-old versions) support FastCGI out of the box. The downsides are that FastCGI is beleived to be slightly slower than plain HTTP in Go, and that you'll lose the ability to run your program in the standalone mode.

2. Turn your program into a proper Windows™ service or "wrap" it with some helper tool to make it a Windows™ service.

   The former is cleaner as it allows your program to actually be aware of control requests the Windows Service Management subsystem would send to you. You could also easily turn your program into a shrink-wrapped product, if/when needed. You could start with golang.org/x/sys/windows/svc.

   The latter may be a bit easier, but YMMV. If you'd like to explore this way, look for tools like srvany, nssm, winsv etc.

   Note that of these, only srvany is provided by Microsoft® and, AFAIK, it's missing since Win7, W2k8, so your best built-in bet might be messing with sc.exe.

   In either case, should you pick this route, you'll have to deal with the question of setting up proper permissions on your app's assets. This question is reasonably complex in itself since there are many moving parts involved.

   For a start, you have to make sure your assets are tried to be accessed not from "the process' current directory"—which may be essentially random when it runs as a service—but either from the place the process was explicitly told about when run (via command-line option or whatever) or figured out somehow using a reasonably engeneered guess (and this is a complicated topic in itself).

   Next, you either have to make sure the account your Windows™ uses to run your service really has the permissions to access the place your assets are stored in. Another possibility is to add a dedicated account and make the SCM use it for running your service.

   Note that in either case proper error handling and their reporting is paramount: when your program is being run non-interactively, you want to know when something goes wrong: socket failed to be opened or listened on, assets not found, access was denied when trying to open an asset file, and so on—in all these cases you have to 1) handle the error, and 2) report it in a way you can deal with it. For a non-interactive Windows™ program the best way may be to use the Event Log (say, via golang.org/x/sys/windows/svc/eventlog).