Docker Images Are Moving From Ubuntu To Alpine Linux

[snout]

It's not that I don't like the alpine linux idea, it's just that I don't like their (insanely) lacking package repositories that didn't even have a proper Wireless Internet Management GUI last time I checked (I seriously had to script it myself with the help of zenity...)

In the light of Docker images, a such a GUI isn't particularly useful. This topic is not about using Alpine as a main linux distro (which might not be ideal), but use it as a primary OS for Docker images - which seems to me to be a match made in heaven. Very happy to see Docker going this route, never understood why images like MariaDB, Apache, Nginx etc. had to be built on hundreds-of-megabytes Debian/Ubuntu images. A Docker image should contain what you need and only just that, imho.

[caligula]

In the light of Docker images, a such a GUI isn't particularly useful. This topic is not about using Alpine as a main linux distro (which might not be ideal), but use it as a primary OS for Docker images - which seems to me to be a match made in heaven. Very happy to see Docker going this route, never understood why images like MariaDB, Apache, Nginx etc. had to be built on hundreds-of-megabytes Debian/Ubuntu images. A Docker image should contain what you need and only just that, imho.

Enterprise users are used to big images. Smaller footprint might give the impression of bad quality. Besides Debian is "standard".

[duby229]

Enterprise users are used to big images. Smaller footprint might give the impression of bad quality. Besides Debian is "standard".

Seriously? You must kidding right?

A light application that does what it does well will outperform a heavier one that does what it does well. Given two equal applications where one is lighter and the other is heavier, the lighter one is almost always the better choice..

I always took lighter applications as a sign of -better- quality. Because it's always been true.

[snout]

Enterprise users are used to big images. Smaller footprint might give the impression of bad quality. Besides Debian is "standard".

It shouldn't be too hard to explain to enterprise that they're building an entire office with full facilities while all they need is an extra desk, a chair and an employee, right?

[caligula]

Seriously? You must kidding right?

A light application that does what it does well will outperform a heavier one that does what it does well. Given two equal applications where one is lighter and the other is heavier, the lighter one is almost always the better choice..

I always took lighter applications as a sign of -better- quality. Because it's always been true.

I'm not. I've build few prototype services for internal company use before SaaS become the best thing since sliced bread. Had really minimal custom systems which worked just fine. They had to be replaced with something standard like Debian or RHEL to be validated by company standards. I've seen my share of stupid policies requiring a standard commercial solution instead of a simple one.

[snout]

Had really minimal custom systems which worked just fine. They had to be replaced with something standard like Debian or RHEL to be validated by company standards. I've seen my share of stupid policies requiring a standard commercial solution instead of a simple one.

You keep mixing things up here quite a bit. There's a huge difference between Alpine Linux and a "custom system",and there's a huge difference between Operating Systems and the base image used for a container.

In most cases, nothing of value can be said about the reliability, support, stability and integrity of a custom system, whereas RHEL, SLES and Debian are very well documented, very well known, have a long standing reputation in stability and their integrity can be easily verified. It's far easier for another sysadmin to find his way around in these systems than in any custom system and Enterprise might indeed prefer to select a flavour of Linux with enterprise level support. And there's safety in numbers. Would a random number bug as occurred in Debian ever be noticed in a custom system like yours?

In other words: that custom system might work very well for you, but how can you guarantee its stability over longer time, over different hardware configurations? How can you show beyond doubt that there is nothing hidden inside your custom system that might impose a security risk (unintentionally or intentionally)? And how will things transition when you leave your job for whatever reason and someone else has to maintain and upgrade your custom system? In this light size doesn't matter indeed, especially because I expect there won't be a big performance hit. A lot of components of those enterprise systems might not be in use, but are only wasting space there and not actually hogging resources.

Last but not least, "it runs just fine" is about the worst argument that can be used in IT. It cannot be a reason to choose for less reliability and maintainability - and on the other hand should also not be a reason to accept something mediocre and not look for more efficient ways and optimization.

Containers, on the other hand, already run on such a reliable, well known flavour of Linux and there's no reason at all why every single container running on a server should by itself contain a complete OS on its own. In a container you want to isolate, you don't want a lot of binaries in that container that are not needed and only might cause security concerns (albeit only to the container its running). There's no need to include man-pages or most of the software & configuration settings a large distro not intended to be run in a container might consider useful.

In an ideal world what you want to run in a container is exactly the bare minimum for the service you want to run, but you also want a certain form of standard, security and community support. This is where the lightweight, security oriented Alpine Linux comes in with its apk package manager and OpenRC init system - using no more than 8MB in a container. It provides just enough to run a container, install the service you actually want and prevent that service causing a PID 1 zombie reaping problem. Exactly what you want when your goal is to isolate things. With Alpine becoming the de-facto default in Dockerland I'm quite sure a lot of missing yet essential (for container) packages will soon find their way to Alpine. Postgres, Nginx-mainline, Elasticsearch and PHP7 would be nice, for instance

[ncopa]

Awesome, Natanael