I recently implemented Capistrano for the first time with a new cloud production environment. When I run cap deploy, everything seems to work fine. I can visit my live application in the browser, but my static files seem to load very slowly (like 5.0-12.0s).
See answer for clarity on config.assets.compile.
Static files load slowly because they possibly are not static, but are being served by Sprockets.
Check in production.rb and see if config.assets.compile = true or it is not set. That would mean that Sprockets is doing the work. You would also see far-future headers being used.
Have a look in /home/my_user/my_app/current/public and see if assets exists; I suspect it does not.
That means that mkdir -p is not working. The most likely cause is that the deploy user does not have sufficient permissions to create the directory.
Fix that, and also check (if this is an upgraded app from 3.0 or before) that your config setting match those in the last section of the pipeline guide.
Related
while setting up a basic 1 x NGINX load-balancer in front of 2 backends, I ended up in what it is clear to me to be a bug: the cron of this Certified App cannot be edited:
As you can see, in this particular App the cron file is owned by root:root and doesn't have the extended attribute (the plus on the right of permissions) necessary for the file to be edited also by the logged in user (nginx in this case).
All other certified apps allow instead the main login user to have crontabs, even though I found the permissions of each file vary a lot.
I've stumbled on https://github.com/jelastic/jem/blob/master/etc/jelastic/export.conf and it seems the file to go for proposing a bugfix, but it's last update if Aug-2016, so I guess Jelastic had closed much of its source code.
How can we contribute to Certified App source code?
indeed it is a bug as cron file of nginx user isn't editable in a balancer template, by design in has to be.
As for exports.conf - this file left for backwards comparability, but no more used.
The problem will be definitely fixed in latest templates, as for existing containers - we would like to apply a patch to fix them, if you provide us more details about hosting service provider you are using - we will help with that.
As for contribution to certified templates, all the images are publicly available on Docker Hub, you can create your own version of template based on existing one if you build a docker image and in your Dockerfile you specify
"from jelastic/nginxbalancer" as a base, then you can do any modifications to the filesystem. Next step will be just to replace existing balancer with your custom one.
Anyway, let's start with fix of existing containers.
Many thanks for finding out the bug!
So, I've deployed a Java web application (myapp.war) to a Tomcat 7 server that happens to be running on Amazon EC2. I noticed that, when I do this, it overwrites a similarly-named directory called myapp when I deploy. I further realized that the app is actually being served from that myapp directory and, when I directly make a change to a file in that directory, the changes are served to the client as expected.
My question is does Tomcat do anything to this directory between redeployments? If I make a small change in a file in that directory, will it ever be overwritten before I redeploy again?
It depends.
Changes to class files will probably be ignored.
Changes to JSPs may take effect depending on if the JSP has already been accessed and if the JSP Servlet is configured to check for changes.
Changes to static files will probably take effect but may be delayed by the effects of the static file cache. Normally that delay is only a few seconds but it can be configured to be longer.
Editing web.xml will probably trigger a reload (again this can be disabled with config)
Editing contex.xml will probably trigger a redeploy.
A reload pauses the app, re-reads web.xml and unpauses the app so the user might see a short pause but no 404s. A redploy completely removes the old app and creates a new one. A user may see a 404 in they try accessing it at the wrong time.
As soon as a new WAR file is deployed, all local changes will be lost.
I'm trying to setup my app to serve assets over the Amazon S3/Cloudfront CDN. Its a rails app and I use the asset_sync gem to achieve this as per this heroku document.
I push my project up to heroku, and then afterwards run a heroku run rake assets:precompile. This gives me output that looks like this:
I, [2013-09-20T21:19:06.506796 #2] INFO -- : Writing /app/public/assets/application-cb6347d3ce9380e02c37364b541fd8ae.js
I, [2013-09-20T21:19:19.979570 #2] INFO -- : Writing /app/public/assets/application-9dc3068c1bf9290c7eb0493fd36b3587.css
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
Take note that the hash it writes for the JS file cb6347d3ce9380e02c37364b541fd8ae.js is correct (as I also ran this in staging under my localhost).
The problem though, is that when I hit my app on heroku and inspect the source, the JS that it is including 50460076f4c6eb614a44b6b17323efa7.js is different than the one that was compiled earlier...
Why isn't heroku picking up the right precompiled asset to use? I deployed locally and did all the same steps, my local server picks up the correct JS with no problem.
Thanks for your help!
After some time, I realized that this was because previously I had compiled assets locally and pushed it up. Because of this, Heroku didn't try to precompile in production and just used the old manifest.json that was previously checked in.
You can either recompile locally and push it up, or run rake assets:clobber to delete all precompiled assets, then commit/push and heroku will realize that it needs to precompile. Afterwards, it should be using the correct manifest file and assets should show as normal.
I found this blog post really useful in understanding the situation: http://www.rubycoloredglasses.com/2013/08/precompiling-rails4-assets-when-deploying-to-heroku/
I generated the default RoR application with the rails new <project_name> command, and everything seemed to go fine. Later I decided I wanted to relocate my rails projects in a different directory (something other than my home directory), so I moved the RoR project to /opt/rails/<project_name> and I created a symlink in my web root pointing to /opt/rails/<project_name>/public, and the page loads fine, but some of the assets aren't loading on the Welcome aboard page, i.e. the rails.png And when I go to click on the About your application's environment link I get a 404 error. If I had to take a guess as to why I'm getting these errors it would have to be that I moved the rails app simple_cms from /home/user/www/rails/simple_cms to /opt/rails/simple_cms Is there a command I need to issue in the project root of simple_cms to get things fully working?
Update
I'm using Apache 2 as the web server on a CentOS 5.9 box.
If you are using rails s to launch your app, then there is no need to create symlinks. The web server (could be WEBrick, or Thin) will serve the application from the app root.
If you are using Apache or Nginx, again there is no need to create symlinks, but you need to let Apache/Nginx know the new location. For example, in a Nginx+Passenger setup, you would need to set passenger_app_root to the new location.
Provide more details in your question, or consult the documentation for your setup.
After wrestling with heroku for about a week and passing through various barriers to get it working (barriers to a newbie, I definitely don't fault heroku) I finally got my app running on it. One of the steps I had to adjust was precompiling my assets
bundle exec rake assets:precompile
and making some changes to the production environment in production.rb ...
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = true
Unfortunately this breaks a number of js behaviors on my local site. Works fine on heroku though. The way I've been handling this is to just rollback my local copy to a point just before these changes, but I'd like to understand why it's breaking. And also is there an assets:decomplile? Basically how the hell does one reverse the polarity or whatever? I'm definitely trying to get more intimate with the assets pipeline, but in the meantime any help or insight would be greatly apprecitaed.
To remove the precompiled assets in your local copy you just need to run
rake assets:clean
If you still have issues, clean your browser cache