Elastic Beanstalk上的502 bad gateway nginx + puma + rails 3.2

时间:2022-08-25 09:01:55

The deployment was successful and everything is green. But when we try to access the application URL, it gives 502 Bad Gateway error.

部署成功,一切都是绿色的。但是当我们尝试访问应用程序URL时,它会出现502 Bad Gateway错误。

Checking for puma process with ps -aux | grep puma doesn't return any process attached to puma server but pgrep returns following.

使用ps -aux检查美洲狮过程| grep puma不会返回附加到puma服务器的任何进程,但pgrep会返回以下内容。

$pgrep -fl puma
18009 su -s /bin/bash -c bundle exec puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb webapp
18031 ruby /opt/rubies/ruby-2.0.0-p598/bin/puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb

3 个解决方案

#1


1  

I have tried all possible combinations, as shown in every other forum/blog OR support sites of nginx/puma. Following is the status.

我尝试了所有可能的组合,如nginx / puma的其他论坛/博客或支持网站所示。以下是状态。

  1. Default configuration - Where we have UNIX:// sock file used in the UPSTREAM option of nginx.conf and pumaconf.rb - This gives 502 bad gatway. When checked, puma is not running and it is rebooting every 3rd minute.
  2. 默认配置 - 我们有UNIX://在nginx.conf和pumaconf.rb的UPSTREAM选项中使用的sock文件 - 这给出了502错误的gatway。检查时,puma没有运行,并且每隔3分钟重启一次。

  3. As we have used it in DigitalOcean - Change the above UPSTREAM conf URL to tcp://127.0.0.1:3000 in pumaconf.rb and 127.0.0.1:3000 in conf.d/webapp.conf file. - This is also not working, puma is not able to run properly same as above.
  4. 正如我们在DigitalOcean中使用它 - 将上述UPSTREAM配置URL更改为pumaconf.rb中的tcp://127.0.0.1:3000和conf.d / webapp.conf文件中的127.0.0.1:3000。 - 这也行不通,puma无法像上面那样正常运行。

My question is,

我的问题是,

  1. Why there is no control over running puma with diff. configurations? And why we have to always use the UI, which is not able to run the services properly as per other standard configuration options?
  2. 为什么没有控制与差异运行puma。配置?为什么我们必须始终使用UI,因为UI无法按照其他标准配置选项正确运行服务?

  3. There is no configuration options from UI, to change/verify from the UI. So we have to do it from SSH. But, we have no control over rebooting PUMA from console.
  4. UI中没有用于从UI更改/验证的配置选项。所以我们必须从SSH做到这一点。但是,我们无法控制从控制台重启PUMA。

  5. Whenever puma is not running, we are not able to see any logs of what error it is facing. This is really not helpful at all.
  6. 每当美洲狮没有运行时,我们就无法看到它所面临的任何错误的任何日志。这根本没有用。

Puma is not able to run even with default configurations, so it nginx is not able to talk to Puma and so the EC2 does not really make sense!

Puma即使使用默认配置也无法运行,所以nginx无法与Puma交谈,因此EC2没有意义!

Please let us know, how we can resolve this issue, if you have any idea on this.

如果您对此有任何疑问,请告诉我们如何解决此问题。

See this - https://forums.aws.amazon.com/thread.jspa?messageID=608148&#608148

看到这个 - https://forums.aws.amazon.com/thread.jspa?messageID=608148????

Still no answers on this one, this is like our hands are cuffed and not able to change any configurations!

仍然没有这个问题的答案,这就像我们的手被铐,无法改变任何配置!

UPDATE

AWS is somehow stopping and starting PUMA, because i can see the process IDs changing when checking with ps -ef|grep puma. So, I started the puma to work on another port and tried to check if it runs or not.

AWS以某种方式停止并启动PUMA,因为我可以在使用ps -ef | grep puma进行检查时看到进程ID发生变化。所以,我开始使用puma在另一个端口上工作并尝试检查它是否运行。

Started on another port, and then from another console accessing the URL using wget http://127.0.0.1:3000. It prints the following log.

在另一个端口上启动,然后从另一个使用wget http://127.0.0.1:3000访问URL的控制台启动。它打印以下日志。

current]$ bundle exec puma -b tcp://127.0.0.1:3001
Puma 2.0.1 starting...
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://127.0.0.1:3001
Rails Error: Unable to access log file. Please ensure that /var/app/current/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Use Ctrl-C to stop
2015-03-16 13:19:35 +0000: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
2015-03-16 13:19:35 +0000: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.0.1", "GATEWAY_INTERFACE"=>"CGI/1.2"}

So, is it compulsory to use SSL? Because I think by default, it is not enabled.

那么,是否必须使用SSL?因为我认为默认情况下它没有启用。

#2


0  

I had this issue after uploading my rails app, I found this line (auto generated) on secrets.yml (config > secrets.yml) :secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

我在上传rails应用程序后遇到了这个问题,我在secrets.yml(config> secrets.yml)上找到了这一行(自动生成):secret_key_base:<%= ENV [“SECRET_KEY_BASE”]%>

so you have to add it as an environment variable to your environment.

所以你必须将它作为环境变量添加到您的环境中。

In the environment dashboard go to Configuration > Software > Environment properties and add a new variable with name SECRET_KEY_BASE.

在环境仪表板中,转到配置>软件>环境属性,然后添加名为SECRET_KEY_BASE的新变量。

You can set any value but make sure it is a safe key. This resolved the issue for me, I hope it helps.

您可以设置任何值,但请确保它是一个安全的密钥。这解决了我的问题,我希望它有所帮助。

#3


-1  

I could not fix this problem. Also we supposed to use EC2 free instance only instead of BeanStalk.

我无法解决这个问题。此外,我们应该只使用EC2免费实例而不是BeanStalk。

We have now moved to Free EC2 instance with RDS and deployed the rails application using Capistrano with Nginx + Unicorn. Though it was not easy[1][2] but finally we got it working.

我们现在已经使用RDS迁移到Free EC2实例,并使用Capistrano和Nginx + Unicorn部署了rails应用程序。虽然这并不容易[1] [2]但最后我们得到了它的工作。

#1


1  

I have tried all possible combinations, as shown in every other forum/blog OR support sites of nginx/puma. Following is the status.

我尝试了所有可能的组合,如nginx / puma的其他论坛/博客或支持网站所示。以下是状态。

  1. Default configuration - Where we have UNIX:// sock file used in the UPSTREAM option of nginx.conf and pumaconf.rb - This gives 502 bad gatway. When checked, puma is not running and it is rebooting every 3rd minute.
  2. 默认配置 - 我们有UNIX://在nginx.conf和pumaconf.rb的UPSTREAM选项中使用的sock文件 - 这给出了502错误的gatway。检查时,puma没有运行,并且每隔3分钟重启一次。

  3. As we have used it in DigitalOcean - Change the above UPSTREAM conf URL to tcp://127.0.0.1:3000 in pumaconf.rb and 127.0.0.1:3000 in conf.d/webapp.conf file. - This is also not working, puma is not able to run properly same as above.
  4. 正如我们在DigitalOcean中使用它 - 将上述UPSTREAM配置URL更改为pumaconf.rb中的tcp://127.0.0.1:3000和conf.d / webapp.conf文件中的127.0.0.1:3000。 - 这也行不通,puma无法像上面那样正常运行。

My question is,

我的问题是,

  1. Why there is no control over running puma with diff. configurations? And why we have to always use the UI, which is not able to run the services properly as per other standard configuration options?
  2. 为什么没有控制与差异运行puma。配置?为什么我们必须始终使用UI,因为UI无法按照其他标准配置选项正确运行服务?

  3. There is no configuration options from UI, to change/verify from the UI. So we have to do it from SSH. But, we have no control over rebooting PUMA from console.
  4. UI中没有用于从UI更改/验证的配置选项。所以我们必须从SSH做到这一点。但是,我们无法控制从控制台重启PUMA。

  5. Whenever puma is not running, we are not able to see any logs of what error it is facing. This is really not helpful at all.
  6. 每当美洲狮没有运行时,我们就无法看到它所面临的任何错误的任何日志。这根本没有用。

Puma is not able to run even with default configurations, so it nginx is not able to talk to Puma and so the EC2 does not really make sense!

Puma即使使用默认配置也无法运行,所以nginx无法与Puma交谈,因此EC2没有意义!

Please let us know, how we can resolve this issue, if you have any idea on this.

如果您对此有任何疑问,请告诉我们如何解决此问题。

See this - https://forums.aws.amazon.com/thread.jspa?messageID=608148&#608148

看到这个 - https://forums.aws.amazon.com/thread.jspa?messageID=608148????

Still no answers on this one, this is like our hands are cuffed and not able to change any configurations!

仍然没有这个问题的答案,这就像我们的手被铐,无法改变任何配置!

UPDATE

AWS is somehow stopping and starting PUMA, because i can see the process IDs changing when checking with ps -ef|grep puma. So, I started the puma to work on another port and tried to check if it runs or not.

AWS以某种方式停止并启动PUMA,因为我可以在使用ps -ef | grep puma进行检查时看到进程ID发生变化。所以,我开始使用puma在另一个端口上工作并尝试检查它是否运行。

Started on another port, and then from another console accessing the URL using wget http://127.0.0.1:3000. It prints the following log.

在另一个端口上启动,然后从另一个使用wget http://127.0.0.1:3000访问URL的控制台启动。它打印以下日志。

current]$ bundle exec puma -b tcp://127.0.0.1:3001
Puma 2.0.1 starting...
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://127.0.0.1:3001
Rails Error: Unable to access log file. Please ensure that /var/app/current/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Use Ctrl-C to stop
2015-03-16 13:19:35 +0000: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
2015-03-16 13:19:35 +0000: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.0.1", "GATEWAY_INTERFACE"=>"CGI/1.2"}

So, is it compulsory to use SSL? Because I think by default, it is not enabled.

那么,是否必须使用SSL?因为我认为默认情况下它没有启用。

#2


0  

I had this issue after uploading my rails app, I found this line (auto generated) on secrets.yml (config > secrets.yml) :secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

我在上传rails应用程序后遇到了这个问题,我在secrets.yml(config> secrets.yml)上找到了这一行(自动生成):secret_key_base:<%= ENV [“SECRET_KEY_BASE”]%>

so you have to add it as an environment variable to your environment.

所以你必须将它作为环境变量添加到您的环境中。

In the environment dashboard go to Configuration > Software > Environment properties and add a new variable with name SECRET_KEY_BASE.

在环境仪表板中,转到配置>软件>环境属性,然后添加名为SECRET_KEY_BASE的新变量。

You can set any value but make sure it is a safe key. This resolved the issue for me, I hope it helps.

您可以设置任何值,但请确保它是一个安全的密钥。这解决了我的问题,我希望它有所帮助。

#3


-1  

I could not fix this problem. Also we supposed to use EC2 free instance only instead of BeanStalk.

我无法解决这个问题。此外,我们应该只使用EC2免费实例而不是BeanStalk。

We have now moved to Free EC2 instance with RDS and deployed the rails application using Capistrano with Nginx + Unicorn. Though it was not easy[1][2] but finally we got it working.

我们现在已经使用RDS迁移到Free EC2实例,并使用Capistrano和Nginx + Unicorn部署了rails应用程序。虽然这并不容易[1] [2]但最后我们得到了它的工作。