Если вы хотите, чтобы ваши приложения запускались быстрее, а docker-образ был меньше, тогда вам стоит попробовать Alpine в качестве базового образа.

Уже давно не секрет, что Docker часто использует Alpine в качестве базового образа для официальных docker-образов. Эта тенденция началась в начале 2016 года. Сейчас почти каждый официальный docker-образ имеет тег Alpine.

Но вряд ли будет так, что вы проснетесь одним прекрасным утром и подумаете: “О! А почему бы мне не использовать другую ОС для всех своих образов”. Тем более, когда до этого по умолчанию официальным образом был Debian. И позиции его были весьма прочными.

Вы всегда можете выбрать docker-образы на основе Debian. Но лучшее ли это решение?

Почему Alpine?

Звучит, конечно, интересно. Но что это значит для тех, кто регулярно использует Docker?

Главное преимущество - сжатие размеров

Если вы используете Docker, то вы должны стремиться к этому сжатию. Благодаря этому ваш docker-образ будет меньше.
Apline 3.6 весит всего 3,98 мб.

Вот сравнение с другими дистрибутивами:

Получается, что Alpine в 25 раз меньше Debian’а.

Всего с Docker Hub были сделаны уже миллионы пулов. Немного покопавшись с его публичным API, можно увидеть, что у Debian 45 275 515 пулов, в то время как у Alpine -целых 397 152 768 (по состоянию на 10.10.2017).

Уменьшение образа на 100 мб может иметь большое значение.

В реально используемых веб-приложениях, в которых установлено множество пакетов, можно заметить 2-3 - кратное уменьшение конечного образа с Alpine. Экономия этих 100 мб останется всегда, вне зависимости от того, что встроено в ваш образ.

Сравним размер некоторых образов на основе Alpine и разных версиях Debian:

• Redis на основе alpine весит 27,5 мб, а на jessie - 107 мб
• Python на основе alpine- 89 мб, а на основе jessie - 690 мб
• Golang на основе alpine - 270 мб, а на основе stretch- 733 мб

Конечно, если вы захотите использовать образ в реальном приложении, вам надо будет установить несколько зависимостей, поставить необходимые библиотеки и т.д через dockerfile. Все это приведет к “утяжелению” dockerfile’а. Но даже если сравнивать конечный dockerfile на основе debian и alpine, то последний будет легче.

Образ на Alpine следует использовать, когда конечный образ должен быть как можно меньше. Чтобы образы на основе Alpine были меньше, туда не включены такие инструменты, как git или bash. Если вы используете Alpine в качестве основы образа, то для установки необходимых вам пакетов их нужно добавить в dockerfile.

Alpine быстрый

Уменьшение размеров не единственное преимущество использования маленьких docker-образов.

Изначально цель была, чтобы система запускалась из RAM. То есть, это “одноразовая” система, которая переустанавливается после каждого перезапуска. И это отлично вписывается в концепцию контейнеров.

Да, такими дистрибутивами, как Debian или Ubuntu пользовать легче, но они слишком большие и медленные по сравнению с Alpine. apt-get update тратит столько же времени на обновление списка актуальных пакетов, сколько Alpine тратит на установку или обновление всей системы. В Alpine используется свой менеджер пакетов apt-tools (ничего общего с форматом.apk в Android). Apk расшифровывается как “alpine package keeper”. Поскольку Alpine должен быть очень легкой системой, то нужен очень быстрый менеджер пакетов. В одном интервью один из разработчиков Alpine говорил: “Мы рассматривали pacman от arch linux, также deb, ipkg, .rpm и другие. Но приняли решение использовать свой менеджер пакетов, руководствуясь требованием “run-from-ram”.

Alpine безопасный

Еще одно преимущество того, что образ не занимает много пространства, заключается в том, что не так много целей для атаки.
Когда в системе мало пакетов и библиотек, шанс того, что что-то пойдет не так заметно снижается.

Для обеспечения безопасности системы разработчики делают упор не на фикс багов, которые привели к уязвимости, а делают все, чтобы эти баги не появились. В ядре системы минимально компонентов. В Alpine не устанавливается ничего, чем пользователи никогда не будут пользоваться. Например, BashShell. Вместо него используется по умолчанию используется BusyBox Bash. Кроме того, Alpine предоставляет блоки, из которых пользователь сам собирает то, что ему надо. Во многих дистрибутивах дела обстоят иначе: многие компоненты включены по умолчанию, и пользователям приходится самостоятельно отключать некоторые компоненты, чтобы обеспечить безопасность системы. И если находится библиотека, которая по мнению разработчиков более безопасна, то они ее меняют. Так они заменили OpenSSL на LibreSSL, т.к. по мнению разработчиков Alpine, эта библиотека является более безопасной.

Несколько лет назад существовал bash-эксплойт, который позволял получить контроль над машиной, если она поражена так называемым “Shellshock”. Alpine таким атакам не был подвержен, так как по умолчанию bash там не установлен.

Установка пакетов на Alpine

Как я уже писал, для управления пакетами в Alpine используется apk. И некоторых пакетов, которые вам будут нужны, по умолчанию не будет в Alpine. Придется ставить их самостоятельно. Названия пакетов для Debian и Alpine будут отличаться. Например, чтобы установить пакет, который в Debian называется libpq-dev, в Alpine надо прописать apk add postgresql-dev.

Используйте лучший инструмент для работы

Alpine он делает все, чтобы быть легким и безопасным дистрибутивом. Поэтому использование Alpine в качестве основы для Docker-образа является оптимальным решением.

P.s. Спасибо моим коллегам из

По зову сердца и работе в Digital Design в качестве системного инженера, мне часто приходится сталкиваться с переусложненными программными продуктами и архитектурными конструкциями. Это вызывает страстное желание минимизации и упрощения всего, что попадается под руку, и приводит к восторгу от человеческих решений, просто делающих свою работу, без регистрации и смс.

Так я и познакомился с Alpine Linux.

Этот дистрибутив может вам понравиться по следующим причинам:

• Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
• Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
• Если вы захотели решить имеющуюся задачу простым способом.

Под «мэйнстримом» я подразумеваю тройку CentOS - Debian - Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы. При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?».

Оно нам действительно надо?

$ holywar mode disable
Неужели для решения вашей небольшой задачи требуется все это:

Замечательная systemd. Система инициализации (уже не совсем), которая может произвести впечатление системы управления шаттлом?

Ненене!

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

Подсистема журналирования / аудита, построенная на связке вроде journald → rsyslogd + auditd?




Несомненно, это здорово!

Можно догадываться, почему это сделано именно так, но действительно ли для моей простой задачи требуется такая цепочка?

Дублирование функциональности периодического выполнения задач как в systemd, так и в crond?

Ох уж этот Cron!

Неужели мне не хватает его классического механизма? Возможно, его синтаксис может быть не совсем очевиден, но так ли очевидны таймеры в s-d?

Сосуществование нескольких подсистем управления сетью в разных сочетаниях: классический networking / networkd / NetworkManager?

Управлять сетью надо много!

Такое сочетание, да на серверной системе, да с несколькими интерфейсами управления на все вкусы. Хотя нет, давайте добавим сюда еще и netplan, «решающий» проблему конфигурации для перечисленных подсистем. Вам свой сервис хочется завести, или часто менять орбиту за счет переконфигурирования сетевых интерфейсов?

Сервисы вида tuned и firewalld?

Как же без них?

Так ли они нужны для вашей задачи? В принципе, неплохо рассматривать firewalld как попытку сбежать от синтаксиса iptables, но в результате вы вместо одного синтаксиса будете разбираться в другом и недоумевать от размера команд firewall-cmd. И вам действительно в базовой системе нужен интерпретатор python и его процессы? Нет, я люблю python, но не в этом случае.

Локальный почтовый сервис. Вы точно будете его использовать?

Раз уж мы вспомнили про минимализм, можно очень грубо сравнить наши дистрибутивы-лидеры в их минимальном варианте установки:

• Лидером избыточности по дисковому пространству и числу пакетов оказывается Ubuntu 18.04 (2,8 ГБ дискового пространства, 342 пакета, 31 активный сервис systemd, 15 процессов при входе). Семейство systemd тут представлено в максимальном объеме - systemd, networkd, timesyncd, resolved, logind, есть dbus.
• CentOS 7.5.1804 проигрывает по диску и числу пакетов, но лидер по вероятно-избыточным сервисам (1.1 ГБ дискового пространства, 299 пакетов, 34 активных сервиса systemd, 19 процессов при входе, среди которых - NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
• Debian 9.4.0 пытались сильно не надувать: 940 МБ, 334 пакета, 25 активных сервисов systemd, 14 процессов при входе. Само собой, тут тоже есть systemd (а также journald, timesyncd и сопутствующий dbus), но без особого фанатизма в части управления сетью.

holywar: cannot change mode to ‘disable’: Permission denied

Хочется странного

От части перечисленного выше можно (попробовать) избавиться вручную, но вдруг все уже придумано за нас? В идеале, от дистрибутива серверной операционной системы общего назначения хочется видеть:

• Как ни странно, загрузчик, который дотянет нас до ядра;
• Само ядро ОС (в рассматриваемом случае - linux);
• Система инициализации, которую ядро запустит по готовности. Желательно, по простоте недалеко ушедшая от топора;
• Минимальный набор процессов, который запустит система инициализации. Ну например:
  • Окончательная инициализация устройств и определение дополнительных параметров ядра;
  • Обеспечение журналирования (можно с текстовыми журналами? Ну пожалуйста);
  • Конфигурация сети (хорошо бы, с меньшим числом управляющих прослоек);
  • Синхронизация времени (ntpd / chronyd);
  • Несколько локальных консолей;
  • Опционально - периодическое выполнение задач (сrond);
  • Опционально - удаленный доступ к системе (sshd);
  • Хорошо бы еще сохранять и восстанавливать конфигурацию межсетевого экрана.

И на этом почти все, остальное - дело менеджера пакетов. Меньше исполняемого кода и конфигурации – меньше багов, меньше багов – меньше багов. А система все также запущена и доступна по сети. Идея выглядит неплохо, теперь посмотрим, насколько близок к ней дистрибутив Alpine Linux .

Про Alpine

Чем может очаровать Alpine, особенно после CentOS? Отчаянным минимализмом!
Ну и, конечно, отсутствием необходимости сертификации «Linux Systemd Certified Voldemort ».

• Понизили число используемых базовых компонентов;
• Выбрали модули поменьше и попрозрачнее;
• Упростили процесс конфигурирования системы.

А именно:

• Чрезвычайно лаконичный процесс установки с использованием консольной утилиты setup-alpine;
• В качестве загрузчика взят extlinux из состава проекта syslinux;
• Небольшой инструмент сборки mkinitfs для создания временной файловой системы, используемой при загрузке;
• Система инициализации openrc с определением зависимостей между сервисами, уровнями запуска и щепоткой скриптования;
• Замена стандартной библиотеки GNU libc на более легковесную musl libc;
• Вместо пакета GNU coreutils большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который может быть Вам знаком по встраиваемым решениям;
• По умолчанию используется командный интерпретатор ash в составе busybox. Само собой, никто не мешает при необходимости поставить bash , ну и systemd ;
• Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.

• Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же); Уже нет, спасибо коллеге из комментариев. Как раз 26 июня вышла версия 3.8.0 .
• Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.

В итоге мы получаем систему, снабженную рядом дополнительных механизмов защиты, позволяющую решить имеющуюся задачу и занимающую около 130 МБ . В запущенной системе установлен 41 пакет и выполняется 13 пользовательских процессов, можно стучаться по ssh.

И больше ничего. Осталось добавить то, что нужно вам (да и iptables с возможностью восстановления конфигурации при старте поставьте).

Приоткроем крышку

Обратите внимание – Alpine может пригодиться как учебная площадка при ознакомлении с ОС Linux! Увидеть логику работы компонентов субъективно проще, чем пытаться охватить сходу CentOS или Ubuntu:

• Загрузчик нашей установленной системы прост, его конфигурация влезает в 12 строк:

• Да и в /boot не слишком многолюдно:

• А вот и запущенный загрузчик без модных обоев:

• Ядро загружается, подхватывает initramfs, отрабатывает собственные шаги инициализации и вызывает команду init (которая, на самом деле, тоже идет в составе busybox). Init использует файл /etc/inittab:

• И тут в явном виде прописано, что нужно запустить для инициализации системы:
  • Запустить 6 процессов getty, ожидающих на 6 виртуальных консолях локального входа пользователя.
  • Запустить систему инициализации openrc для поочередного достижения требуемых уровней инициализации (openrc использует не классические уровни инициализации 0-6, а собственные уровни/группы sysinit - boot - default).

• Переменных, заданных в файлах каталога /etc/conf.d;
• Скриптов запуска, находящихся в каталоге /etc/init.d;
• Привязки скриптов запуска к «группам инициализации»:

Как видите, это не всегда эти ваши нелюбимые "портянки":

Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /etc/conf.d/syslog. В нашем случае, в файле определена переменная SYSLOGD_OPTS="-Z".
Обратите внимание - в скрипте декларативно определены зависимости данного сервиса.

Openrc честно перебирает в заданном порядке скрипты запуска, достигает уровня «default» - и вот она, рабочая система!

Демоны под крышкой

Что же именно скрывается под скриптами запуска openrc? Как ни странно - набор задач и демонов, перечисленных ниже.

• Сначала, на уровне sysinit:

  • dmesg - выставляется уровень журналирования для сообщений от ядра;
  • devfs - монтируется и настраивается /dev;
  • mdev - запускается менеджер устройств;
  • hwdrivers - загружаются модули устройств на основе информации из /sys и /dev;

• Следующим идет уровень boot:

  • modules - загружаются модули ядра, перечень которых определен в /etc/modules;
  • hwclock - настраиваются аппаратные часы реального времени;
  • sysctl - задаются параметры ядра, определенные нами в /etc/sysctl.conf;
  • swap - подключается swap-раздел;
  • bootmisc - очищаются временные каталоги;
  • urandom - настраивается генератор случайных чисел;
  • keymaps - инициализируется раскладка клавиатуры;
  • hostname - задается имя машины, которое определено в /etc/hostname;
  • networking - поиск и инициализация интерфейсов с использованием информации из /etc/network/interfaces;
  • syslog - запускается демон журналирования из состава busybox;

• И наконец, уровень default:

  • chrony - запускается NTP-сервис;
  • crond - запускается сервис выполнения задач по расписанию;
  • acpid - запускается сервис отслеживания событий питания;
  • sshd - запускается сервис удаленного доступа.

Ура, после выполнения этих шагов система готова к работе! Не забудем и про зависимости от перечисленных выше сервисов, которые были заданы в init.d файлах:

• sysfs - монтирование /sys;
• fsck - проверка и исправление файловых систем;
• root - монтирование корневой системы на запись/чтение;
• localmount - монтирование всех файловых систем, перечисленных в /etc/fstab;
• klogd - журналирование событий ядра.

Открываем одну из локальных консолей, где нас поджидает getty, вводим логин, после чего передаем пароль процессу login и получаем доступ к запущенному командному интерпретатору ash (при запуске которого выполняется содержимое файлов /etc/profile, /etc/profile.d/* и ~/.profile для подготовки пользовательского окружения).

Ура, никаких дополнительных сущностей (несомненно, полезных в ряде случаев, вроде PAM) - а мы в системе!

Осталось воспользоваться пакетным менеджером apk, и поискать нужные нам для нашей задачи пакеты. (Есть ли они там? Можно оценить это через веб-портал).

А еще

• Авторы дистрибутива сделали свою собственную надстройку над iptables под названием «Alpine Wall». И она не висит постоянно отдельным процессом в системе;
• Для тех, кто любит управлять сервером через веб-интерфейс, подготовлен пакет «Alpine Configuration Framework». Без PHP или Perl, но с Lua;
• Для тех, кто желает рабочего стола, есть возможность установки графической среды (хотя это может оказаться больно в начале);
• Для особых ценителей имеется «установка» Alpine в памяти с хранением конфигурации на внешнем хранилище (см. описание инструмента lbu).

Итог

Дистрибутив Alpine не идеален, но его лаконичность меня действительно впечатлила, особенно в роли контейнера (всего 6 процессов - init, 4*getty, syslogd). Для меня он выглядит так, как должна выглядеть минимальная серверная операционная система (прости меня, CentOS!).

Кроме того, он вполне подходит на роль учебной площадки, позволяющей увидеть, из чего состоит современный дистрибутив, не погружаясь сразу в пучину whateverd-сервисов и многократного дублирования функциональности в великолепно-многоуровнево-конфигурируемых-средствах на все случаи жизни.

Alpine Linux - один из самых компактных и нетребовательных к железу дистрибутивов Linux, ориентированных на безопасность пользователя. Зачастую его можно встретить во многих встраиваемых системах. Alpine Linux прекрасно подходит для таких задач как создания контейнеров, организации серверов или ознакомления с основами Линукс, поскольку дистрибутив не отягощён избыточным функционалом, но при этом поддерживает установку любой популярной графической среды.
Дистрибутив основан на BusyBox вместо GNU coreutils. Alpine будет хорошим выбором для пользователей, которые ищут упрощенный вариант для работы с минимальным набором функций, при этом максимально эффективный и полезный:

• Небольшое количество базовых компонентов, которые благоприятно сказываются на размерах оболочки - без ядра базовая система весит всего около 5 МБ;
• Быстрая и простая установка через консольную утилиту;
• Удобные настройки конфигурации системы пользователем;
• В дистрибутиве применены свежие версии ядер, а также реализована возможность применять патчи, повышающие степень безопасности системы. Также реализована защита стека от переполнения.

Также в Alpine linux имеется большинство необходимых для комфортной работы пользователя пакетов. Сюда входят GNOME, Firefox и ряд других, кроме пока что не портированного KDE. Есть патчи grsec и PaX, встроенные в ядро дистрибутива, что помогает защититься от эксплойтов.

Ссылки для скачивания Alpine Linux:

Название	Версия	Разрядность	Образ	Размер	Ссылка
Alpine Extended	3.8.2	64-bit	ISO	369 Mb	Скачать
Alpine Extended	3.8.2	32-bit	ISO	355 Mb	Скачать
Alpine Standart	3.8.2	64-bit	ISO	104 Mb

Installation Quick-Start in 3 Easy Steps

Installation Handbook

Alpine can be booted or not, just use it. Alpine Linux installation process are so flexible that indeed can just boot up inside other broken Linux. You believe that every system needs a DVD disc, or a USB to install it?, but Alpine may not even need it , so much so that it can even boot from its phone memory. Obviously the more exquisite the more complicated method .

A proper setup of your system are need, but if you deploy all of an ecosystems in your own home and job.. in your only machine... you will need a proper guide to setup your main system (or maybe a parallel system?).

As any Linux installation, Alpine start process by booting from an external device (CD/DVD, USB Drive, etc...).

As Alpine uses Linux kernel, start step of collecting information to initialize a minimum system, the setup-alpine will copy files. This minimun system started before proceed to property install are a diskless mode started from the orig medium.

The post installation step provides the way to choose the root password, and eventually boot up the new installed system.

Overview of run modes for Alpine system

Alpine can be used in any of three modes respected the install process :

diskless mode

You"ll boot from a read-only medium such as the installation CD, a USB drive , or a Compact Flash card .

Tip: To prepare either a USB or Compact Flash card, you can use the setup-bootable script; see the pages linked above for details.

This mode may be used for desktops , development boxes, and virtual servers.

Further Documentation

Post-Install

• Package Management (apk) (How to add/remove packages on your Alpine)
• Alpine local backup (lbu) (Permanently store your modifications in case your box needs reboot)