Hello, My name is Zoe, a server side engineer in Rakuma. I like to polish my sneakers these days.
This post is about Rails x puma-dev x puma server environment.
The original motivation for this post is my laggy local Rails environment with pow x powder. I frequently encounter the situations where the whole process stops therefore it needs reboot. Moreover, the web application run on powder is slow, so I considered updates, but it hasn’t been updated for 3 years.
After some investigation, I gave a try to move onto puma-dev as a better alternative with migration support from powder.
What is puma?
Puma is a simple, fast, multi-threaded, highly concurrent HTTP 1.1 server for Ruby / Rack applications.
Puma is now the default server for Rails (above version 5). Thin, webrick, and unicorn are also categorized as application servers for Rails.
What is puma-dev? -The servers started by puma are centrally managed. Once puma-dev accepts an HTTP access, the puma server is started automatically. It automatically sleeps if there is no access for a while. As stated above, server operations are managed by puma-dev without any manual operation.
・ Set up a proxy server
This feature allows you to easily access "(directory name) .test" puma server from your browser.
This seems to be achieved via
etc / resolver / test created by
Access to each puma server is automatically distributed through this proxy.
domainname1.test => ~/.puma-dev/domainname1.test directory domainname2.test => ~/.puma-dev/domainname2.test directory domainname3.test => ~/.puma-dev/domainname3.test directory
Good points of puma-dev - You can access *.test without setting hosts Without puma-dev, you usually need to set up /etc/hosts for every Rails application, but with puma-dev, no more configuration after initial setup is done.
・ You do not need to start each server by executing commands by yourself
bundle exec rails s
・ Easy setup. You can use it by just typing a few commands. As described on GitHub, puma-dev is a "zero-config development server", no config file is required, and can be used with just a few commands.
・Your powder settings can be re-used. This is also good. The uniform specification allows multiple developers to have diversity for their choices in tools.
Notes on puma-dev Puma-dev uses port 80. If you are using Apache or Nginx on port 80/443, you must change the port number used by puma-dev. Also, because puma-dev run in background, you cannot use byebug for Rails debug.
When to use puma-dev? For example, puma-dev is useful if you develop multiple related apps together, such as front-side and api apps. If you don’t use puma-dev, you need to manually start multiple Rails apps with different port numbers. That’s bothering.
bundle exec rails s -p 3000 bundle exec rails s -p 3001 ….
Puma-dev solves such problems!
Usage * All descriptions are based on the assumption of macOS / Homebrew / Rails app.
・If you have not installed Homebrew, please install from https://brew.sh/index_ja
・Install puma-dev with
brew install puma-dev・Initial setup with
1-2. Migration from powder
When migrating from powder, please uninstall powder and execute
puma-dev -pow. puma-dev will look to
~ /.pow directory. You can re-use
.powrc as puma-dev will refer to them.
Link puma-dev to each application Move to the Rails application directory, then execute
puma-dev link. Or, you can create a symlink to the app root directly from ~/.puma-dev/. Now, you can access to your app by http://directoryname.test. If you cannot, you may find out what's happening with debug in section 4.
How to restart puma server. In the root of Rails application directory, execute
Debugging If something doesn’t work, you can investigate the log at ~/Library/Logs/puma-dev.log, where puma-dev and puma log are output to. This can be helpful if your application errs before startup, due to syntax error or other kind of errors, and you cannot find the cause from the browser.
FYI. byebug Although I wrote earlier that you cannot use byebug with puma-dev, you can somehow use byebug Gem's remote debugging. I recommend you, however, starting Rails server only if you want to use byebug, because the byebug server is not intuitive enough to recognize its timing to start and connect the server. For more details, you can refer to the byebug Gem GUIDE. https://github.com/deivid-rodriguez/byebug/blob/master/GUIDE.md#debugging-remote-programs
After migration to puma-dev, my local server is stable and there are no problems described at the beginning! Creating the comfortable local environment itself is fun and you can develop more efficiently. Good luck with puma-dev!