I'm using Ruby on Rails 6 with Puma server managed by systemd on Ubuntu 20.04.
On the official Puma website, two setups types are given:
simple
with socket activation
There it says:
systemd and puma also support socket activation, where systemd opens the listening socket(s) in advance and provides them to the puma master process on startup. Among other advantages, this keeps listening sockets open across puma restarts and achieves graceful restarts, including when upgraded puma, and is compatible with both clustered mode and application preload.
[emphasis mine]
I have two questions:
What's a "graceful" restart?
What are the "other advantages"?
One other advantage would be the use of 'system ports', e.g. port 80 while running puma as a non-root user.
Related
I'm just trying to run my server locally. I'm on Windows and using Ruby on Rails on Windows is a pain, so I am using Vagrant. I am doing all of these commands from my Vagrant shell.
I've tried rails s and rails s -b 0.0.0.0. Both give me OK responses in the terminal:
=> Rails 5.2.3 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.12.1 (ruby 2.6.1-p33), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
However, when I go to localhost:3000 in my browser, it gives me:
This site can't be reached.
localhost refused to connect.
When I tried to curl http://localhost:3000 get:
curl: (7) Failed to connect to localhost port 3000: Connection refused
I also have the following line of code in my Vagrantfile:
config.vm.network "forwarded_port", guest: 3000, host: 3000
Really don't know what to do next. Right now, I am installing Ubuntu ISO file (will be done in 5 hours, so that's quite a bit of time) to create a VirtualBox instance as backup if this doesn't work. Hoping I can find a fix for this.
I would like to suggest you docker. Docker is not new, it was released in 2012 and since then has become one of the fastest-growing technologies in web development and devops.
Some of the advantages you will have if you start using it:
Reproducibility: A docker container is guaranteed to be identical on any system that can run docker and having a simple file you (and your team members) can run the system with the same specs really fast on another environment.
Isolation: Dependencies or settings within a container will not affect any installations or configurations on your computer.
Hub: You have thousands of well maintained images available including ruby and you can use them for faster experiment and get in the stuff that mater.
Docker is not vagrant, is a lot more and much more powerful.
Easy image upgrades: because images are versioned, it's a matter of to change a single tag.
Happy codding with the whale!
The key thing here is "localhost" on your Vagrant box and "localhost" on your machine are two different things. The port forwarding can often fix this, but if you have two Vagrant machines using the same port you may be sending traffic to the wrong one.
It's often better to get the Vagrant machine's IP and connect to that directly. If that IP keeps changing, you can lock it down:
config.vm.network "private_network", ip: "172.30.1.5"
Then you connect to http://172.130.1.5:3000/ predictably.
Resolved by running Ruby on Rails on UBUNTU VirtualBox machine.
I am having troubles with auto-scaling group in AWS. I am running a Ruby on Rails App in EC2 instance with ELB. I applied auto-scaling group so it scales-up automatically when heavy traffics come. However, the app server upon nginx does not start automatically so it becomes "OutOfService" in ELB. Any solution?
You can either use Monit to monitor your services, in this case Nginx and/or ( Puma, Unicorn, Passenger etc.. ) or use unix's own 'service' for things like this, Upstart.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples#auto-starting-services-with-upstart
As the title states, I'm trying to start a Ruby on Rails app through systemd socket activation. I've no prior experience with Ruby and the lack of quality documentation is frustrating.
Obtaining the listen socket from systemd is trivial enough, though I'm struggling to put that socket to use. Is there an app server, that accepts a pre-existing listen socket? Or do I have to write my own, possibly by implementing a Rack::Handler (going by what limited information I've been able to gather from the documentation)? In the latter case a minimal example implementation would be helpful.
I'm looking for a production-suitable, lightweight, least-effort solution, capable of serving an average of 2 concurrent users on embedded hardware.
Starting with Puma 3.0.0, socket activation is supported by its Rack module, which is used by rails server. This means that running bin/rails server puma from systemd with socket activation will now work out of the box (tested with Puma 3.9.1). One caveat is that you must start bin/rails inside your application root, not the globally installed version.
For more details on this setup and some examples, see my blogpost.
In absence of any alternatives, I'll likely end up using the Puma web server, which implements the systemd socket activation protocol.
EDIT: Puma does implement socket activation, but not in the Rack handler.
I arrived at my initial conclusion via grep -r LISTEN_FDS and only discovered my mistake once I actually tried it.
Where do you configure the IP addresses that are permitted to connect to a Rails app?
I have a simple rails application which I have inherited that runs in a development environment on Ubuntu 14.04.
It was working OK until recently when some changes were merged in from git. Now when I run rails s the application appears to start thin as the server, as expected.
=> Booting Thin
=> Rails 4.2.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on localhost:3000, CTRL+C to stop
netstat shows that rails is in fact listening as expected
tcp 0 0 localhost:3000 *:* LISTEN
I can access the website ok from a browser on the server box using 127.0.0.1:3000 and all appears to work as it should. I can't access it from any other machine as a Connection Refused status is returned because rails is only allowing localhost on port 3000.
If I start Thin from the command line with thin start it returns with a similar setup
>> Using rack adapter
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
But this time Thin is listening for connections from any IP and I can reach the site from another machine. There is a difference in behaviour between starting Thin on its own and starting Thin from rails although both are version 1.5.1. Something in the Rails config is constraining Thin to listen only for connections from localhost.
I have all up to date gems so far as I can tell. I thought the issue might be something to do with eventmachine, but I can't find anything.
Any advice appreciated.
0.0.0.0:3000 is an alias for binding to all interfaces. Localhost is literally only the localhost 127.0.0.1 which is not reachable from outside.
With rails 4 I believe they changed the deafult behavior of rails s so the server no longer listens on external interfaces. You can use
rails s -b 0.0.0.0
This will bind it to 0.0.0.0 (all interfaces),as if you started thin manually.
When you start the server specify the ip on which your rails application will run by binding rails application to specific IP. This can be done with -b option. For example if your ip is 192.168.1.69
rails server -b 192.168.1.69 -p 3000
You need to allow the incoming traffic for the port 3000 when you try to access your app from other devices only with in the same network. check out the documentation for Allowing Incoming Traffic on Specific Ports on ubuntu
Thanks errata
That explains it clearly, and now that I have the keyword "binding", I can see that this question has been asked before. It would be helpful to set the binding in a config file, but it seems this is not possible. I'll try to set an alias for the rails s command and use that.
FYI the change was made in version 4.2 of rails according to the release notes for that version because of a change in the underlying rack library.
I am new to rails.
How do I find which web server rails app using?
Command to start app is
rails s puma -dp 80 -e production
Also I see apache2 is not running on server. So I guess Puma is being used. But I am not sure Puma is webserver, I found link which describes setting up Puma with nginx. So Am I using nginx? Also where do I find log of this web server?
Puma can be used as a webserver, since the command line appears to be setting the port to 80, this is probably how it is configured in your case. This works fine for the most part, but a more common configuration is to use apache or nginx as a reverse proxy and to serve static assets. (the stuff in public/assets). Requests for non-static content are then forwarded to puma.