Hacker News new | past | comments | ask | show | jobs | submit login
Build Your Own SaaS Using Docker (cs50x project) (memcachedasaservice.com)
86 points by julien421 on Apr 16, 2013 | hide | past | web | favorite | 23 comments



Hello!

This website is a proof of concept with a simple Memcached SaaS. It is my final project for cs50x that ended this sunday. Please tell me what you think :)

+ You can read the how-to on SlideShare: http://www.slideshare.net/julienbarbier42/building-a-saas-us...

+ You can see the source on GitHub: https://github.com/jbarbier/SaaS_Memcached


Fun little project. Well done.

Giving a public facing application sudo powers (even limited ones) is a little scarey. If I understood your documentation I believe if I somehow got onto your box I could escalate to root just by editing your iptables scripts. You probably want to ensure www-data (or anyone) cannot write to these files :-)


ouch! thank you! :) let's -w!


Here's a nice comment on some of the dangers of setuid/sudo on shell scripts. The more you know...

http://unix.stackexchange.com/questions/364/allow-setuid-on-...


Thank you Chris. So a better way would be a compile an executable instead of using a shell script?


Or run the webapp itself inside a docker container? :)


What has been your experience with docker? I've been meaning to check it out but did not get around to it yet.


Hey! I've been playing with docker for a few weeks now for this project. I started working on my project using LXC & AUFS, but then switched to Docker when it was released. Frankly it made my life much easier because getting LXC and AUFS to do what you want can be pretty hardcore.


Consider trying LVM2 snapshots instead of AUFS.


Great work Julien, keep it up :)


What would be a good way of reliably farming out docker daemons to worker nodes? Mesos is a bit heavyweight but a docker-mesos framework could be pretty cool for programmatically scaling up or down dockers across worker nodes.


Yes, I agree it would be awesome. And the heavyweight problem could be solved by bootstrapping mesos itself from a nicely packaged docker container. Turtles all the way down :)


I created an issue for integrating Docker as a Mesos agent. https://github.com/dotcloud/docker/issues/410

If anybody with Mesos experience wants to lend a hand, I would love to give this a try. Say hi on the issue!


A very informative paper on Docker, will definitely help me out when I start playing around with it. Well done!


Also, I've just submitted some tips for getting the best out of memcached in case anyone is interested https://news.ycombinator.com/item?id=5560764


Nice job, damn docker is nice!


I would love to see something like that built on piece of a bit better technology, like FreeBSD Jails. I've tried to use LXC but it seems to be heavily fragmented (works a bit differently on Ubuntu, Debian and other distros), less secure (issues with remountability filesystems of root from inside of the container, and others) and in addition to that FreeBSD has some other neat things, like ZFS and CARP.


For whatever it's worth, OS-based virtualization is one of the core tenants of SmartOS[1] -- an illumos derivative that makes heavy use of zones (which were inspired by FreeBSD jails). And it also has ZFS, natch. ;)

[1] http://smartos.org

Update/clarification: SmartOS is running tens of thousands of VMs and virtual OS containers in production at Joyent -- and has for years. It is new in nomenclature and exposure, perhaps, but not in terms of core technology or production readiness.


I am familiar with remainings of Solaris, that is Illumos and its technologies, likes zones, dtrace and native ZFS, but the problem is that I personally wouldnt be very hasty to use such young OS in production, and I think I would have even more issues with convincing the management layer to do so, once I would manage to convince myself ;) But, even if that'd happen, that's again just another good stack, like FreeBSD and Jails, and not fancy framework like Docker.


I'm not sure what you're referring to when you say "such young OS". Solaris zones and ZFS have been around for almost a decade. Docker is young, but it wraps around LXC, cgroups, AUFS, and namespaces. Cgroups and AUFS were introduced in 2006. Namespaces are more recent, but they are basically a reimplementation of concepts from OpenVZ and VServer (and the latter is more than 10 years old). FreeBSD jails are great, and they have also been around for a while; but they are still lacking a lot of features (a jail doesn't have its own network stack, and resource accounting and limiting isn't as evolved as what cgroups provide), and unionfs is far from being as stable as AUFS.

Don't misunderstand me: FreeBSD jails are awesome if you're doing FreeBSD and want lightweight virtualization. For the rest of us, LXC is just as awesome, and docker lowers the barrier of entry considerably!

My 2c.


Actaully "zones" in smartos are created/managed/uploaded/download/etc via imgadm and vmadm which are not unlike docker commands at all.

http://wiki.smartos.org/display/DOC/How+to+create+a+zone+%28...


While FreeBSD jails have been around for ages, I would question how one can consider them "better technology", since they already offer significantly less functionality than LXC. You are kind of asking for a negative response with that terminology.

Personally I have used both in production and as far as I am aware Linux is light-years ahead already. Yes: Documentation is lacking. Yes: Some security issues remain. Yes: You need to be happy recompiling kernels and tinkering away. Yes: You need quite high baseline knowledge to figure out what's going on.

Perhaps I am wrong and FreeBSD has changed in the last three years to provide a stronger offering - but show me a policy that runs a program within a container, restricts it to certain syscalls, exposes only a whitelisted subset of devices and a virtualized network of arbitrary topology, bandwidth, and firewalling (at either layer 2 or 3), successfully limits block IO bandwidth to the container on a per-device basis through one of multiple schedulers and policy configurations, similarly both accounts for and limits cpu, memory and swap utilization via multiple configurable strategies (CPU affinity, time slices, hard/soft limits, etc.). Now show me it co-exist with multiple disparate options of kernel-level security toolkits for additional protection. Now show me it boot arbitrary Linux distributions within those containers, to effectively allow the container-based execution of the majority of modern 'nix software.

While we can umm and ahh about it, in truth, FreeBSD just doesn't have this, and realistically it never will at the container-based virtualization level.

Are broad software support and extreme configurability a requirement for most container scenarios? Probably not; in truth FreeBSD is practically comparable to Linux in most cases. However, to describe it as "better" seems dishonest.

(As for ZFS, OpenSolaris is the platform of choice there. Linux has some realistic alternatives appearing with more features, and well established stopgap measures like LVM2 snapshots... which allow the achievement of similar functionality without requiring additional complexity in the filesystem (or everyone to learn a new OS!), though they do lack some of ZFS' capabilities, they're good enough in practice for many situations.)

IMHO it boils down to this: design of any complex system (be it an organization or software) is largely about pragmatism and tradeoffs between various options. Being on an outlying OS doesn't increase your options, either immediately or in future. On the other hand, this is Linux's great strength.


The thing is, in my world all of these drawbacks you've listed on your own are unacceptable for production use, and almost each of them disqualifies the LXC separately, not mentioning all of them together. In addition to that, you've mentioned that your knowledge of jails is outdated, and I can confirm that, it is ;) Most of things you've listed as drawbacks for jails is no more true: they are hierarchical, they have their own network stack, they can be restricted with cpu/ram/swap usage, and so on.

Of course, this is highly subjective, as everything else is - its cool that you can run Steam in LXC and I cant run it in jails, but running steam is not something I want and need to achieve, its security and separation of architecture blocks, and in this world, jails are 'better' technology. Keep in mind, this is not religious - LXC was my technology of choice to start with, but I had to drop it due its immaturity and issues. Will LXC fix all of this, I will probably switch in no time (probably, because of the surrounding features FreeBSD provides).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: