search

abernix / meteord

MeteorD - Docker Runtime for Meteor Apps for Production Deployments
https://registry.hub.docker.com/u/meteorhacks/meteord/
MIT License
93 stars 129 forks source link

Is there a way to not install phantomjs on the image? #5

Closed jamesgibson14 closed 7 years ago

jamesgibson14 commented 8 years ago

With the recent updates to the image, my installs are taking a lot longer. I think I tracked it down to the install of PhantomJs, it even cause my small 500mb machine to run out of memory and I had to create a swap file to get the install to even finish. here is some code from mupx reconfig in installed Phantom again: 

Considering` PhantomJS found at /usr/local/bin/phantomjs
Found PhantomJS at /usr/local/bin/phantomjs ...verifying
PhantomJS detected, but wrong version 1.9.8 @ /usr/local/bin/phantomjs.
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.

Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
Receiving...

Everything worked fine 3 days ago.

abernix commented 8 years ago

Thanks for reporting this. PhantomJS has always been installed and I haven't bumped the version at all. The changes are listed here (I'd recommend looking at the "Files Changed" as I made many back-and-forth revert commits in testing).

The most notable change was the bumping of Node from 4.4.7 to 4.6.2 because of this. This was the main reason for the change. However, I also added g++ (7d705737c399ae608fec28db479d482ead60cdeb) as it necessary to compile some binary packages.

But overall, yes, the image is slightly larger, just going over 500mb uncompressed and your intuition about size is probably at play. I will say though, that is an extremely small size to have a machine configured for and I did not anticipate that.

I just tried rebuilding the old image (without g++ and with the previous Node 4.4.7), but it also resulted in a larger image (just over 500MB instead of the ~450MB before), so it seems Debian dependencies have grown in size. Unfortunately, there isn't much I can do about this and I won't be able to look at the problem specifically.

You can try using the appropriate abernix/meteord:node-4.4.7:* image (which should be the previous version you were using) explicitly and see if the problem goes away, but I really wouldn't recommend using an older version of Node if you can avoid it – there were some critical security updates between 4.4.7 and 4.6.2.

If you can score an extra 30-50MB of memory on your server, you might see this go away.

As an alternative, and hopefully better plan, I've created a new abernix/spaceglue image, which while not thoroughly tested yet works for me and might work for you. I've made a lot of improvements (not very well documented, yet, I'm sorry) but I no longer include PhantomJS in that image (you can install it yourself by having phantomjs-prebuilt in your package.json. The base image image 40% smaller though unless you're running mup deploy from a Debian Jessie 64-bit box, you will need to use the larger builddeps image which can recompile your binary dependencies.

Unfortunately, if you want to use it you'll need to update from mupx to kadirahq's mup (you should do this anyway) and kadirahq/meteor-up#383 will need to be merged as my image exposes a non-privileged port (port 3000) instead of port 80 (for security reasons).

jamesgibson14 commented 8 years ago

Thanks for these great ideas, I will try them out and see if one works better than my current setup. I havent upgraded to mup yet because it doesnt let me set unique env variables per server.

On Nov 24, 2016 2:34 AM, "Jesse Rosenberger" notifications@github.com wrote:

Thanks for reporting this. PhantomJS has always been installed and I haven't bumped the version at all. The changes are listed here https://github.com/abernix/meteord/compare/node-4.4.7...abernix:node-4.6.2 (I'd recommend looking at the "Files Changed" as I made many back-and-forth revert commits in testing).

The most notable change was the bumping of Node from 4.4.7 to 4.6.2 because of this https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/. This was the main reason for the change. However, I also added g++ ( 7d70573 https://github.com/abernix/meteord/commit/7d705737c399ae608fec28db479d482ead60cdeb) as it necessary to compile some binary packages.

But overall, yes, the image is slightly larger, just going over 500mb uncompressed and your intuition about size is probably at play. I will say though, that is an extremely small size to have a machine configured for and I did not anticipate that.

I just tried rebuilding the old image (without g++ and with the previous Node 4.4.7), but it also resulted in a larger image (just over 500MB instead of the ~450MB before), so it seems Debian dependencies have grown in size. Unfortunately, there isn't much I can do about this and I won't be able to look at the problem specifically.

You can try using the appropriate abernix/meteord:node-4.4.7:* image https://hub.docker.com/r/abernix/meteord/tags/ (which should be the previous version you were using) explicitly and see if the problem goes away, but I really wouldn't recommend using an older version of Node if you can avoid it – there were some critical security updates between 4.4.7 and 4.6.2.

If you can score an extra 30-50MB of memory on your server, you might see this go away.

As an alternative, and hopefully better plan, I've created a new abernix/spaceglue https://github.com/abernix/spaceglue image, which while not thoroughly tested yet works for me and might work for you. I've made a lot of improvements (not very well documented, yet, I'm sorry) but I no longer include PhantomJS in that image (you can install it yourself by having phantomjs-prebuilt in your package.json. The base image image 40% smaller though unless you're running mup deploy from a Debian Jessie 64-bit box, you will need to use the larger builddeps image which can recompile your binary dependencies.

Unfortunately, if you want to use it you'll need to update from mupx to kadirahq's mup https://github.com/kadirahq/meteor-up (you should do this anyway) and kadirahq/meteor-up#383 https://github.com/kadirahq/meteor-up/pull/383 will need to be merged as my image exposes a non-privileged port (port 3000) instead of port 80 (for security reasons).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/abernix/meteord/issues/5#issuecomment-262730599, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuPKvrRzqENj8Wne1yzch95vVl7mUgWks5rBVoVgaJpZM4K7Hyn .