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.
Related
I have a Sinatra app, overall configured like described here sinatra docs.
It basically starts an event machine loop.
Now, If I want to write a RSpec test, how do I start server like this and shutdown it after?
I can do this from console by ruby server.rb, I may execute this command from spec file in test suit setup (however, I'm not sure if it is right). But then, even if I do so, how I stop it after? (and do I need or it will be stopped after test is finished?)
I think, in any case, you can use Rack::Test to test your Sinatra app. In order to run the specs, you don't need to run the server from the terminal.
Take a look at the documentation, you can find different examples:
http://www.sinatrarb.com/testing.html
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'm designing a web service using Sinatra and I need to perform certain operations when the service is started and some other operations when the server is stopped.
How can I register those operations to be fully integrated with sinatra?
Thanks.
The answer depends on how you need to perform your operations. Does they need to be ran for each ruby process or do they need to be ran just once for the service. I suppose it's once for all the service and in the case of the latest :
You might be tempted to run some code before your Sinatra app is starting but this is not really the behavior you might expect. I'll explain why just after. The workaround would be adding code before your sinatra class like
require "sinatra"
puts "Starting"
get "/" do
...
end
You could add some code to your config.ru too btw, would have the same effect but I don't which one is uglier.
Why is this wrong ? Because when you host your web service, many web server instances will be fired and each one will execute the puts method or your "starting" code. This is correct when you want to initialize things that are local to your app instance, like a database connection but not to initialize things which are shared by all of them.
And about the code firing at its end, well you can't (or maybe you could with some really ugly workaround, but you'll end with the same issue you get with the start).
So the best way to handle on and off operations would be to wrap it within your tasks firing your service.
Run some rake task or ruby script that do your initalization stuff
Start your web server
And to stop it
Run a rake task or ruby script that stops the server
Run your rake task or ruby script that does the cleaning operations.
You can wrap those into a single rake task, by starting your app server directly from ruby, like I did there https://github.com/TactilizeTeam/photograph/blob/master/bin/photograph.
This way you can easily add some code to get ran before starting the service, still keeping it into a single task. With some plumbing, I guess you can fire multiple thin instances and then allow you to start your cluster of thin (or whatever you use) instances and have still one task to rely on.
I'd say that adding a handler to the SIGINT signal could allow you to run some code before exiting. See http://www.ruby-doc.org/core-1.9.3/Signal.html for how to do that. You might want to check if Thin isn't already registering a trap for that signal, I'm not sure if this is handled in the library or in the script used to launch thin ( the "thin" executable that gets in your $PATH).
Another way to handle the exit, would be to have a watchdog process, that check if your cluster is running and could ensure the stop code is being ran if no more instances are running.
I have a single instance of InDesign Server running on a Windows 2007 VPS, which runs a SOAP service on port 8081. This runs as a Windows Service and runs both dev and live JSX scripts, depending on the path of the script (we have a dev folder and a live folder).
I am having trouble running a new script, so would like to get access to the console of the running service, but I am struggling to find a reference to how to do this in the Adobe PDF docs. I know the script itself being found, since there are errors in the Windows Event Viewer for a specific code line, but I think it is having trouble locating JSXBIN resources. The error message just lists the variable in question, rather than the explicit path.
I have modified the script to output path information to stdout, but this doesn't get into the Event Log. So, can I get a window on the console of the running service? I don't want to stop the current service as that is in use for live.
Some ideas I've got from the docs:
InDesignServer -console
InDesignServer -LogToApplicationEventLog
I think this executable however starts up a new instance, which isn't what I want (either it would choose a new port number, or try with 8081 and fail to start since the port is in use - I've not tried either for obvious reasons). The flags respectively display stdout in the DOS window, and redirect std out to the Event Log.
In short, I don't think this is possible. I was hesitant to start a new instance on our live server in case it upset anything, but in fact it is quite safe; just ensure that the port you specify is different to your usual one.
InDesignServer -noconsole -port 10001
The noconsole connects stdout and stderr with the current DOS window - using console opens a new one, so it's the former you want.
Aside: it may be worth avoiding LogToApplicationEventLog, since the process can get disconnected from the console, which makes it fiddly to kill in a graceful manner.
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).