Show HN: Self-contained Redis server
github.comThis 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?
agreed - redis is a single binary with minimal dependencies, this seems like so much more work for no gain.
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.
It provides just as much addition as running redis in a docker container. As for the "libcontainer explicitly doesn't claim security as a feature" do you have a source for this I'm curious ? Running things in containers provide isolation and should provide an extra layer of security (I no expert so prove me I'm wrong :) ). In the future it can provide resources isolation (CPU, memory ...). Also, at scale, I don't know anyone who is ready to setup namespaces and stuff manually.
Is Redis not already self contained?
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>).