Feature: Smaller Footprint

[ThomasSteinbach]

Is it possible to make the Installation of Tiller a bit more independent of Ruby and with a smaller memory footprint?

I don't know much about ruby but in my imagination I think about compiling Tiller somehow to a binary which only includes the parts of Ruby nescessary. Currently, e.g. on the library/httpd container, the installation of Ruby and Tiller creates a 43.9 mb layer. On some Docker Base Images the wrong Ruby version is in the packages, such that Tiller becomes more complicated to install.

Here my first hints about a solution: https://github.com/phusion/traveling-ruby

Maybe travelling-ruby wouldn't leave a smaller footprint, but will make the distribution of Tiller more easy. Maybe there are other tools to package just the nescessary components.

Good idea - at least to think about?

[markround]

Thanks for the request, I'll look into this. If I get a workable solution I'll also look at creating a set of minimal base containers for various distros that include Ruby, Tiller etc.

[EugenMayer]

Even if i would love to see that, effectively there is no fix for that beside replacing ruby and e.g. going for Golang.

For me, one of the big reasons tiller is not wide spreaded is the exact reason mentioned here - it's runtime is "fat" - having a single fat lib to ship as golang would blow tiller up in the sky.

The point is, tiller is devops. And adding ruby to every single docker image, be it java, php, golang, node .. just adds up und also lets me override more and more docker images.

I have seen, though, i think also here, a approach where people use one single docker image with tiller + ruby to generate all the configuration and then use volume_from

Beside i dislike this due to "spagetty split" app configuration it much more also making "restart scripts" far less usefil, since your tiller runs "abroad", you simply cannot restart the service without having a shared docker-socker or anything other blown-out-of-the-propotion kind of thing.

That all said - back in days i have chose tiller over consul-template because of erb and the lack of proper features in Golangs template engine. So going back to Golang might impose some issues with exactly that, we would need a proper template engine. Beside that, all the other things are probably better implemented in Golang then ruby ( from consul, etc, env and others ).

Sorry if i took this over this issue a little - i just thought those thoughts make sense here