When I push new code from my Sinatra application to my production server, I am currently triggering a restart of passenger by touching tmp/restart.txt, which loads the new changes. The problem is that the site is essentially down for about 10 seconds during this process.
How can I setup my server so that I can completely avoid any downtime?
That is, I want the application to keep serving the old version of the code until the new code is completely loaded, and then to instantly switch to the new code.
Using shotgun or sinatra/reloader will not work here since this is a production environment. Finally, if the answer depends on the application server, I'd be interested in how to do it with both unicorn and passenger.
What you're looking for is rolling restarts. Phusion Passenger Enterprise supports this: http://www.modrails.com/documentation/Users%20guide%20Nginx.html#PassengerRollingRestarts
Related
I have a simple Sinatra application. When I launch it (rackup) locally, and I place a byebug breakpoint, then I can see and interact with bye bug when that spot is reached in the code.
When I deploy that same app on heroku, I have problems:
Using heroku logs -t I can see the output of the server as it runs, and when it hits the break point, I can see it but not interact with it.
Using heroku run irb I can run an interactive rib session but it is not of the running server.
I think this must be possible but I cannot find it documented anywhere.
I highly doubt this is possible.
When you run "heroku run irb", you are spinning up and interacting with a Heroku one-off dyno.
The one-off dyno is a completely separate VM, that has no connection (out of the box) with the dyno(s) running your Sinatra app.
You can check on Heroku Elements to see if there might be add-ons to enable you to debug your running Sinatra app, but out of the box, I don't think you can run an interactive irb session against it.
How does the NewRelic agent know how many instances are running or how much RAM the app is using?
I'm wondering how it can glean so much without running an agent on the system as I thought you could only run your application code on Heroku, and not just any process?
I'll assume you're referring to Ruby, but the agent is not actually different on Heroku except for some accounting integrations due to New Relic/Heroku partnerships.
If you're using the New Relic Add-On for Heroku, the memory usage displayed in the "Instances" tab is an average per process.
New Relic will only track the instances that are being used by the app in the time window that you select.
Is there any potential downtime when I do a commit to a clojure/Java app running on Heroku?
I am guessing not - but can't find out for sure.
Thanks.
When you push to Heroku, you invoke the slug compiler, which does all the heavy lifting needed to turn your application into a self-contained archive. That can take a little while, as you see whenever you run git push. However, during this time, your application is running normally.
When your slug finishes compiling, Heroku then pushes it out to the dyno grid. This causes existing web dynos to stop and causes new ones to start. Your application will be unresponsive between the time that the old dynos stop and the new ones begin serving requests -- probably only a few seconds. During this interval, Heroku's routing layer will queue incoming requests.
TL;DR: users might notice a pause (but not an error!) as your application is updated. You can simulate this at any time by running heroku restart.
i am new to heroku and node.js. i have a small node.js app which i can start and run successfully on my local machine using FOREMAN from the heroku toolbelt. i do not understand how to best debug the app, though.
i see that there is an eclipse debugger for node.js as well as the node-inspector project. but i cant seem to make these work with FOREMAN.
foreman start
if it is not possible to debug an app started by foreman, what is the purpose of foreman?
Just an addition, your Procfile could look like this:
web: node web.js
webDebug: node --debug-brk=5858 web.js`
So to start debugging you just call foreman start webDebug, you could call the configuration however you want.
The debugger will listen on port 5858 and you'll have to call your app from http://localhost:5100 instead of http://localhost:5000.
The purpose of Foreman is to allow you to run complex applications, which may consist of several processes, easily. Check out the author's blog post on Foreman:
Lately I've noticed my web apps are getting complicated to run. My
apps no longer consist of a single web process; I usually have have
one or more types of background workers to run different types of jobs
and a clock process to handle scheduling. Splitting an app up in this
way is great for performance and scalability. The downside, however,
is that it becomes much more complicated to get the app and all of its
parts running.
Foreman is an attempt to make this easier. Using foreman you can
declare the various processes that are needed to run your application
using a Procfile.
By leveraging Foreman, Heroku has made it so that you can essentially run any kind of process you want to--a Rails app, a Sinatra app, a Node.js app, or anything else--simply by specifying how to start it in your Procfile, which Foreman reads and executes.
Foreman also allows you to take this simple Procfile and export it to production environments using tools like Upstart and Init. It does not provide any debugging functionality (nor is it meant to).
I'm working in a new Rails engine and I need to restart it while testing. Of I try Dummy::Application.initialize! it do not work because the application was already initialized, so Rails returned the same instance.
I need to do so my engine after_initialize block runs again>
I do not believe that Rails::Application has any (at least publicly accessible) method for restarting the stack. Your best way (and what I do) is just exit the server process (Control + C) and rails s the server back up.
If that is not what you are talking about, please be more specific on the error and situation you are in.
ref: http://railsapi.com/doc/rails-v3.0.7/classes/Rails/Application.html