4 ms·
> But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ? No. In the past I've tried seve
by notzorbo3 11y ago
> But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ?
No. In the past I've tried several times to create a lightweight Debian derivative that would still allow me to install Debian/ubuntu packages from their repositories. The smallest I've been able to get things without completely breaking everything was around 230mb. This required lots of ugly hacks such as post install triggers that would remove useless garbage such as /usr/share/doc/ and man pages.
It's simply not possible to take the Debian eco-system and magically turn it into a slim version of itself.
I would never run Alpine stand-alone on a server. But for containers, it's absolutely amazing. I don't need the full Debian ecosystem. All I need is some basic tools such as NPM, Pip or gem. They can take care of the rest. The whole point of containers is to escape from the dependency and package hell that we're currently in.
- icebraining 11y agoI don't need the full Debian ecosystem. All I need is some basic tools such as NPM, Pip or gem. They can take care of the rest. What happens when your npm/pip/gem package depends on a C library like libpq or libsasl2? Restricting yourself to pure JS/Python/Ruby code to avoid having a few MBs sitting on the disk sounds like a terrible tradeoff.
- icebraining 11y agoThe smallest I've been able to get things without completely breaking everything was around 230mb. This required lots of ugly hacks such as post install triggers that would remove useless garbage such as /usr/share/doc/ and man pages. # debootstrap stable mydir # chroot mydir apt-get remove -y vim-common nano netcat-traditional e2fsprogs # chroot mydir apt-get clean # du -sh mydir 228M mydir
- Symbiote 11y agoWith a little more work: cat /etc/dpkg/dpkg.cfg.d/small path-exclude=/usr/share/locale/* path-exclude=/usr/share/man/* path-exclude=/usr/share/doc/* path-exclude=/usr/share/info/* Saves about 15MB. Removing wget saves 50MB or so, since it uses a large library (libicu52). for p in $(dpkg --get-selections | cut -d $'\t' -f 1); do echo $(du -kc /x $(for i in `dpkg-query -L $p`; do [[ -f $i ]] && echo $i; done) | tail -n 1 | cut -d $'\t' -f 1) $p; done | sort -n | tail 2676 libssl1.0.0:amd64 3084 tzdata 3152 libc-bin 3288 groff-base 3652 iptables 5224 coreutils 5660 perl-base 6036 udev 10308 libc6:amd64 13784 systemd (Since I've removed things, `dpkg-query -Wf '${Installed-Size}\t${Package}\n'` isn't accurate.) Compressing Apt indices saves another 20MB [1] The system is now down to 123MB. [1] https://wiki.ubuntu.com/ReducingDiskFootprint#Compress_files https://wiki.ubuntu.com/ReducingDiskFootprint#Compress_files
- LinuxBender 11y agoDid you also try stripping out the locale's from glibc that you don't need? In CentOS that frees up about 150MB for me.
- icebraining 11y agodebootstrap already only comes with the minimum (en_US, I think).
- LinuxBender 11y agoExcellent. I was not aware of that, thank you!
- pixelbeat 11y agoNote the coreutils-single package in Fedora rawhide which can be used to get coreutils down to about 1MB. Details on that change at http://pkgs.fedoraproject.org/cgit/rpms/coreutils.git/commit/?id=5fb9bc47 http://pkgs.fedoraproject.org/cgit/rpms/coreutils.git/commit...
- tracker1 11y agoYou can also use separate build and deploy containers... build in a container with all the tooling you need, that exports out to a mount point everything needed to run, then turn that mount point into the new deploy container.
- sandGorgon 11y agoI posted this today - https://news.ycombinator.com/item?id=11046797 https://news.ycombinator.com/item?id=11046797 this is by one of the posters above you. its called Dockersl.im > Here are a few numbers to give you an idea (using on Ubuntu 14 base image): > node: 431MB -> 14MB python: 433MB -> 15MB ruby: 406 MB -> 14MB java: 743MB -> 100MB
- lisivka 11y agoAnd your reason is ... to share less between instances? The more code in common, the better, isn't? When I trying to optimize my system of containers, I move everything common into topmost container, to make application containers smaller. You are doing opposite. Why?