Докер: Являются ли образы узла alpine в конце меньше, чем образы полного узла?
Я запускаю кластер приложений nodeJS, который должен быть очень маленьким, поскольку они выполняются как микросервисы. Лишь немногим из них нужны дополнительные вещи, такие как bcrypt или imagemagick, что время от времени доставляет мне некоторые проблемы.
Сейчас я использую node:10.13-alpine в качестве базового образа для всех файлов Docker для создания своих приложений. Для некоторых из них мне нужно добавить зависимости через apk и так далее. Итак, эти изображения становятся больше. Это лучший подход - использовать альпийский образ, который становится больше за счет добавления необходимых пакетов (например, python, gcc ...)? Или использовать полный образ?
Если бы я использовал node:10.13, базовое изображение было бы намного больше, но если я правильно понимаю, мои приложения добавили бы только небольшой слой, поскольку используется тот же базовый образ. Так что в конце лучше использовать один большой образ узла ??
Ответы 3
Образы Alpine меньше по размеру, поскольку другие пакеты используют множество библиотек, которые не используются вашим решением.
В чем преимущества использования маленьких изображений?
Преимущества: меньше памяти, лучшая производительность, безопасность и удобство обслуживания.
Образ докера меньшего размера уменьшает необходимый размер на диске, но дисковое пространство дешево.
Гораздо важнее то, что это также потреблять меньше памяти, который ограничен на каждом сервере. Если вы уменьшите количество базовых образов на вашем сервере, это также приведет к тому, что вам понадобится меньше памяти. Меньше памяти означает, что у вас меньше свопинга, и вы можете получить некоторые улучшения производительности, загрузив все базовые образы в память.
Еще одна особенность заключается в том, что базовые образы из alpine используют менее зависимые библиотеки, которые улучшить общую безопасность. Вы можете легко разделить риски, используя ваше базовое изображение alpine и изображения, которые используют только apk, который действительно необходим. Это также дает преимущества в отношении общего обслуживания.
На https://hub.docker.com/r/library/node/tags/ видно, что альпийская версия не имеет уязвимостей. У всех других версий образа есть некоторые проблемы, которые могут быть нацелены на безопасность вашего решения.
Почему по умолчанию все еще используется buildpack-deps и почему вам, возможно, стоит их использовать?
Когда вы читаете официальную документацию к изображениям докеров для узла:
https://hub.docker.com/_/node/
Основные выводы:
- Вы можете использовать обычный образ, так как он основан на «buildpack-deps», то есть обычно используется во многих изображениях.
- Изображения Alpine очень маленькие и уменьшают объем необходимой памяти. Тем более другого типа установки докер-контейнера нет.
Для меня это, наконец, означает, что вы можете использовать обычный пакет в большинстве случаев, если вы используете другие образы, созданные на "buildpack-deps". Возможно, это может быть лучшим решением в этом случае, поскольку у вас нет необходимости, кроме buildpack-deps, для хранения базового образа «alpine» на вашем диске и в памяти.
Заключение
Если у вас есть «только» образы alpine в вашей среде докеров, тогда вам следует выбрать «alpine» или если безопасность контейнеров «node» действительно важна для вас.
В большинстве случаев подходят образы «узлов», основанные на «buildpack-deps», поскольку у вас есть другие докер-контейнеры, основанные на «buildpack-deps».
Я предполагаю, что в будущем будет доступно все больше и больше пакетов, основанных на "alpine", и тогда вам следует использовать node -alpine.
В общем, да, изображения alpine лучше официальных изображений узлов, который поставляется с предварительно запеченными двоичными файлами.
Но это очень специфический случай.
- Если у вас есть тяжелая настройка, вы все равно можете добавить зависимости даже с официальным образом узла.
- Если у вас не так много настроек, добавление небольших зависимостей в node alpine не будет стоить вам больших затрат с точки зрения размера и времени сборки по сравнению с официальными образами узлов.
- Если у вас сложные зависимости (иногда документы могут быть плохими), все будет работать нормально в официальном образе узла, но вам нужно будет изо всех сил, чтобы все работало в node alpine, и все равно он будет нестабильным. (Это случилось со мной однажды с пакетом
libpng16-dev, и он работал только с официальным образом узла, и я не мог понять, почему он не работал с узлом alpine даже после нескольких дней попыток).
Итак, в заключение, обычно рекомендуется выбрать node alpine, если у вас нет сложной настройки, а официальный образ node упрощает вам задачу.
Почти все контейнеры узлов, с которыми я работал, 90% из них работают на образе alpine.
Если вы используете nodejs 10 или выше, рассмотрите проблемы утечки памяти, обнаруженные с помощью alpine: