понедельник, 19 сентября 2016 г.

Хватит использовать 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 и судя по всему достаточно активный, но настолько сложных проблем, что бы туда написать у меня ещё не возникало.

Комментариев нет:

Отправить комментарий