Show HN: Self-contained Redis server

Show HN: Self-contained Redis server(github.com)

19 points by b0ba1lle 11 years ago | 6 comments

akerl_ 11 years ago |

This is an interesting idea, but if you're shipping all the container code and the image inside the binary, I'm not sure how much you gain over just shipping a precompiled binary of redis itself. At best, you're baking in the config you want, but with the work being done here you could just patch in your desired config options into the redis binary.

libcontainer explicitly doesn't claim security as a feature, so you aren't getting real security wins by doing this, especially when you can put a static redis process in cgroups and limit it down with SELinux or similar anyways, and the packaging/distribution workflow is pretty much the same as pushing a static redis around.

I feel like I'm missing something; can the author or some other knowledgable soul point out the upsides of packaging a service like this?

nteon 11 years ago | |

agreed - redis is a single binary with minimal dependencies, this seems like so much more work for no gain.

akerl_ 11 years ago | | |

I'm comparing "statically compiled redis" with "statically compiled libcontainer + redis container", which appears to be what this is. I can see a lot of benefits for statically compiling something, redis included, I just don't see what the addition of libcontainer provides.

BillinghamJ 11 years ago |

Is Redis not already self contained?

b0ba1lle 11 years ago | |

Well not really as it doesn't run in a container. Might be a static binary though. Sure sc-redis could make much more sense for something that is really hard to setup (sc-<dependency-heavy-thing-here>).