工头开始后，工头关闭了彪马 Procfile.rb heroku__release.sh文件

问题描述

我的puma服务器没有保持活动状态，它一直关闭。我认为这与发布有关，但不确定如何使其动态，因此它可以在heroku上运行，但不能在工头上运行。

运行foreman start时，我使用procfile启动了puma服务器和sidekiq工作者

请参阅以下设置代码。我不确定为什么它会一直关闭。

我安装了工头

$ gem install foreman

设置Procfile

Procfile.rb

release: bin/heroku_release.sh
web: bundle exec puma -C ./config/puma.rb
worker: bundle exec sidekiq

设置bin / heroku_release.sh文件

heroku__release.sh文件

#!/usr/bin/env bash
#
# Usage: bin/heroku_deploy

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
NO_COLOR='\033[0m'
CLEAR_LINE='\r\033[K'

set -euo pipefail

schema_version=$(bin/rails db:version | { grep "^Current version: [0-9]\\+$" || true; } | tr -s ' ' | cut -d ' ' -f3)

if [ -z "$schema_version" ]; then
  printf "?${RED}   [Release Phase]: Database schema version could not be determined. Does the database exist?${NO_COLOR}\n"
  exit 1
fi

if [ "$schema_version" -eq "0" ]; then
  printf "\n⏳${YELLOW}   [Release Phase]: Loading the database schema.${NO_COLOR}\n"
  bin/rails db:schema:load
else
  printf "\n⏳${YELLOW}   [Release Phase]: Running database migrations.${NO_COLOR}\n"
  bin/rails db:migrate
fi

printf "\n?${GREEN}   [Release Phase]: Database is up to date.${NO_COLOR}\n"

在foreman start之后的控制台：

14:53:39 release.1 | started with pid 10418
14:53:39 web.1     | started with pid 10419
14:53:39 worker.1  | started with pid 10420
14:53:40 web.1     | Puma starting in single mode...
14:53:40 web.1     | * Version 4.3.5 (ruby 2.7.1-p83),codename: Mysterious Traveller
14:53:40 web.1     | * Min threads: 5,max threads: 5
14:53:40 web.1     | * Environment: development
14:53:44 web.1     | * Listening on tcp://0.0.0.0:5100
14:53:44 web.1     | Use Ctrl-C to stop
14:53:44 release.1 | 
14:53:44 release.1 | ⏳   [Release Phase]: Running database migrations.
14:53:44 worker.1  | 2020-09-25T19:53:44.905Z pid=10420 tid=arg INFO: Booted Rails 6.0.3.3 application in development environment
14:53:44 worker.1  | 2020-09-25T19:53:44.906Z pid=10420 tid=arg INFO: Running in ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-darwin17]
14:53:44 worker.1  | 2020-09-25T19:53:44.907Z pid=10420 tid=arg INFO: See LICENSE and the LGPL-3.0 for licensing details.
14:53:44 worker.1  | 2020-09-25T19:53:44.907Z pid=10420 tid=arg INFO: Upgrade to Sidekiq Pro for more features and support: https://sidekiq.org
14:53:44 worker.1  | 2020-09-25T19:53:44.907Z pid=10420 tid=arg INFO: Booting Sidekiq 6.1.2 with redis options {}
14:53:44 worker.1  | 2020-09-25T19:53:44.910Z pid=10420 tid=arg DEBUG: Client Middleware: 
14:53:44 worker.1  | 2020-09-25T19:53:44.910Z pid=10420 tid=arg DEBUG: Server Middleware: 
14:53:44 worker.1  | 2020-09-25T19:53:44.911Z pid=10420 tid=arg DEBUG: {:queues=>["critical","default","mailers"],:labels=>[],:concurrency=>10,:require=>".",:strict=>true,:environment=>nil,:timeout=>25,:poll_interval_average=>nil,:average_scheduled_poll_interval=>5,:error_handlers=>[#<Sidekiq::ExceptionHandler::Logger:0x00007ff9e2a150e8>],:death_handlers=>[],:lifecycle_events=>{:startup=>[],:quiet=>[],:shutdown=>[],:heartbeat=>[]},:dead_max_jobs=>10000,:dead_timeout_in_seconds=>15552000,:reloader=>#<Sidekiq::Rails::Reloader @app=Teacher::Application>,:verbose=>true,:production=>{:concurrency=>25},:staging=>{:concurrency=>15},:config_file=>"./config/sidekiq.yml",:tag=>"teacher",:identity=>"me-MacBook-Air.local",:fetch=>#<Sidekiq::BasicFetch:0x00007ff9e906d430 @options={...},@strictly_ordered_queues=true,@queues=["queue:critical","queue:default","queue:mailers",2]>}
14:53:48 release.1 |    (0.3ms)  SELECT pg_try_advisory_lock(5720425725902639640)
14:53:48 release.1 |    (1.4ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
14:53:48 release.1 |   ActiveRecord::InternalMetadata Load (0.6ms)  SELECT "ar_internal_metadata".* FROM "ar_internal_metadata" WHERE "ar_internal_metadata"."key" = $1 LIMIT $2  [["key","environment"],["LIMIT",1]]
14:53:48 release.1 |    (0.4ms)  SELECT pg_advisory_unlock(5720425725902639640)
14:53:48 release.1 |    (1.5ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
14:53:48 release.1 | 
14:53:48 release.1 | ?   [Release Phase]: Database is up to date.
14:53:48 release.1 | exited with code 0
14:53:48 system    | sending SIGTERM to all processes
14:53:48 web.1     | - Gracefully stopping,waiting for requests to finish
14:53:48 worker.1  | 2020-09-25T19:53:48.873Z pid=10420 tid=arg DEBUG: Got TERM signal
14:53:48 worker.1  | 2020-09-25T19:53:48.873Z pid=10420 tid=arg INFO: Shutting down
14:53:48 worker.1  | 2020-09-25T19:53:48.873Z pid=10420 tid=arg INFO: Terminating quiet workers
14:53:48 worker.1  | 2020-09-25T19:53:48.874Z pid=10420 tid=1qno INFO: Scheduler exiting...
14:53:48 web.1     | === puma shutdown: 2020-09-25 14:53:48 -0500 ===
14:53:48 web.1     | - Goodbye!
14:53:48 web.1     | terminated by SIGTERM
14:53:49 worker.1  | 2020-09-25T19:53:49.380Z pid=10420 tid=arg INFO: Bye!
14:53:49 worker.1  | exited with code 0

解决方法

我认为问题在于您制作的Heroku release脚本并不打算在开发环境中使用。 Heroku知道将该脚本作为其管理behind the scenes的构建管道的一部分来处理，但是您开发中的领班实例没有适当的特殊处理来知道该怎么做。默认情况下，Foreman适用于长时间运行的流程，而Heroku通过Procfile处理一次性一次性流程的操作是针对其平台的。

我建议创建两个不同的Procfile，一个用于开发，一个用于生产，因为它们必然会随着时间而变化。我通常使用的一种设置是：

1. Procfile-默认生产procfile
2. Procfile.dev-我要在开发中运行的procfile。

您的开发过程文件实际上只需要您长期运行的进程即可，因为您可以手动运行迁移（或发布脚本），而不必担心会影响任何人。

要在本地运行其他Procfile（即Procfile.dev），只需运行：
foreman start -f Procfile.dev