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
Related
I can see the logs for a heroku app with heroku logs -t
Is there a way to easily see how many hits an app has received in, say, the past 24 hours? (preferably using a quick command in the CLI, but otherwise through the heroku webisite)
There are two ways I see here
the Heroku dashboard provides you with a Metrics tab, where you can see the throughput of your application.
If this is not exact enough, you can add a logging addon (logentries for example), then then analyze the router-logs there. Logentries provides you with counting, grouping, etc.
Same as a logging addon, but you also can add your own log drain and then analyze them yourself :)
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.
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 have a play 1.2.5 app running on heroku and I want to swap out all jobs into a worker dyno, so they don't scale with the web dynos.
To do that, I need to differentiate, if the application is running on a web or a worker dyno.
Is there any way to accomplish that by passing a command line argument using the procfile?
Currently I see, that by passing custom CLI arguments the JVM fails to be created...
Thanks you in advance!
Heroku uses web as the process type for web dynos.
You need to declare your dynos in your Procfile where you can specify their process types.
You can use any identifier you like, but worker is suggested and seems like a good convention to use.
You can then scale your individual dynos types using:
heroku ps:scale web=1
or
heroku ps:scale worker=1
Also, this post has a good answer that might help you.
Okay, I found it myself:
By adding a -D parameter to the procfile, I can determine the environment play is running in.
So my procfile's going to look like:
web: play run --http.port=$PORT $PLAY_OPTS
worker: play run --http.port=$PORT $PLAY_OPTS -Dprocesstype=worker
By using
System.getProperty("processtype");
I can ensure, that i am on a worker dyno and process my jobs only then.
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).