Heroku Announces New Version: “Celadon Cedar” | Hacker News Reader

Heroku Announces New Version: “Celadon Cedar”

news.heroku.com

137 pointskrohrbaugh45 comments

Oh, hey, it appears you can run python stuff too: https://gist.github.com/0a08e676559fc03e6200

  kurt$ heroku run bash
  Running bash attached to terminal... up, run.2
  ~ $ python -V
  Python 2.7.1
  ~ $

Huh, so the Python support is pretty complete:

Simple Flask app: https://gist.github.com/efec5e060e88abc87821

Python/Django: https://gist.github.com/866c79035a2d066a5850

Wow, it gets even more interesting:

  /tmp $ cd redis-2.2.8/
  /tmp/redis-2.2.8 $ make
  /tmp/redis-2.2.8 $ cd src
  /tmp/redis-2.2.8/src $ ./redis-server 
  [295] 31 May 15:36:30 # Warning: no config file specified, using the default config. In   order to specify a config file use 'redis-server /path/to/redis.conf'
  [295] 31 May 15:36:30 * Server started, Redis version 2.2.8
  [295] 31 May 15:36:30 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
  [295] 31 May 15:36:30 * The server is now ready to accept connections on port 6379
  [295] 31 May 15:36:30 - 0 clients connected (0 slaves), 790480 bytes in use
  [295] 31 May 15:36:35 - 0 clients connected (0 slaves), 790480 bytes in use
  [295] 31 May 15:36:40 - 0 clients connected (0 slaves), 790480 bytes in use

Absolutely none of this is officially supported, right? (It looks very much like "game on, DotCloud", from what you've been finding, though....)

I don't think any of it's supported. Redis will run, but you can't exactly get to it (no TCP routing mesh apparently). It really just seems like they made it really easy to add new languages.

This is because running commands is from a one-off dyno vs. the formation dyno's that have requests routed to them.

See: http://devcenter.heroku.com/articles/oneoff-admin-ps

From their new homepage (http://www.heroku.com) :

  "Run Anything
   Run and scale any type of app."

Also Go and Erlang

    ~ $ go
    gobject-query  godefs         godoc          gofix          gofmt          goinstall      gomake         
    gopack         gopprof        gotest         gotry          gotype         govet          goyacc         
    ~ $ erl
    erl   erlc

How do you output from bash/terminal to text like that?

Type part of what you want, then hit tab twice.

Yep, Python works great so far, I threw up a little cookbook recipe for a Pyramid app: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/...

Since its fairly easy to composite multiple WSGI apps together, one could run a few different Python WSGI-based apps under a single multi-threaded process to take full advantage of the free quota. That would work with Pylons/Pyramid/Flask and other Python web frameworks that don't rely on a single set of module global settings (Django).

I just created my first Node.js app. Clone ry's demo at:

https://github.com/ry/node_chat

Add a Procfile and package.json per the docs:

http://devcenter.heroku.com/articles/node-js

And it just works:

http://node-chat.herokuapp.com/

It worked for me too :) but check up your billing usage statement it will be showing some charges, even though you are under free limit. I just filed a support ticket with heroku, after scaling the web dyno to 0 ;)

Cedar now allows you to scale any dyno as low or high as needed, including all the way down to 0. This means you could choose to scale your web dyno down to 0 and a worker to 1. If left this way for the entire month you would have 720 worker dyno-hours and 0 web dyno-hours total at the end of the month, fully inside the 750 available per month. http://devcenter.heroku.com/articles/billing-changes

This means any process type, for example cron jobs, for free. As long as only one process is ran per app, but as far as I know, you can run as many apps as you want. This sounds like a very nice deal. Am I missing something?

No, that's the long and short of it.

Of course, you can't share multiple apps behind one domain, so if the one dyno isn't keeping you you'll need to scale up and pay for it.

OTOH, if you don't need to worry about any extra latency (maybe?) you could probably get away with a rails+node app like https://github.com/maccman/holla running free by having one app just run the web interface, and point the backend at another app running node.

As soon as you go outside of one tech stack it's cheaper to just get a small VPS to start with, but heroku definitely has its perks.

It seems unlikely that rack-cache + memcached would actually offer similar performance to varnish. This seems like a pretty bad set of changes for apps that need to serve out lots of static content - think newspapers, blogs, etc.

Will the old configuration style for http caching continue to be supported indefinitely?

Where did you read about this new configuration?

http://devcenter.heroku.com/articles/http-routing#the_heroku...

"The new HTTP stack does not include Varnish (a reverse proxy cache) because it is not compatible with the advanced HTTP features described above. If you wish use HTTP caching headers, rack-cache and the memcache add-on offer features and performance comparable to Varnish, but with the additional benefit of giving you complete control over authentication and page expiration."

In testing we've seen roughly similar performance with rack-cache + memcache to varnish for most situations.

memcached also has a 1MB limit.

(Begs the question though: What are we doing serving pages >1MB?)

I expect that someone will build a Varnish add on for Heroku. It even looks possible to run Varnish on a dyno, believe it or not.

I love Varnish, but it's completely inflexible in Heroku so it's always been a mixed blessing. Sticking Google Analytics on your page, for instance, creates cookies for users that mean they will no longer get cached content. It's something that I can work around with dedicated Varnish, but Heroku can't really fix for me.

That's not true. Google Analytics cookies are injected via JS. When heroku's Varnish is checking for a cached version of the page, it strips any cookie information given by the browser.

We've are running production apps with Varnish caching + Google Analytics without issue.

Set your cookies with JS or on uncached pages (such as POST logins) and you'll be fine.

It's possible that it strips the GA cookies (which is cool, I had no idea), but Varnish doesn't strip cookie information from the browser. If it did you wouldn't get any Rails sessions or anything.

It's not specific to GA cookies.

You can set cookies on uncached pages in ruby and read them without issue in JS on Varnish cached pages. The page will still be cached even if the user has a session cookie.

Basically: don't set or get cookies in ruby on cached pages and you'll be fine.

"LXC used as a container for all dynos running on Celadon Cedar"

Has anybody published a complete SELinux or SMACK policy to use LXC with untrusted users? Last I checked LXC wasn't fully ready yet.

Very interested to hear this as well. Anyone from Heroku can comment?

LXC is one of several isolation layers used in the Heroku dyno manifold to ensure process security and resource guarantees. Here is a more in-depth discussion of Heroku dyno isolation: http://devcenter.heroku.com/articles/dyno-isolation.

So LXC is fully secure now if you stick to chroot?

http://www.mail-archive.com/lxc-users@lists.sourceforge.net/...

You can't contain root in lxc. It's great for unprivileged users, though.

The use of LXC containers now is quite interesting for security.

"- Full isolation of processes for security and performance"

Have there been security-related incidents before with their slugs? Is this to address safer multi-tenancy?

Have there been security-related incidents before with their slugs?

Absolutely. http://daverecycles.com/post/2858880862/heroku-hacked-dissec...

Blog post with code examples is here - much better than press release: http://blog.heroku.com/archives/2011/5/31/celadon_cedar/

This is beautiful. I like how they got rid of Varnish. The problem with Varnish was that you couldn't test it in your local development environment. (Heroku wouldn't give out their Varnish configuration, so you could only make an educated guess as to how their Varnish was configured.)

Fantastic! I am glad to see support for HTTP 1.1. Anyone know if unicorn/Rails 3.1 chunked responses will work out of the box?

It seems as though it will. I read somewhere in the Dev Center that an app called "foobar" can now be accessed via "foobar.herokuapp.com", which uses an advanced new HTTP stack that supports async and chinned responses too I believe. I don't remember the exact page I read that, but take a peek in the Dev Center for more info.

http://devcenter.heroku.com/articles/cedar#new_http_stack_he...

It looks that the new stack is based on BeeHive (http://getbeehive.com/).

Um, no.

No? Not even a little? Just to be clear - I mean the part that replaced nginx + Varnish combo (HTTP routing), not the deployment stuff.

In any case, I guess you won't / can't say what you're using instead of those two? ;)

This is exciting stuff. I have been learning Ruby on Rails and will be pushing my code to Heroku soon.

Full native Node.js support. Alright!

Anyone find that grey on grey text a little hard to read?

it would makes sense if the documentation and the API had been updated before they did the press release. otherwise, great news for node.js people!

Take a look at the documentation below:

http://devcenter.heroku.com/articles/cedar

http://devcenter.heroku.com/articles/node-js

great, thanks for the links!

Reply on news.ycombinator.com