Бесплатный инструмент сжимает образы в 30-400 раз без изменений в коде
Небольшой веб-сервис, написанный на Go, занимает 5 мегабайт. Но когда его упаковывают в Docker-контейнер - стандартный способ запускать и доставлять приложения на серверах, - итоговый пакет тянет 700 мегабайт. Никто ничего лишнего специально не добавлял. Просто базовая система, на основе которой собирается контейнер, тащит за собой сотни компонентов: системные утилиты, текстовые редакторы, отладочные инструменты. Вашей программе из всего этого не нужно почти ничего.
SlimToolkit - бесплатный инструмент с открытым кодом - существует именно для того, чтобы это исправить. Без правок в коде, без переписывания инструкций по сборке, без ручного разбора того, что лежит внутри образа.
Почему контейнер на 700 мегабайт несёт программу на полтора
Docker-контейнер - это изолированная среда, в которой запускается приложение вместе со всем необходимым. Образ, то есть упакованный снимок этой среды, включает операционную систему, системные библиотеки и само приложение в одном файле. Когда разработчик берёт стандартный базовый образ - например, на основе Ubuntu или Debian - он получает полноценную Linux-систему: с текстовыми редакторами, инструментами для работы с сетью, утилитами для диагностики. Большинство из этого в рабочем контейнере никогда не запустится ни разу.
Это не ошибка проектирования - так удобнее разрабатывать. Но в итоге на сервер уезжает образ, где 90-95% содержимого - чистый балласт. Его нужно хранить, скачивать при каждом обновлении, платить за место в облаке. И дело не только в деньгах: чем больше компонентов внутри контейнера, тем больше шансов, что один из них окажется с уязвимостью и станет точкой входа для атаки.
Платные инструменты для оптимизации образов существуют, но для большинства задач это избыточно. SlimToolkit закрывает ту же потребность - бесплатно и с открытым кодом под лицензией Apache 2.0.
Что Slim делает, пока работает ваше приложение
Slim не угадывает, что нужно, а что нет. Он запускает ваш контейнер и в реальном времени отслеживает, к каким файлам и библиотекам программа реально обращается. По умолчанию инструмент сам отправляет к веб-приложению набор запросов - перебирает открытые адреса, проверяет ответы. Если нужно, вы дополняете это своими тестовыми сценариями: запускаете автоматические тесты, воспроизводите обычный сценарий работы пользователя. Slim всё это время ведёт учёт. Затем берёт только то, что было использовано, - и собирает новый, компактный образ.
Представьте: вы переехали в новую квартиру и взяли с собой 50 коробок. За полгода вы открыли пять из них. Slim смотрит на это и говорит: остальные 45 - на выброс. Ваша квартира сразу становится просторнее.
Помимо размера, Slim автоматически формирует профили безопасности - специальные ограничения, которые запрещают контейнеру обращаться к системным функциям, которые он в работе никогда не использовал. Как указано в описании проекта, это сокращает поверхность возможной атаки на приложение. Платные решения в сфере безопасности контейнеров берут за похожую функциональность отдельные деньги.
Есть и ещё одна функция - команда xray. Это, по сути, рентген любого образа: показывает, что в нём находится, какие файлы добавлялись на каждом этапе сборки, и даже восстанавливает инструкцию по сборке из готового образа. Если вам достался чужой контейнер без документации - xray расскажет, из чего он сделан. Я не видел, чтобы этот инструмент часто упоминали в обзорах, хотя для работы с унаследованными образами он может оказаться полезнее основной функции.
И последнее: если после оптимизации что-то пошло не так, есть команда debug. Она подключает отдельный контейнер с отладочными инструментами к работающему приложению - вы получаете доступ к файловой системе и оболочке, не добавляя ничего лишнего в сам рабочий образ.
Go: с 700 до 1.56 МБ - результат, который хочется перепроверить
Авторы проекта опубликовали замеры на реальных приложениях. Я перечитал часть цифр дважды.
Go-приложение на базе стандартного образа: 700 мегабайт → 1.56 мегабайта. Уменьшение в 448 раз.
Go компилирует программы в единственный исполняемый файл без внешних зависимостей - поэтому результат такой радикальный. Но и в других языках картина впечатляет:
- Python: 916 МБ → 27.5 МБ (в 33 раза)
- Ruby: 978 МБ → 30 МБ (в 32 раза)
- Node.js (на основе Ubuntu): 432 МБ → 14 МБ (в 30 раз)
- Rust: 2 ГБ → 14 МБ (в 147 раз)
- Haskell: 2.09 ГБ → 16.6 МБ (в 125 раз)
- Java: 743 МБ → 100 МБ (в 7 раз - скромнее, но тоже ощутимо)
Оговорка честная: результат зависит от базового образа и от того, насколько полно удалось воспроизвести работу приложения во время анализа. Если Slim не увидел нужный файл в деле - он его выбросит, и приложение может сломаться. Именно поэтому правильный тестовый прогон во время анализа - не опция, а необходимость.
Где Slim теряет позиции
Некоторые приложения подгружают файлы динамически - только когда пользователь выполняет конкретное действие: открывает нужный раздел, запускает редкую функцию. Если при анализе это не было воспроизведено, нужные компоненты окажутся в мусоре. Разработчики учли это: есть возможность явно перечислить пути, которые должны попасть в итоговый образ при любых обстоятельствах. Но это требует понимания того, как устроено ваше приложение.
Ещё один момент: Slim работает поверх Docker. Без установленного Docker он не запустится. Если сервер использует другую среду контейнеризации - совместимость нужно уточнять отдельно.
Наконец, Slim - инструмент командной строки, то есть управляется текстовыми командами. Привычного окна с кнопками нет. Это не сложно, но требует базового знакомства с терминалом. Установка на Linux занимает несколько минут: скачиваете готовый архив со страницы проекта, распаковываете, кладёте два исполняемых файла в нужную папку. На macOS работает через популярный пакетный менеджер. Подробная инструкция - на странице проекта по ссылке внизу.
Проект набрал 23 000 звёзд на GitHub и принят в CNCF - организацию, которая курирует ключевую инфраструктуру облачных технологий. Там же находятся Kubernetes и другие широко используемые инструменты. Это не гарантия качества, но сигнал определённого уровня зрелости.
Для тех, кто держит хотя бы один сервер с Docker: Slim стоит попробовать на реальном образе. Один тестовый прогон покажет, насколько ваш контейнер можно ужать. В ряде случаев это напрямую влияет на скорость запуска, стоимость хранилища и, что важнее, на безопасность - меньше компонентов внутри означает меньше компонентов с потенциальными дырами.
Скажите в комментариях: вы уже оптимизируете Docker-образы или работаете с тем, что получилось при сборке? И если оптимизируете - как именно?
Источник: SlimToolkit
🔔 КликХак - для тех, кто хочет от своих серверов и устройств максимум, не переплачивая за инструменты. Если этот разбор был полезен - подпишитесь.