{"id":1128,"date":"2017-03-24T19:33:18","date_gmt":"2017-03-25T02:33:18","guid":{"rendered":"http:\/\/www.wiredatom.com\/blog\/?p=1128"},"modified":"2017-03-24T19:41:49","modified_gmt":"2017-03-25T02:41:49","slug":"websockets-from-ember-rails-nginx-with-aws-elasticache-redis","status":"publish","type":"post","link":"https:\/\/www.wiredatom.com\/blog\/2017\/03\/24\/websockets-from-ember-rails-nginx-with-aws-elasticache-redis\/","title":{"rendered":"WebSockets from Ember, Rails, Nginx with AWS ElastiCache Redis"},"content":{"rendered":"

\"\"<\/p>\n

When we finally upgraded our Rails application to v5, plans were put in place to take advantage of its WebSockets capabilities.<\/p>\n

Locally on development machines, things seem to chug along smoothly until it all broke down on our staging stack.<\/p>\n

Here’s the basic setup:<\/p>\n

* Rails 5.0.x
\n* Ember 2.x (using Ember Cable<\/a> for WebSockets)
\n* Puma
\n* Nginx (for reverse proxying Ember calls to Rails + serving Ember app)
\n* AWS ElastiCache Redis
\n* Postgres hosted on AWS RDS
\n* EC2 instance + ELB + custom security group… etc.
\n* Entire stack is orchestrated with Chef running on AWS OpsWorks<\/p>\n

I didn’t think the set up was anything out of the ordinary per se. The only exception is probably my choice of using ElastiCache instead of having an EC2 server running our own Redis instance (or having it hosted at Redis Labs or something). But other than that, it’s pretty vanilla.<\/p>\n

Immediately we rant into trouble having Ember making a proper connection. We kept seeing this error:<\/p>\n

WebSocket connection to 'ws:\/\/staging.domain.name\/cable'<\/span> failed: Connection closed before receiving a handshake response<\/div><\/div>\n

First thing first, we had to make sure our \/cable<\/span><\/code> endpoint was proxied properly so that Rails can answer the calls. So in our main Nginx config file, we added:<\/p>\n

1
2
3
4
5
6
7
8
9
10
<\/div><\/td>
location \/<\/span>cable {<\/span>
\n    proxy_set_header   X-Real-IP $remote_addr<\/span>;
\n    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for<\/span>;
\n    proxy_set_header   Host $http_host<\/span>;
\n    proxy_set_header   Upgrade $http_upgrade<\/span>;
\n    proxy_set_header   Connection "Upgrade"<\/span>;
\n    proxy_redirect     off;
\n    proxy_http_version 1.1<\/span>;
\n    proxy_pass         http:\/\/<\/span>app_server;
\n}<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

It still didn’t quite work.<\/p>\n

1
2
3
4
5
<\/div><\/td>
I, [<\/span>2017<\/span>-03-22T18:46<\/span>:39.166623<\/span> #4175]  INFO -- : Started GET "\/cable" for 127.0.0.1 at 2017-03-22 18:46:39 +0000<\/span>
\nI, [<\/span>2017<\/span>-03-22T18:46<\/span>:39.167699<\/span> #4175]  INFO -- : Started GET "\/cable\/" [WebSocket] for 127.0.0.1 at 2017-03-22 18:46:39 +0000<\/span>
\nE, [<\/span>2017<\/span>-03-22T18:46<\/span>:39.167837<\/span> #4175] ERROR -- : Request origin not allowed: https:\/\/staging.domain.name<\/span>
\nE, [<\/span>2017<\/span>-03-22T18:46<\/span>:39.167950<\/span> #4175] ERROR -- : Failed to upgrade to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE:)<\/span>
\nI, [<\/span>2017<\/span>-03-22T18:46<\/span>:39.168064<\/span> #4175]  INFO -- : Finished "\/cable\/" [WebSocket] for 127.0.0.1 at 2017-03-22 18:46:39 +0000<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Obviously we need to specify in Rails that our Staging subdomain, along with its https<\/span><\/code> protocol should be allowed. So we added that to our Rails \/config\/environments\/staging.rb<\/span><\/code> file.<\/p>\n

config.action_cable<\/span>.allowed_request_origins<\/span> = %<\/span>w(<\/span>https:\/\/<\/span>staging.domain<\/span>.name<\/span> staging.domain<\/span>.name<\/span>)<\/span><\/div><\/div>\n

Once we squared that away, we were still left with that dreadful error on line #4 above.<\/p>\n

Failed to upgrade to WebSocket (<\/span>REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE:)<\/span><\/div><\/div>\n

Somehow, the $http_upgrade<\/span><\/code> variable in Nginx is simply not being set despite browser’s request. As it turns out, WebSocket traffic isn’t quite HTTP\/HTTPS. The devil is in the details of the AWS ELB (load balancer).<\/p>\n

\"\"<\/p>\n

I simply swapped out HTTPS<\/span><\/code> with SSL<\/span><\/code>. And BOOM!<\/strong> Like that, it worked:<\/p>\n

Successfully upgraded to WebSocket (<\/span>REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE: websocket)<\/span><\/div><\/div>\n

Now connection was being made properly. Except for this one little thing: The browser had to keep reinitialize the connection every few seconds. And we noticed the UI simply wasn’t being updated despite changes to data. Sigh…<\/p>\n

Next stop was to test if the EC2 instance itself was actually talking to AWS ElastiCache. There are a couple of ways to try this:<\/p>\n

In Rails:<\/p>\n

1
2
3
4
5
<\/div><\/td>
irb(<\/span>main)<\/span>:001:0<\/span>><\/span> redis = Redis.new(<\/span>:host =><\/span> 'my-elasticache-instance-identifier.0001.usw2.cache.amazonaws.com'<\/span>, :port =><\/span> 6379<\/span>)<\/span>
\n=><\/span> #< redis client v3.3.3 for redis:\/\/my-elasticache-instance-identifier.0001.usw2.cache.amazonaws.com:6379\/0><\/span>
\nirb(<\/span>main)<\/span>:002:0<\/span>><\/span> redis.ping
\nRedis::CannoConnectError: Error connecting to Redis on my-elasticache-instance-identifier.001.usw2.cache.amazonaws.com:6379<\/span> (<\/span>Redis::TimeoutError)<\/span>
\n...<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Using Telnet:<\/p>\n

1
2
3
<\/div><\/td>
$ telnet my-elasticache-instance-identifier.0001.usw2.cache.amazonaws.com 6379<\/span>
\nTrying \/<\/span>ip<\/span> ADDRESS\/<\/span>...
\n# eventually times out<\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

OMFG. WHAT ELSE IS WRONG NOW??!!<\/p>\n

As it turns out, the devil, again, is in the details. This time, it’s in AWS Security Groups.<\/p>\n

AWS resources are only allowed to talk to each other if said resources are within the same security groups (among other things). In this case, AWS ElastiCache has a default<\/span><\/code> security group, which we’re not allowed to change (not to my knowledge anyway). So the trick was to make sure that our OpsWorks Layers<\/span><\/code> also have been assigned the default<\/span><\/code> security group. Now, OpsWorks documentation says that you must reboot each instance within the layer for the new security group settings to kick in. But the truth is I had to spawn brand new instances for the new security group to stick. But once that was done, everything finally started to gel:<\/p>\n

1
2
3
4
5
6
<\/div><\/td>
irb(<\/span>main)<\/span>:001:0<\/span>><\/span> redis = Redis.new(<\/span>:host =><\/span> 'my-elasticache-instance-identifier.0001.usw2.cache.amazonaws.com'<\/span>, :port =><\/span> 6379<\/span>)<\/span>
\n=><\/span> #<redis client v3.3.3 for redis:\/\/my-elasticache-instance-identifier.0001.usw2.cache.amazonaws.com:6379\/0><\/span>
\nirb(<\/span>main)<\/span>:002:0<\/span>><\/span> redis.ping
\n=><\/span> "PONG"<\/span>
\n...
\n<\/<\/span>redis><\/span><\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

I hate technology sometimes.<\/p>\n

References:
\n* https:\/\/blog.jverkamp.com\/2015\/07\/20\/configuring-websockets-behind-an-aws-elb\/ (cached in PDF<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":"

When we finally upgraded our Rails application to v5, plans were put in place to take advantage of its WebSockets capabilities. Locally on development machines, things seem to chug along smoothly until it all broke down on our staging stack. Here’s the basic setup: * Rails 5.0.x * Ember 2.x (using Ember Cable for WebSockets) … Continue reading “WebSockets from Ember, Rails, Nginx with AWS ElastiCache Redis”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[21,10,14],"tags":[],"class_list":["post-1128","post","type-post","status-publish","format-standard","hentry","category-coding","category-geek-stuff","category-linuxunix"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p54IqZ-ic","_links":{"self":[{"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/posts\/1128","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/comments?post=1128"}],"version-history":[{"count":0,"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/posts\/1128\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/media?parent=1128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/categories?post=1128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wiredatom.com\/blog\/wp-json\/wp\/v2\/tags?post=1128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}