AWS OpsWorks, Meteor, Docker Deployment

So, I got this up and going and I thought all was well. However, I’ve had some reports of some people getting 503’s. I used a wildcard in my VIRTUAL_HOST env var *.mydomain.com. WGET seems to confirm something’s amiss:

wget mydomain.com
--2015-04-15 22:31:27--  http://mydomain.com/
Resolving mydomain.com (mydomain.com)... 52.8.x.y
Connecting to mydomain.com (mydomain.com)|52.8.x.y|:80... connected.
HTTP request sent, awaiting response... 503 Service Temporarily Unavailable
2015-04-15 22:31:27 ERROR 503: Service Temporarily Unavailable.

Can anyone explain why this might be happening?

Also, I’d like to redir all www. requests to just mydomain.com. I assume I’d need to fork the nginx-proxy repo and make changes there? Or can I just inject the redir in the chef recipes?

TIA for any tips/advice!

anyone getting this problem while pushing to docker hub?

@skwasha It looks like you are not using any SSL certificate. Which repo are you using your chef recipes from? Also, if you want to redirect www requests, you can create a custom template from nginx-proxy that will have a 301 redirect in it.

@arjunrajjain not sure, but it looks like it’s an issue with Dockerhub itself?

The SSL certs are there and named mydomain.com.crt and key as stated in the docs… It redirects to SSL version of the site properly. I’m using your recipes.

I ended up changing the VIRTUAL_HOST entry to specify mydomain.com,www.mydomain.com and now it seems to be working. Not sure what was wrong when I had the wildcard in the VIRTUAL_HOST.

Anyone having problems with Cordova? For some reason my app is not refreshing when I deploy new applications, its using a cached version when I first deployed the app to the app store.

are you referring to the docker image? I was just gonna ask about that myself… Deploys seemed to be using an older image. I had to retag the latest and change the Env Vars to use the new tag to force a deploy of a newer image. This only seems to have cropped up in the last day or so. Was working fine previously.

@jkatzen having some issues starting a new server in on of my Docker stacks. I am trying to start the second instance in the stack and seems like it can’t find a file related to the Papertrail setup. Any ideas, let me know, please?

Here’s an excerpt from the logs:

================================================================================
Error executing action `run` on resource 'bash[docker-logspout]'
================================================================================
 
 
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of "bash"  "/tmp/chef-script20150418-4513-eweuka" ----
STDOUT: 31ebb8b2db3a144bb3630072547a99b164cf83db28dee976074b6978b2264107
STDERR: Unable to find image 'gliderlabs/logspout:latest' locally
Pulling repository gliderlabs/logspout
9187d5605e70: Pulling image (latest) from gliderlabs/logspout
9187d5605e70: Pulling image (latest) from gliderlabs/logspout, endpoint: https://registry-1.docker.io/v1/
9187d5605e70: Pulling dependent layers
511136ea3c5a: Download complete
c9fa955c112e: Pulling metadata
c9fa955c112e: Pulling fs layer
c9fa955c112e: Download complete
579f3ee47b59: Pulling metadata
579f3ee47b59: Pulling fs layer
579f3ee47b59: Download complete
0e0d60892003: Pulling metadata
0e0d60892003: Pulling fs layer
0e0d60892003: Download complete
4c67616736c8: Pulling metadata
4c67616736c8: Pulling fs layer
4c67616736c8: Download complete
3cb83935a9b3: Pulling metadata
3cb83935a9b3: Pulling fs layer
3cb83935a9b3: Download complete
9187d5605e70: Pulling metadata
9187d5605e70: Pulling fs layer
9187d5605e70: Download complete
9187d5605e70: Download complete
Status: Downloaded newer image for gliderlabs/logspout:latest
time="2015-04-18T21:14:46Z" level=fatal msg="Error response from daemon: Cannot start container 31ebb8b2db3a144bb3630072547a99b164cf83db28dee976074b6978b2264107: Error getting container 31ebb8b2db3a144bb3630072547a99b164cf83db28dee976074b6978b2264107 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-165113-31ebb8b2db3a144bb3630072547a99b164cf83db28dee976074b6978b2264107' on '/var/lib/docker/devicemapper/mnt/31ebb8b2db3a144bb3630072547a99b164cf83db28dee976074b6978b2264107': no such file or directory"
---- End output of "bash"  "/tmp/chef-script20150418-4513-eweuka" ----
Ran "bash"  "/tmp/chef-script20150418-4513-eweuka" returned 1
 
 
Cookbook Trace:
---------------
/var/lib/aws/opsworks/cache.stage2/cookbooks/lxc/libraries/monkey.rb:20:in `monkey_shell_out!'
 
 
Resource Declaration:
---------------------
# In /var/lib/aws/opsworks/cache.stage2/cookbooks/logspout/recipes/install.rb
 
33:     bash "docker-logspout" do
34:         user "root"
35:         code <<-EOH
36:             docker run -d --restart=always -h #{hostname} --name logspout -v /var/run/docker.sock:/tmp/docker.sock gliderlabs/logspout syslog://#{deploy[:environment_variables][:PAPERTRAIL_URL]}:#{deploy[:environment_variables][:PAPERTRAIL_PORT]}
37:         EOH
38:     end
39:     Chef::Log.info('docker-logspout stop')
40: end
 
 
 
Compiled Resource:
------------------
# Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/logspout/recipes/install.rb:33:in `block in from_file'
 
bash("docker-logspout") do
action "run"
retries 0
retry_delay 2
command "\"bash\"  \"/tmp/chef-script20150418-4513-eweuka\""
backup 5
returns 0
user "root"
code "            docker run -d --restart=always -h Buzzy-Docker-buzzy3 --name logspout -v /var/run/docker.sock:/tmp/docker.sock gliderlabs/logspout syslog://logs2.papertrailapp.com:<my-paper-trail-port>\n"
interpreter "bash"
cookbook_name "logspout"
recipe_name "install"
end
 

@jkatzen I did remove the space out of my layer name and it seems to have run now. I am not 100% sure this was the issue as I did have those transient issues in the past.

the deploys themself are working fine…but what is loaded on Cordova is not (its using the cached version of as when the app was updated on the appstore) -

@jkatzen back on this old topic re: " deploy a new instance that is not hooked up to your DNS" - does this need to be a separate app with a separate “cluster” configuration?

ie if I deploy “app1” to the instance, it’ll get added to the “app1” cluster, right? Not sure if any issues with this? Or should I have an “app2” that I deploy with a separate Cluster db and then once that’s up and running swap it?

Alternatively, I could have 2 stacks for app1 & 2 respectively.

So I think 3 options:

  1. deploy to new instance with same app/cluster config - then swap Elastic IP to point to new instance
  2. deploy to new instance with different app/cluster config - then swap Elastic IP to point to new instance
  3. deploy to separate stack with different app/cluster config - then swap Elastic IP to point to new instance

Any recommendations?

You want to deploy a new instance to the same app - you don’t have to do anything special as long as the cluster configuration is setup properly.

@jkatzen thanks. I am still getting random issues, so perhaps my setup is messed up.

UPDATE to the info below:
I think I know what happened and it had to do with swapping the IPs.
eg Server 1 - IP-addr-A (AWS dyamic address)
swap Server 2 to IP-addr-B (Elastic IP)

Somehere in the nginx settings it’s still referring to IP-addr-A which now no longer exists as it was originall a dynamic AWS IP.

Could that be possible?

------------orginal below ---------

Folk are experience sporadic “disconnection” and I see the following in the logs:

May 06 09:49:03 Buzzy-Docker-buzzy1 nginx-proxy:  nginx.1    | 2015/05/05 23:49:03 [error] 26#0: *5152 upstream prematurely closed connection while reading response header from upstream, client: <someones IP>, server: *.buzzy.buzz, request: "GET /_timesync HTTP/1.1", upstream: "http://<and internal amazon IP egg 172.something>/_timesync", host: "buzzy.buzz", referrer: "https://buzzy.buzz/l" 

I don’t have a server with the internal ip of <and internal amazon IP egg 172.something> and I don’t see it listed in my cluster database.

The weird things is, I don’t think I have changed any of my app settings when I deploy. So not sure why it’s not working?

I am not sure if this is related, but sometimes in my deploy logs I see the following:

================================================================================
Error executing action `run` on resource 'bash[docker-logspout]'
================================================================================
 
 
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of "bash"  "/tmp/chef-script20150505-15749-r7i4yu" ----
STDOUT: 14a0ebf9bd7700085849e058a658fe1f8afd345b5e5321c2f7dac3a58b0c1780
STDERR: time="2015-05-05T12:42:57Z" level="fatal" msg="Error response from daemon: Cannot start container 14a0ebf9bd7700085849e058a658fe1f8afd345b5e5321c2f7dac3a58b0c1780: Error getting container 14a0ebf9bd7700085849e058a658fe1f8afd345b5e5321c2f7dac3a58b0c1780 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-172158-14a0ebf9bd7700085849e058a658fe1f8afd345b5e5321c2f7dac3a58b0c1780' on '/var/lib/docker/devicemapper/mnt/14a0ebf9bd7700085849e058a658fe1f8afd345b5e5321c2f7dac3a58b0c1780': no such file or directory"
---- End output of "bash"  "/tmp/chef-script20150505-15749-r7i4yu" ----
Ran "bash"  "/tmp/chef-script20150505-15749-r7i4yu" returned 1
 
 
Cookbook Trace:
---------------
/var/lib/aws/opsworks/cache.stage2/cookbooks/lxc/libraries/monkey.rb:20:in `monkey_shell_out!'
 
 
Resource Declaration:
---------------------
# In /var/lib/aws/opsworks/cache.stage2/cookbooks/logspout/recipes/install.rb
 
33:     bash "docker-logspout" do
34:         user "root"
35:         code <<-EOH
36:             docker run -d --restart=always -h #{hostname} --name logspout -v /var/run/docker.sock:/tmp/docker.sock gliderlabs/logspout syslog://#{deploy[:environment_variables][:PAPERTRAIL_URL]}:#{deploy[:environment_variables][:PAPERTRAIL_PORT]}
37:         EOH
38:     end
39:     Chef::Log.info('docker-logspout stop')
40: end
 
 
 
Compiled Resource:
------------------
# Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/logspout/recipes/install.rb:33:in `block in from_file'
 
bash("docker-logspout") do
action "run"
retries 0
retry_delay 2
command "\"bash\"  \"/tmp/chef-script20150505-15749-r7i4yu\""
backup 5
returns 0
user "root"
code "            docker run -d --restart=always -h Buzzy-Docker-buzzy1 --name logspout -v /var/run/docker.sock:/tmp/docker.sock gliderlabs/logspout syslog://logs2.papertrailapp.com:<SOMEPAPERTRAILPORT>\n"
interpreter "bash"
cookbook_name "logspout"
recipe_name "install"
end
 
 
 
[2015-05-05T12:42:58+00:00] INFO: Running queued delayed notifications before re-raising exception
[2015-05-05T12:42:58+00:00] ERROR: Running exception handlers
[2015-05-05T12:42:58+00:00] ERROR: Exception handlers complete
[2015-05-05T12:42:58+00:00] FATAL: Stacktrace dumped to /var/lib/aws/opsworks/cache.stage2/chef-stacktrace.out
[2015-05-05T12:42:58+00:00] ERROR: bash[docker-logspout] (logspout::install line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'

If I run it again, it usually just works, no error

Hey adam - sorry I’ve been less responsive lately; been lurking a bit less. In any case - I think your instinct is probably right. To amend it, what you could probably do is run the chef recipe that will re-launch your nginx server on the instance after you swap the IP’s.

@jkatzen thanks. Yep, yet to try that out as I am now using the failover approach. I may switch back to that depending on how long that recipe takes to run.

1 Like

@jkatzen @arunoda how goes? Hoping for some quick help please - where is the bundle installed in the docker container pls?

I need to set the BUNDLE_PATH for this package I am using. Their hint is it would be something like ‘/var/www/app/bundle’

Please see their ‘tldr;’ section for more info, if needed

If you’re using the new meteord image to build yours, then I think it’s in the /built_app directory.

Here’s the script that bundles the meteor application:

1 Like

Thanks @jkatzen much appreciated

Update: I rolled back to cluster 1.6.4 and this error goes away. - I have logged here https://github.com/meteorhacks/cluster/issues/67

Hi, Anyone having any recent issues with this… not sure of meteord changed again, I don’t think I have changed anything and I am now getting the following issues:

Mixed Content: The page at 'https://<my domain>/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://172.31.<AWS internetl IP>:8080/cluster-ddp/4e2d65a488d5e5077c856136179743e6ddca5ab7/web/532/bel3gonh/websocket'. This request has been blocked; this endpoint must be available over WSS.T.websocket @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32T._try_next_protocol @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32T._didClose @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32o._ir.onfinish @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32a.emit @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32X.doXhr.a.onfinish @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32a.emit @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32w._start.a.xhr.onreadystatechange @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32
b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32 Uncaught SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.T.websocket @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32T._try_next_protocol @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32T._didClose @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32o._ir.onfinish @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32a.emit @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32X.doXhr.a.onfinish @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32a.emit @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32w._start.a.xhr.onreadystatechange @ b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32
b570b0fd4bc634ecb0d4c6d9be8527ae6dd6d064.js:32 Mixed Content: The page at 'https://<EXTERNAL IP>/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://172.31.<AWS INTERNAL IP>:8080/cluster-ddp/4e2d65a488d5e5077c856136179743e6ddca5ab7/web/532/4lhusb7k/xhr'. This request has been blocked; the content must be served

Great tutorial I am currently in the process of working my way through it. However, I ran into a odd error. For some reason my local docker box is unable to install meteor. This is the error I receive

Sending build context to Docker daemon   259 MB
Sending build context to Docker daemon 
Step 0 : FROM meteorhacks/meteord
# Executing 2 build triggers
Trigger 0, COPY ./ /app
Step 0 : COPY ./ /app
 ---> Using cache
Trigger 1, RUN bash $METEORD_DIR/on_build.sh
Step 0 : RUN bash $METEORD_DIR/on_build.sh
 ---> Running in 357a399dde95
curl: (6) Couldn't resolve host 'install.meteor.com'
/opt/meteord/lib/build_app.sh: line 11: meteor: command not found
INFO[0033] The command [/bin/sh -c bash $METEORD_DIR/on_build.sh] returned a non-zero code: 127 

Any ideas? @jkatzen

@adamgins Looks like your web socket connection and your http connection to your client are not the same - while one is being loaded over SSL, the websocket connection does not look like it is being supplied over a secure connection as well.

@patrickwml curl: (6) Couldn't resolve host 'install.meteor.com' - looks like when you were trying to build your image, your machine could not connect to the meteor install servers.