kotovalexarian-likes-github/puma--puma
1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00
Code Releases Activity

Remove upstart from docs (#2408)

Browse source 
upstart is dead!
upstart as system init - last release - 14.04 LTS, public support ending April 2019
upstart as user init - last release - 16.04 LTS, public support ending April 2021

Signed-off-by: fliiiix <hi@l33t.name>

Co-authored-by: Nate Berkopec <nate.berkopec@gmail.com>
This commit is contained in:
Felix 2020-10-03 16:04:58 +02:00 committed by GitHub
parent ddbeda76b4
commit a31959c535
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
7 changed files with 5 additions and 169 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
History.md
View file

@ -7,6 +7,7 @@
* Cleanup daemonization in rc.d script (#2409)
* Refactor
* Remove upstart from docs (#2408)
* Consolidate option handling in Server, Server small refactors, doc changes (#2389)
## 5.0.2 / 2020-09-28

4
README.md
View file

@ -274,11 +274,11 @@ end
Puma has support for Capistrano with an [external gem](https://github.com/seuros/capistrano-puma).
It is common to use process monitors with Puma. Modern process monitors like systemd or upstart
It is common to use process monitors with Puma. Modern process monitors like systemd or rc.d
provide continuous monitoring and restarts for increased
reliability in production environments:
* [docs/jungle](https://github.com/puma/puma/tree/master/docs/jungle) for rc.d and upstart
* [docs/jungle](https://github.com/puma/puma/tree/master/docs/jungle) for rc.d
* [docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md)
## Community Extensions

4
docs/deployment.md
View file

@ -81,7 +81,7 @@ thread to become available.
Daemonization was removed in Puma 5.0. For alternatives, continue reading.
I prefer to not daemonize my servers and use something like `runit` or `upstart` to
I prefer to not daemonize my servers and use something like `runit` or `systemd` to
monitor them as child processes. This gives them fast response to crashes and
makes it easy to figure out what is going on. Additionally, unlike `unicorn`,
puma does not require daemonization to do zero-downtime restarts.
@ -91,7 +91,7 @@ task and thus want it to live on past the `cap deploy`. To these people I say:
You need to be using a process monitor. Nothing is making sure puma stays up in
this scenario! You're just waiting for something weird to happen, puma to die,
and to get paged at 3am. Do yourself a favor, at least the process monitoring
your OS comes with, be it `sysvinit`, `upstart`, or `systemd`. Or branch out
your OS comes with, be it `sysvinit` or `systemd`. Or branch out
and use `runit` or hell, even `monit`.
## Restarting

4
docs/jungle/README.md
View file

@ -1,9 +1,5 @@
# Puma as a service
## Upstart
See `/docs/jungle/upstart` for Ubuntu's upstart scripts.
## Systemd
See [/docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md).

61
docs/jungle/upstart/README.md
View file

@ -1,61 +0,0 @@
# Puma as a service using Upstart
Manage multiple Puma servers as services on the same box using Ubuntu upstart.
## Installation
# Copy the scripts to services directory
sudo cp puma.conf puma-manager.conf /etc/init
# Create an empty configuration file
sudo touch /etc/puma.conf
## Managing the jungle
Puma apps are referenced in /etc/puma.conf by default. Add each app's path as a new line, e.g.:
```
/home/apps/my-cool-ruby-app
/home/apps/another-app/current
```
Start the jungle running:
`sudo start puma-manager`
This script will run at boot time.
Start a single puma like this:
`sudo start puma app=/path/to/app`
## Logs
Everything is logged by upstart, defaulting to `/var/log/upstart`.
Each puma instance is named after its directory, so for an app called `/home/apps/my-app` the log file would be `/var/log/upstart/puma-_home_apps_my-app.log`.
## Conventions
* The script expects:
* a config file to exist under `config/puma.rb` in your app. E.g.: `/home/apps/my-app/config/puma.rb`.
* a temporary folder to put the PID, socket and state files to exist called `tmp/puma`. E.g.: `/home/apps/my-app/tmp/puma`. Puma will take care of the files for you.
You can always change those defaults by editing the scripts.
## Here's what a minimal app's config file should have
```
pidfile "/path/to/app/tmp/puma/pid"
state_path "/path/to/app/tmp/puma/state"
activate_control_app
```
## Before starting...
You need to customise `puma.conf` to:
* Set the right user your app should be running on unless you want root to execute it!
* Look for `setuid apps` and `setgid apps`, uncomment those lines and replace `apps` to whatever your deployment user is.
* Replace `apps` on the paths (or set the right paths to your user's home) everywhere else.
* Uncomment the source lines for `rbenv` or `rvm` support unless you use a system wide installation of Ruby.

31
docs/jungle/upstart/puma-manager.conf
View file

@ -1,31 +0,0 @@
# /etc/init/puma-manager.conf - manage a set of Pumas
# This example config should work with Ubuntu 12.04+. It
# allows you to manage multiple Puma instances with
# Upstart, Ubuntu's native service management tool.
#
# See puma.conf for how to manage a single Puma instance.
#
# Use "stop puma-manager" to stop all Puma instances.
# Use "start puma-manager" to start all instances.
# Use "restart puma-manager" to restart all instances.
# Crazy, right?
#
description "Manages the set of puma processes"
# This starts upon bootup and stops on shutdown
start on runlevel [2345]
stop on runlevel [06]
# Set this to the number of Puma processes you want
# to run on this machine
env PUMA_CONF="/etc/puma.conf"
pre-start script
for i in `cat $PUMA_CONF`; do
app=`echo $i | cut -d , -f 1`
logger -t "puma-manager" "Starting $app"
start puma app=$app
done
end script

69
docs/jungle/upstart/puma.conf
View file

@ -1,69 +0,0 @@
# /etc/init/puma.conf - Puma config
# This example config should work with Ubuntu 12.04+. It
# allows you to manage multiple Puma instances with
# Upstart, Ubuntu's native service management tool.
#
# See puma-manager.conf for how to manage all Puma instances at once.
#
# Save this config as /etc/init/puma.conf then manage puma with:
# sudo start puma app=PATH_TO_APP
# sudo stop puma app=PATH_TO_APP
# sudo status puma app=PATH_TO_APP
#
# or use the service command:
# sudo service puma {start,stop,restart,status}
#
description "Puma Background Worker"
# no "start on", we don't want to automatically start
stop on (stopping puma-manager or runlevel [06])
# change apps to match your deployment user if you want to use this as a less privileged user (recommended!)
setuid apps
setgid apps
respawn
respawn limit 3 30
instance ${app}
script
# this script runs in /bin/sh by default
# respawn as bash so we can source in rbenv/rvm
# quoted heredoc to tell /bin/sh not to interpret
# variables
# source ENV variables manually as Upstart doesn't, eg:
#. /etc/environment
exec /bin/bash <<'EOT'
# set HOME to the setuid user's home, there doesn't seem to be a better, portable way
export HOME="$(eval echo ~$(id -un))"
if [ -d "/usr/local/rbenv/bin" ]; then
export PATH="/usr/local/rbenv/bin:/usr/local/rbenv/shims:$PATH"
elif [ -d "$HOME/.rbenv/bin" ]; then
export PATH="$HOME/.rbenv/bin:$HOME/.rbenv/shims:$PATH"
elif [ -f /etc/profile.d/rvm.sh ]; then
source /etc/profile.d/rvm.sh
elif [ -f /usr/local/rvm/scripts/rvm ]; then
source /etc/profile.d/rvm.sh
elif [ -f "$HOME/.rvm/scripts/rvm" ]; then
source "$HOME/.rvm/scripts/rvm"
elif [ -f /usr/local/share/chruby/chruby.sh ]; then
source /usr/local/share/chruby/chruby.sh
if [ -f /usr/local/share/chruby/auto.sh ]; then
source /usr/local/share/chruby/auto.sh
fi
# if you aren't using auto, set your version here
# chruby 2.0.0
fi
cd $app
logger -t puma "Starting server: $app"
exec bundle exec puma -C config/puma.rb
EOT
end script