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.
Related
I want to get info from twitter for my project, I'm using tweetstream gem, and it works in my code, but I need it to be done as a background process in heroku as a script. So I'm using Event Machine gem to do so, and it works in my computer, but I haven't been able to make it run on heroku on it's own.
I've read that I need to use the Procfile and say it is a worker process, but I can't make it work, but on my local it works fine.
I'm new to background process and working with servers.
Heroku dynos do not support background processes in the "free" or "hobbyist" tiers.
Here is the Heroku Documentation on Background Jobs.
It costs about $30 bucks a month to add this on. There is other implementation hurdles to overcome with a local server vs. Heroku with background jobs. The best starting point I can give you is that Heroku does not support background jobs by default. You have to "Scale the worker dynos"
I've tried googling and stackoverflowing this and all I get is links back to the API reference or examples of scaling dynos, which is not what I want.
heroku run:detached is great as it just spins up a dyno with your app, runs whatever you want, then spins down the dyno.
How do I achieve the exact same things but using the Heroku Platform API?
I've seen people mention you have to use the Dyno endpoint on the API, but how? Can someone offer an exact example of how I would run the following from the API?
$ heroku run:detached --size 2x rake my_task.rb
You can use the platform API to to this, and create a dyno.
See https://devcenter.heroku.com/articles/platform-api-reference#dyno-create
By sending a POST request to /apps/your_app_name/dynos with the following parameters:
command, the command you wich to run.
attach, set it to false.
This will create a one-off dyno and detach it.
This is what the toolbelt does when you run the run:detached command. You can see how it works here: https://github.com/heroku/heroku/blob/01cd753570cb62b917843112fb29d1cdd43ba335/lib/heroku/command/run.rb#L65
I'm trying to deploy a ruby (NOT rails) app to Heroku. My procfile is laid out like so:
console: bundle exec ruby main.rb
However, my app never actually launches. The logs on the system are all quiet, I see nothing resembling any error output.
If I run the command as shown in the procfile on my local system, my program launches and runs exactly as it should.
More interestingly, if I run heroku console, the app immediately fires up on the console itself. Looks like some interaction with the procfile? How do I launch my app automatically without being connected to the console on Heroku and have the stdout captured?
If you want the console entry to run, you need to scale it:
$ heroku ps:scale console=1
That said, Heroku uses console to mean "the thing that I use to perform certain interactive administrative functions on my application", which is why heroku console runs the console Procfile entry and provides you a bidirectional pipe. You seem to have a different meaning -- "the thing which I need to always run to perform certain background tasks". (web also has special meaning to Heroku -- the routing mesh will send HTTP requests to web processes.) I would therefore also rename this, so that console still means "console".
You could choose main, for parity with main.rb, but instead I would encourage you to think about what this component actually does and instead give both the Procfile entry and main.rb a descriptive label.
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've got an Express Web app running as my main app on Heroku Cedar. I need to run a worker job periodically. I know I can specify a worker: in my Procfile, but that seems to be for a forever running kind of job. Perhaps there is a way to have the event mechanism of nodeJS caus e the worker to Idle, and use Cron to poke it alive periodically??
to keep your process alive you can try using an external service which will "ping" your application, you can use the newrelice free addon on heroku for that.
I am currently experimenting and it seems that even with this the application is still put in idle mode but it restarts on the next "ping" so it is still up most of the time.
I don't known node.js but I do my worker with Ruby+EventMachine inside a ruby on rails application and it works fine, you just need something to work in the background aside of your web requests.