Slashdot Mirror
Docker Images To Be Based On Alpine Linux (brianchristner.io)
New submitter Tenebrousedge writes: Docker container sizes continue a race to the bottom with a couple of environments weighing in at less than 10MB. Following on the heels of this week's story regarding small images based on Alpine Linux, it appears that the official Docker images will be moving from Debian/Ubuntu to Alpine Linux in the near future. How low will they go?
Obvious troll comment is obvious.
a.out and static binaries, go with linux 0.12. everything since has been bloated crap.
You could run in a Jail on BSD, and ship pretty much no OS at all. Thats the future of containers (and 20 year old tech too...)
Systemd is a new init system whose primary advantage is that it promises to unify the behavior of services running on different linux distros. The problem that a lot of people (including myself) have with it is that since it unifies behavior, you lose choice in how you configure that behavior. In my organisation we've been using Debian for _years_ and upgrading our servers to the latest version has only ever involved minor tweaks to our config scripts. With Debian 8's systemd, we pretty much have to rewrite it all from scratch, which is going to be a huge, dangerous project. Of course, the trend of history is toward automation and standardization, but I think that systemd is too ambitious and too early. Only time will tell though.
I hadn't heard of Alpine Linux before today, being an old Debian guy. Besides the whole systemd thing, I've had the sense that Debian was loosing its way for a while and have been looking around for something to replace it when Debian7 reaches EOL. As a grey beard I want something light-weight and without systemd, but as a practical grey beard I want something stable, that I'll be able to run for another decade. So far, CentOS seemed to be the way of the future for my organization, although it makes me vomit in the back of my throat a little to go closer to the root of the systemd tree.
Make no mistake, though, Docker is the way of the future and will put a lot of people in this forum out of a job. If Alpine has the backing of Docker, it might be the linux distro of the future. It has some really interesting features, like the ability to save all of your system configuration into a package that you can install on other systems via the package manager. That's really cool, and a neat alternative to puppet. I'm not very happy that it isn't binary compatible with stuff built using glibc (which means that commercial software will be limited), and AFAICT it doesn't have some of the dev tools I like to use, but I think this will be a major contender soon.
I'll be watching it. It might
DockerSlim shrinks standard Ubuntu containers by 30X.
Sample images (built with the standard Ubuntu 14.04 base image):
nodejs app container: 431.7 MB => 14.22 MB
python app container: 433.1 MB => 15.97 MB
ruby app container: 406.2 MB => 13.66 MB
java app container: 743.6 MB => 100.3 MB (yes, it's a bit bigger than others :-))
The point is pulling an application.
How the people that made the docker image you are using created their Docker image doesn't matter much.
You can still use Debian/Ubuntu as the base of _your_ Docker images.
These are just the official Docker images. I can see how that makes sense for something like a MySQL Docker image. You just want it to run the database server.
New things are always on the horizon
There are already tools to detect that, at least some of them are FOSS:
https://www.alfresco.com/blogs...
For example this one is open source:
https://coreos.com/blog/vulner...
New things are always on the horizon
Calling You an SJW is without merit, as Your post has nothing to do with social justice.
Instead, I shall call You an assbandit for calling my system to be a "nothing" without systemd. And a total idiot for claiming that GNU is nothing without Linux. And that Linux is nothing without GNU. In short, fuck off and educate Yourself.
So, WTF is docker? I thought docker was some Apple UI concept, but I have no idea what it is in Linux.
I'm a leaf on the wind. Watch how I soar.
I suspect docker is the only real contender to the total systemd domination. I liked systemd until I realized how much fragility it brings to the system with all those supposedly nice dependencies between services. The problem is that when one of the dependencies fails, the rest stops starting/shutting down/working when in fact the failure can be very much transient. So I started to like how docker resists supporting full-featured container dependencies. It essentially requires for containers to deal with connection failures when talking to other containers making the whole setup much more robust. As a bonus it becomes much easier to move containers to other machines making the setup scalable.
The move to Alpine is nice in that respect as it it ensures that the packages to build containers on do not have explicit or implicit dependencies on the presence of systemd and so is much more suitable for docker.
The unification with systemd is so that you as a daemon developer only have to write one single unit file that then will work across all different distributions that use systemd, it has nothing to do with limiting your choice in configuration. There should be no less choice in configuration of systemd for you as an administrator than what you already have with SysVInit. You can run what ever scripts from the unit files that you want. I would very much like to hear why you think that systemd lessens your configurability.
How so when the daemons have different names across distributions httpd Apache2 store the preferences in different locations and the configuration in a different location. Standardizing those things have nothing to do with systemd
Can you name one distro with gnu?
I think the idea behind the tools is to catch stuff just in case something gets forgotten.
You can easily do updates/build of Docker containers, as long as you automated and do 12 factor apps.
New things are always on the horizon
Daemons do not have different names across distributions, the Apache2 daemon is httpd regardless of distribution. However as you point out configuration locations can and will vary and also package names (but package names has nothing to do with systemd). If we look at the systemd unit file for Apache2 from RHEL7 there is these two lines:
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
So what happens here is that the unit file is the same regardless of distribution and then the distribution sets it's configuration locations into the /etc/sysconfig/httpd file by setting $OPTIONS. This way there can be a unified unit file but still differences between distributions. Because to have unified unit files is one of the goals of systemd, the thought is to have a central shared repository of unit files from which the various distributions then simply can sync whenever they update systemd (or when the feel like updating their unit files) without putting the burden on each maintainer/developer to create a distribution specific init script which is the case with SysV.
But in practice the applications don't update this base OS, so the copy of openssl that is loaded into memory when the app launches will be vulnerable since there is no practical way to automatically keep them updated. The app vendor would have to basically rebuild the image every time a single package would have to be updated.
First of all, there's often little reason to even include OpenSSL in your container. You can attach to it through Docker. And only expose ports your app uses. The attack vector is reduced. Secondly, practices around containers are definitely evolving, so what is "in practice" now isn't necessarily the way it will always be.
E pluribus unum
Debian GNU/HURD
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
If I didn't misunderstand them, keeping the common core up to date was one of the goals behind Red Hat's Project Atomic.
As long as one cannot print out the image as a QR code ;)
Make no mistake, though, Docker is the way of the future and will put a lot of people in this forum out of a job.
Yea, you're not really a grey beard if you make stupid statements like that.
Adding another layer of virtualization to our existing stack with several layers already in it isn't going to magically make things better.
In the last 10 years I've seen the same web server go from running on bare metal to running under 4 layers of hypervisor by the time you get to the docker container ... and you know what ... now that server farm takes 3 times as many people to run because you still need the apache guys ... and you still need the linux guys ... but now you need the docker guys, the vmware guys, and somebody who can coordinate the whole fucking mess.
So lets look at this we went from:
Hardware -> Linux -> AppVM running Apache (1 layer of address translation, the AppVM/Linux kernel boundary)
to
Hardware -> Linux -> KVM -> Linux -> Docker -> Linux -> AppVM running Apache (thats 5 layers of translation ... Yes, thats REALLY what most people using Docker will do)
Yea, thats definitely going to put people out of work ... its easy to understand.
Docker is another example of people doing something because they figured out how to do it, not because they actually should do it. Worse still, Docker is a solution to the fact that Linux is a mess from a file system perspective where everyone just dumps all their bins, system or 3rd party all in the same directories, all together. And then they make fun of Windows like System32 is different than /usr/lib on any given Linux box. System or app config files ... ALL of them are in /etc ... WTF? You know theres this /usr/local idea right? You know that you can put libs in the same directory as the application and then you don't have to run a VM to get the same sort of separation right? I mean seriously, you can't call yourself a grey beard and say Docker is good at the same time, you just admit you have no fucking clue how to be an admin or how docker works.
And you're conflating it with systemd? Do you not have any idea what either one of them are?
Yea, I'm ranting. People who think Docker is good are idiots, typically developers trying to be sys admins, or 'DevOps' as they call it ... and they're clueless and don't understand wtf they are doing. Its not Dockers fault. 'Zones' are something Solaris has had for years, and they weren't new when Solaris did it. Mainframes have had the concept since the 70s. The problem devs who don't know when and where to use them are just throwing them all over the place
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Docker applications are slower than natively-running code.
So it seams, looks like I spoke too soon. Has this been changed because I remember (but of course that memory can be false) that apache2 was /usr/sbin/httpd in Debian back in the day (it's several years since I used either Debian nor Apache). Either way, sorry for speaking while uninformed.
Which user space applications depends on a specific binary being pid 1? And for the other utilities in the systemd suite, why is it seen as a major problem that you get more choices for which software to run? Did you get just as upset when lighttpd or nginx where created since Apache should be the only piece of software that we need?
To use the potential of docker, you need to use prebuild images, otherwise it doesn't speed anything up. Prebuild images are just like "okay, somebody uploaded something, i execute it and feed my important data to it". No need to say, it's a bad idea.
What to use instead?
Use plain LXC. LXC works great, you can easily generate a template with debootstrap (it brings a script, which does that) from official debian packages.
Then use ansible to install your stuff. An ansible file just looks like a Dockerfile, only that it has a reasonable function list like "apt: name=apache2 state=installed", which does not rely on writing your own commands "apt-get install apache2", so you avoid many pitfalls (for example quoting stuff with spaces and so on) and it uses jinja2 for templates. Read the docs yourself, it's a great tool to build environments or manage existing ones.
So why was it no problem that most distributions forced SysV on you, or that Ubuntu forced upstart on you? In fact there are tons of software that are forced on me by a distribution, be it grub, libc, or which version of gcc they used to compile the binaries with (not to mention which cflags they used). That it comes as default does not meant that you cannot use another init system if you want, all SysV scripts are still there.
Think you are right, must have been since apache 1 I remember this, I switched to lighttpd when it came and never looked back :)
That is not a dependency on a specific pid 1 binary, that is a dependency on a functionality. How else do you think that they solved GDM on BSD, Solaris et al?
Alpine doesn't have systemd
Go well
and again alpine doesn't have systemd
no gnome yeah
Go well
Thanks F.Ultra
Alpine is poorly configured and you need to fiddle with those lovely script files to get some parts firing.
You would be absolutely lost with systemd.
Not every distro works exactly the same, that's why we have init scripts.
Go well
Why would you be lost with very simple unit files as compared with lengthy and complex init scripts? There is no need to do distribution specific unit files since there is no difference there between distributions, file locations might differ but that is handled by configuration files and not by unit files. That each distribution needs their own init scripts is the problem, not the solution.