Hosting several Go Websites using Virtualmin

Operating system: Debian
OS version: 10

I asked the original question in a previous thread:

And I got an answer from @Joe how to do this. I have now implemented his advice and managed to host 6 Go web sites https://go4webdev.org but without using Virtualmin

My follow up question is if I have understand him correct goTask3 and will this work when using (adding) Virtualmin?

Proxying works in Virtualmin-managed domains. I don’t think I know what you’re asking. This is what I’ve been telling you to do from the beginning.

But, it also continues to be true that you should not put your applications into the document root (which that tutorial seems to be suggesting). Go apps that you are proxying to do not need to be in the document root (public_html in a Virtualmin domain), and absolutely should not be in the document root.

Edit: To be clear: Static HTML can go into the document root. No executable application code (other than PHP, which is a special case) should.

Sorry for not being clear. And it is because I do not know how to ask. But as I understand it, Nginx creates virtual servers that are proxied. And Virtualmin creates also virtual servers. So the question is if they work “together”. And your answer indicates that it should work.

I am suggesting to use the Nginx path

/var/www/sitename/go_executable/

And

/var/www/sitename/public/web stuff for css etc

Is /var/www/ in the document root (sorry for asking)? If it is, where should I place the Go executable and the web stuff?

nginx doesn’t create anything. The configuration file snippets included in that tutorial create virtual hosts and set up proxying. In the Virtualmin scenario, Virtualmin creates the virtual host configuration, and you use one of a variety of methods to add the proxy rules (you can add it to Server Templates if it is consistent across apps, either by using a socket in the domain home or by using a post-create script to setup the port, or by using the proxy rules setup in Virtualmin on each domain, or by manually editing the config file, or by using the new support for proxied apps…I’m not sure how far along that is, it might not be in current Virtualmin version).

It depends on the configuration of the web server. It usually is the default location for web data. (though, I guess the default is /var/www/html for static web files). In a Virtualmin system it’s not right for anything, though. Virtualmin domain user homes live in /home. And, those domains apps should also live in /home (but not in public_html).

It is not crystal clear :slight_smile:

If I interpret this correct it should look like this:

/home/domain1/go + public folder
/home/domain2/go + public folder
/home/domain3/go + public folder

…etc and the webstuff (CSS/HTML/JS) in public folder?

public_html

Do you mean a certain folder or the name of the folder?

As neither Nginx nor Virtualmin uses or can use the content of this folder, I believe that the name is irrelevant. Only Go executable can read and do use this folder.

Then why are you asking me? I only care about and can help you with Virtualmin and how it configures nginx. What your Go app does is irrelevant.

You told me to use the folder “/home” and I asked you if you mean this way:

/home/domain1/go + public folder
/home/domain2/go + public folder
/home/domain3/go + public folder

I did not understand your answer “public_html”, Being a newbie in Virtualmin I have no knowledge why Virtualmin bother the place of Go executable managed by Nginx. Hence my questions.

I guess I have to figure out this myself the trial-and-error way. Sorry for asking stupid questions.

I’m trying to help. Just confused by your questions.

I assumed you were trying to divide out your static assets so they could be served by your web server without involving the go app server. In those kinds of deployments, you’d put your static assets into the public_html directory. If you do not want anything served directly by the web server, then you’d have nothing in public_html.

I guess that is caused by my non native english origin together with a faulty imagination how Virtualmin works. And Go is not that mature and wellknown as a web tool.

The Go server does more than serves html files and endpoints. Business logic, SQL stuff, Go routines (multitasking), calculations etc that I think Nginx is unable to handle. So replacing Go is not the way I want to go. I know that many thing can be done with Javascript, but Go does it both faster and with concurrency. And you have harder to set up gRPC Services. My intention is to create “smart” web sites that Nginx and static assets cannot manage AFAIK.

My intention is to use Javascript where it outperforms Go. As in https://table.go4webdev.org/aggrid Otherwise Go outperforms Javascript as a backend.

I am not suggesting replacing go. And, I’m familiar with deploying go apps. I’ve deployed a few for clients.

I am saying that it is a common strategy for any application server environment to serve static assets (HTML, images, CSS, JavaScript, whatever doesn’t change) from the web server rather than the app server. It matters less if the app server is very fast and very efficient, which may be the case for a go app server (gorilla, or something else?), but you still have the proxy overhead. Anyway, I assumed that’s why you kept mentioning a “public” directory because it is such a common deployment strategy.

Go html template is NOT entirely static. They are distant relatives to Angular and have some React module thinking. I can reuse HTML and Javascipt “components” in a way that is not possible with “static” stuff. So replacing Go html templates with static html is a huge step backwards. And away from the DRY thinking. And Go html templates are way simpler to maintain than static html files.

When using PHP I weakly remember that the PHP files was in the “public_html” folder together with all other stuff. Using Go I place the Go executable outside the “public” folder. I have only borrowed the naming convention from the old “public_html” folder. You can call it “stuff”, “files” or whatever.

Back to my original question. What happens if I use Virtualmin with this method (Nginx and Go)? Is it OK out of the box? Assuming that Virtualmin manage Nginx and Nginx manage Go? Or am I thinking in a completely wrong direction?

nginx doesn’t manage go. It’s a web server. It doesn’t manage anything. You setup a proxy rule to tell nginx to pass requests through to another web server (your application server in go).

And, of course it’s OK with Virtualmin. This is what I’ve been saying from my very first response. I keep saying, “proxy to your web app”, and you keep asking “can I proxy to my web app”, and I keep saying, “Yes, proxy to your web app, like I said before”. :wink:

Thank you for your patience! I know I am not the sharpest knife in the box. :slight_smile:

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.