Recording, Sharing, TimeSaving -- 一切成本皆时间

问题

CentOS 7中，执行passenger-status报了如下错误:

1
2
3
4

ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it is running, then the causes of this problem could be:
1. You customized the instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument. If so, please set the environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory and run passenger-status again.
2. The instance directory has been removed by an operating system background service. Please set a different instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument.

而命令passenger-memory-stats可以正常工作。

同样的问题，在Amazon Linux 2 AMI中也同样存在。

今天要跑一个其他的rails项目，为了不污染原先的gemset。就重建了一个gemset, 但是bundle install的时候，安装nokogiri 1.8.4一直失败。
系统版本是Macos 10.13 High Sierra中, ruby版本是rvm安装的ruby2.3.0。

令人费解的是，同样在ruby2.3.0下的另一个gemset,nokogiri 1.8.2可以顺利安装。

网上搜了一圈后，找到了解决办法。记录如下:

设置bundle config，编译nokogiri时，使用系统xml2路径即可。

1

bundle config build.nokogiri --use-system-libraries --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/libxml2

还有一个更简单的方法，自动根据系统版本得到系统libxml2的路径

1

bundle config build.nokogiri --use-system-libraries=true --with-xml2-include="$(xcrun --show-sdk-path)"/usr/include/libxml2

参考资料: Installation of nokogiri fail with bundle on macOS Sierra 10.12

nginx 444

介绍

当没有显式指定default server的时候，Nginx会使用第一个server来作为默认的响应server，即使请求的Host并没有匹配到server_name。
这是为了兼容老旧的一些不带Host的HTTP请求而做的设置。官文描述: How nginx processes a request

此时可能存在一定的风险。如果有非备案的名解析到了你的Public IP上，而你的Web服务对该域名的请求有所响应的话，可能会导致Public IP被运营商封锁。

解决办法:

在nginx中添加一个default server，并在default server中设置return 444;。此时Nginx就不会响应请求，除非请求的Host是配置的。

问题点

一直使用的是Amazon自有的Amazon Linux，中国区的C5出来后，将原有的机器升级到C5的时候，发现额外挂载的磁盘没有挂载成功。

调查了一下，C5系列属于Nitro-based instance, EBS卷默认使用的是NVMe driver,设备名由原来C4的/dev/xvda1和/dev/xvdf变为了/dev/nvme[0-26]n1的格式。官网说明Device Naming on Linux Instances。

以前C4的机器中,/etc/fstab中设定的另外一块EBS的挂载点是/dev/xvdf, 所以导致了换用C5的时候，没能自动挂载。

1
2

# C4时的设置
/dev/xvdf   /mnt/data ext4  auto,nofail,defaults        1   2

解决办法

lsblk查看EBS的挂载路径，然后修改/etc/fstab。解决了问题。

1

/dev/nvme1n1 /mnt/data ext4  auto,nofail,defaults        1   2

背景

有一个通知服务，需要使用Mandrill的提供的邮件服务给客户发送邮件。开发时使用了mandrill_mailer这个GEM来实现和Mandrill服务的交互。

今天监控程序报警提及昨天的邮件发送量比平时低了不少。上线查了一下日志，发现是代码中一处exception没处理好,导致程序崩溃了。

分析

Ruby 中捕获非指定类型的异常，会使用如下方式来捕获异常。

1
2
3

begin
rescue => e
end

背景

在AWS Elastic Beanstalk中，如果选用Ruby with Passenger运行Rails时，会遇到一个问题，就是EB环境中的Passenger的max_pool_size是默认的6。如果EB中的Instance选用的是性能比较高的类型，只起6个Passenger进程会是一个巨大的浪费。下面介绍几个修改EB中Passenger max_pool_size参数的方法。

Passenger官方说明

最新的官方Introduction to configuring Passenger Standalone文档中，Passenger Standalone可以通过如下几种方式来修改启动参数

• 一、传递参数给启动命令passenger start
• 二、使用环境变量(从5.0.22开始)
• 三、通过配置文件Passengerfile.json

使用EB Passenger with Ruby部署rails时，如果是以默认配置启动，没有做对应的配置，在ASG Scale Up的时候，可能会有请求没法正常处理，返回404。

原因

1. EB中创建的ELB，默认是使用TCP:80的方式来检查Instance的健康状态的。
2. ELB的health check的默认Interval是10 seconds，Healthy threshold是3 requests。
3. 当ASG Scale Up时，新建的Instance中Passenger在Rails APP部署完成之前就已经在监听80端口了。
4. Passenger启动30秒之后，因为超过了Healthy threshold * Interval的时间, 并且每次检查都是OK的，ELB会判定Instance是可用的，就会将流量导入到该Instance中。
5. 但此时rails APP可能并没有部署完成(bundle install加上precompile，部署一个新的APP可能需要5分钟左右)，所以client会得到404的错误。

背景介绍

公司一个ReactOnRails的项目，之前一直都是跑的好好的。上次一个小修改后，发布预编译React代码的时候，屡次出现FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory 的错误。

调查

项目使用的是webpacker打包js代码，一开始是以为webpacker的问题，调查了一圈下来，最终发现是node中V8的限制。默认情况下，在64位系统下内存使用是有限制的，有一说是1.4GB，有一说是1.76GB。但在node官网搜了一圈也没找到明确说现在的限制是多少。

在浏览器中使用AWS的SDK直接上传文件到S3时，需要在S3 Bucket上配置CORS才能成功上传，否则ajax请求会被浏览器拦截。

普通CORS访问配置

官方文档Cross-Origin Resource Sharing (CORS)中提供了开启CORS的范例，摘录如下:

起因

公司有一个项目，部署有多个AWS环境，但由于一系列复杂的原因，需要先在账号A下备案的域名来使用在账号B中部署的服务，后续再将域名备案转到账号B中。
临时的解决办法就是在账号A下起一个Instance，通过Nginx反向代理到账号B的一个Classic ELB中。

起初服务跑的很顺畅，后来一天突然服务不可用，页面显示504 Gateway Timeout，查看了Nginx的日志，发现有多条upstream timed out (110: Connection timed out) while connecting to upstream的错误日志。