Cookbook Deployment Suggestion

[iwelch]

reading https://docs.mojolicious.org/Mojolicious/Guides/Cookbook#DEPLOYMENT

I would suggest adding a few steps, for debugging. there are so many things that can go wrong...

first, I would suggest running the mojo script without nginx integration but on a different port on the server. as long as they listen to different ports, they apparently do not step on one another. (I had thought otherwise, which caused me headaches on end for no good reason.)

only at this point should integration into nginx be attempted. yes, probably obvious to many, but not to me. this is what the proxy stuff above does. as for me, I am going to stick to having each lite script listen on its own port.

only then should systemd integration be contemplated.

is this a good guideline, or am I just thick?

I then looked at the deployment guide for systemd in the cookbook. May I suggest adding a little bit of information?

1. where should the service file typically go? I put mine in /usr/lib/systemd/system under ubuntu 22.04.

2. what user should the serviced invokation be running under? it took me a while to realize that I did not have a user 'sri' on my system. I ended up using www-data. Once the script is owned by www-data, too, this works.

3. the script does not produce any errors on the command line, after being invoked with 'systemctl start mylitescript.service', even if it had errors. I wonder whether systemd can be convinced to barf appropriately immediately if something goes wrong, as it does when trying to start nginx with an error in the conf files.

[s1037989]

Hi, Ivo! I'll tell you what I've been doing for a while now and it works great! I don't use nginx or any other "traditional" web server. Everything is powered by Mojolicious. I have a "proxy <https://docs.mojolicious.org/Mojolicious/Plugin/DefaultHelpers#proxy-start_p>" mojo app that listens on Port 80/443 and then I have all of my mojo apps listening on unix domain sockets with a filename that is the intended hostname. All mojo apps' DNS point to the proxy server and any request for a mojo app is on a unique domain name and the proxy server proxies the request to the unix domain socket named by the requested hostname. I also support tcp proxy for [non-mojo] apps that can't listen on UDS and for proxying to other hosts not on the same host as the proxy. This works exceptionally well for me and makes it so easy to set up new web apps, even just quick prototypes. With a wildcard DNS, you just need to start up an app listening on a unix domain socket named anything within your wildcard space -- nothing else to do and no extra ports to open. And a Mojolicious proxy server is infinitely more extensible than an nginx app (I'm sure you can do a lot more with nginx modules, but that's not easy to do). I created a Mojolicious Plugin called ProxyPass <https://github.com/stefanadams/Mojolicious-Plugin-ProxyPass/blob/main/lib/Mojolicious/Plugin/ProxyPass.pm> that sets up a lot of that stuff for you, and even provides the ability to require authentication before getting access to the upstream. I used to mount <https://docs.mojolicious.org/Mojolicious/Guides/Cookbook#Application-embedding> applications and even use Toadfarm <https://metacpan.org/pod/Toadfarm> -- and those are still great options -- but I have switched my standard to proxying in order to allow each app to develop at independent rates and not have one app's library upgrades affect another app, this approach even uses separate perl instances (versions) for each app. Certainly there can be disadvantages to that, so many perl processes running when one perl process could handle so much more. But with perlbrew / carton, each app can have its own perl instance and its own libraries and affect no other apps. And the ease by which new apps are ready to test is way better than futzing with an nginx config or opening ports. I've also created an app-wrapper script to make it really easy for systemd. All my apps have an identical systemd configuration and all point at the app-wrapper. The arguments to app-wrapper are what perlbrew perl instance to use and where is the app. I'd even recommend a Mojo proxy app as a Deployment <https://docs.mojolicious.org/Mojolicious/Guides/Cookbook#DEPLOYMENT> strategy for the Cookbook! :)

…

On Thu, Feb 23, 2023 at 12:26 PM ivo welch ***@***.***> wrote: reading https://docs.mojolicious.org/Mojolicious/Guides/Cookbook#DEPLOYMENT I would suggest adding a few steps, for debugging. there are so many things that can go wrong... first, I would suggest running the mojo script without nginx integration but on a different port on the server. as long as they listen to different ports, they apparently do not step on one another. (I had thought otherwise, which caused me headaches on end for no good reason.) only at this point should integration into nginx be attempted. yes, probably obvious to many, but not to me. this is what the proxy stuff above does. as for me, I am going to stick to having each lite script listen on its own port. only then should systemd integration be contemplated. is this a good guideline, or am I just thick? I then looked at the deployment guide for systemd in the cookbook. May I suggest adding a little bit of information? 1. where should the service file typically go? I put mine in /usr/lib/systemd/system under ubuntu 22.04. 2. what user should the serviced invokation be running under? it took me a while to realize that I did not have a user 'sri' on my system. I ended up using www-data. Once the script is owned by www-data, too, this works. 3. the script does not produce any errors on the command line, after being invoked with 'systemctl start mylitescript.service', even if it had errors. I wonder whether systemd can be convinced to barf appropriately immediately if something goes wrong, as it does when trying to start nginx with an error in the conf files. 4. — Reply to this email directly, view it on GitHub <#2039>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6K6QJPAXHCFCMIRUPBCLWY6TW7ANCNFSM6AAAAAAVF7HY5Y> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>