Хватит использовать Debian и Ubuntu как базовый образ для Docker

Если пройтись по образам на docker hub, то подавляющее большинство окажется построенными на базе Ubuntu и Debian. Хотя уже встречаются робкие попытки, в официальных сборках популярных пакетов, выкладывать альтернативные образы на базе Alpine linux. Но в общей массе это капля в море. А между тем Alpine подходит для базового образа куда лучше, чем такие знакомые и родные Debian с Ubuntu.

Размер имеет значение

Если сравнивать размеры этих трёх дистрибутивов, то получим вот такую картину:

Дистрибутив	Размер	% от ubuntu:14.04
ubuntu:14.04	187.9 MB	100. %
ubuntu:16.04	126.6 MB	67.4 %
debian:wheezy	84.91 MB	45.1 %
debian:jessie	125.1 MB	66.5 %
alpine:3.3	4.793 MB	2.55 %
alpine:3.4	4.795 MB	2.55 %

Представители Ubuntu осознавая, что разница в 40 раз вызывает вопросы, оправдываются. Один из основных аргументов в том, что у автора канал хороший и поэтому образ скачивается быстро, остаётся только порадоваться за него. Второй аргумент в том, что базовый образ мол скачивается один раз и благодаря особенностям файловой системы Docker линкуется в остальные. Скажем честно - аргумент лукавый, по опыту, если скачать десяток произвольных контейнеров, есть вероятность собрать на диске всю коллекцию версий Ubuntu и Debian.

 

Набор софта

У меня наиболее часто используемые операции в базовом образе это: скачать (wget/curl), разархивировать (unzip/tar), отредактировать (nano/vi) и посмотреть (less). Судя по размеру, alpine должен быть лишён всех этих базовых полезных возможностей. Однако реальность удивляет:

Дистрибутив	wget/curl	unzip	nano/vi	less
ubuntu:14.04	-	-	vi	+
ubuntu:16.04	-	-	-	-
debian:wheezy	-	-	-	-
debian:jessie	-	-	-	-
alpine:3.3	wget	+	vi	+
alpine:3.4	wget	+	vi	+

А что же тогда хранят образы Ubuntu и Debian? Вот набор наибольших по размеру вещей (в зависимости от версий набор варьируется): systemd, udev, python3+python2, bash и т.п. Уж конечно без этого мы собирая образ обойтись никак не могли.

 

Менеджер пакетов

У Alpine есть легковесный apk, с кучей свежих пакетов на все случаи жизни. Хотя тут он убунтовскомим репозиториям по количеству софта уступает. Но зато под реалии docker'а подходит куда лучше. Давайте разберём типичную проблему: в Dockerfile мы ставим пакет, что-то с его помощью делаем и удаляем, что бы не болтался и не раздувал размер образа. Конкретный пакет не важен, пусть это будет "zip":

Сначала apk:

apk add --no-cache zip
apk del zip

Размер образа до выполнения скрипта: 4.795 MB, после - 4.813 MB, разница 18 KB. Накладные расходы есть, но терпимо, ключ "–no-cache" помог не выкачивать индекс пакетов, а воспользоваться тем, что лежит в сети.

Теперь то же для apt (ubuntu:16.04), тут обойтись без обновления индекса у меня не вышло:

apt-get update
apt-get install zip
apt-get remove zip

Размер образа после этого изменился с 126 MB до 166 MB, разница в 40 MB! Неплохой "штраф" за то, что пакетом попользовался 5 сек. Вычистить конечно мусор вручную можно, но повозиться прийдётся не слабо и всё равно разницу в 18 KB вы врядли получите.

 

Система инициализации

По умолчанию используется гентушный OpenRC, а у конкурентов в последних версиях горячо любимая многими systemd. Не подумайте, что я недолюбливаю творение Поттеринга, напротив по моему, от того, что во всех дистрибутивах будет единообразный способ инициализации, все только выиграют. Но для контейнеров это перебор, уж очень сложно и неудобно там делать многие вещи. Да и по моему никто внутри докера systemd и не использует, не видел ни разу. OpenRC меня кстати тоже не впечатлил, он писался не для docker и не помогает решать специфические задачи, которые возникают в контейнерах.

Я использую s6-overlay, эта набор скриптов поверх s6, которые разрабатывались специально под docker. Я не буду пересказывать документацию, но вкратце опишу возможности:

• "Повесить" набор скриптов на старт и остановку контейнера.
• Декларативно описать назначение прав на директории и файлы, вместо беспорядочных chmod и chown в разных местах.
• Для каждого сервиса можно написать скрипт запуска под нужным пользователем, и скрипт, который будет выполняться при завершении контейнера.
• Ну и конечно единообразное логирование каждого шага.

Всех проблем конечно не решает, но если для контейнера нужна сложная настройка при запуске, помогает её структурировать и облегчает типичные задачи.

 

Документация

В целом проблем с Alpine не возникает, в основном из-за простоты системы, но если что - всегда на помощь прийдёт wiki, по наполнению она конечно поменьше знаменитой archwiki, но решение большинства проблем в ней есть. Проблемы с установкой ПО, проще всего решаются поиском на docker hub, с большой вероятностью кто-то уже написал нужный Dockerfile, где можно подсмотреть решение. Так же существует forum и судя по всему достаточно активный, но настолько сложных проблем, что бы туда написать у меня ещё не возникало.