Posts Tagged ‘happstack’

Patch-Tag uses linode, but I’ve decided to try out EC2 for development purposes, as the hourly pricing model is attractive for server instances that don’t need to persist, and… well, I’m curious.

First off, with a big bow of respect to the amz engineers, I’ll tell ya, EC2 has gotten a lot better lately.

The last time I used aws was 3 or so months ago when I was configuring cloud stuff for a video startup that used a lot of disk, in conjunction with rightscale management console. Everything worked from a technology standpoint, but my gut feeling vis a vis usability was that aws was an awful mess: guis that didn’t work right, command line interfaces with hard to find documentation, inconsistent flags… beh.


is hugely improved, documentation and help seems to be better organized… everything is just just more polished… better.

Anyways, to get to the meat of my post, I have created two public amis that I hope may prove useful to developers and newbies alike.

EC2 Amazon Machine Image: ami-3122ce58

AMI ID: ami-3122ce58
Name: Haskell on EC2
Description: Based on elastic karmic, with haskell platform
Source: 072945664613/Haskell on EC2

and… a few cabal installs later

EC2 Amazon Machine Image: ami-3d23cf54

AMI ID: ami-3d23cf54
Name: Gitit Happstack Demo on EC2
Description: Gitit/Hapstack on EC2
Source: 072945664613/Gitit Happstack Demo on EC2

Now, these images are really not such a bit deal since what with cabal and the haskell platform, there have been huge gains in package installability. But they weren’t completely trivial either, due to missing dependencies, the quickcheck 1 to quickcheck 2 switch that broke a lot of happstack, and various other hoops I had to jump through…

*I* had to jump through.

*You* just load the AMIs.

I recommend to start here if you’re an aws newbie.

Happy hacking!

PS Check out the latest from Simon Marlow for another haskell on EC2 post

In case there any aws experts reading this, here is also a snip of a chat of me fumbling around. Feel free to comment or add your questions.

<patch-tag> I am creating an EBS bootable AMI, which takes (at least) > 10
minutes. Say five minutes after start I do “touch somefile”. Will
“somefile” be included in the new AMI? What governs this behavior?
<patch-tag> (I actually am performing this experiment at the moment but I am
curious as to what to expect and why)
<flaccid> um i havnt played with ebs boot yet, but i would assume so, its
meant to be persistent
<flaccid> try it out
<patch-tag> The reason I am asking is, say I want to snapshot while
configuring something, and I am at a safe/happy place. If the
snapshot applies to that exact moment in time, I can keep doing
dangerous things. But if the snapshot extends in time I have to
sit on my hands till it completes before continuing work.
<flaccid> well a snapshot is a snapshot
<patch-tag> er… ?
* flaccid looks up ebs boot
<patch-tag> not particular to ebs boot. question applies to any way of
creating amis.
<patch-tag> (sorry for obfuscating the issue)
<flaccid> oh right
<flaccid> well an AMI is indeed a snapshot
<flaccid> thus why it is called an image
<flaccid> looking at ebs boot, it does seem to be only the ability to boot
from ebs snapshots, so its not a persistent image but a manual way
of gaining persistence
<flaccid> and it costs more
<patch-tag> changing subject — costs more? I thought ebs storage when offline
was same as S3, 10c/G/month.
<patch-tag> also, AMI creation completed, so I’m actually going to check if
that file I created five minutes in got bundled…
<patch-tag> aaaaaand… it’s not there.
<patch-tag> I guess what’s getting snapshotted is ram in a certain state, not
hard disk. which is why it can be truly instantaneous.
<flaccid> everyone has said that


works out costing more
<flaccid> patch-tag: where was the file on the filesystem you touched ?
<patch-tag> /home/ubuntu/testfile
<flaccid> afaik by default /home is not bundled
<flaccid> you will need to check that
<flaccid> and obviously ensure /home is actually on the root fs (/)
<patch-tag> no, it’s bundled. I know this from a previous snapshot.
<patch-tag> any insight on why boot from ebs costs more? I guess because if
you make a lot of snapshots those 10c/G/month add up?
<patch-tag> And the convenience of it makes it tempting to do more snapshots?
<flaccid> well if /home is bundled then, i have no idea. bundling is
<flaccid> and yeah can’t answer your second question. unfortunately i’m not
amazon sorry
<patch-tag> just in case it’s not clear, we’re in good shape. this is the
behavior I want.
<patch-tag> My assumption is that snapshot is point in time, and I can
initiate dangerous configs after initiating snapshot without
<flaccid> like i was saying before, yes a snapshot is a snapshot
<flaccid> whether it is a bundled ami or ebs snapshot, they are both snapshots

Read Full Post »


Get every new post delivered to your Inbox.