Обложка канала

ServerAdmin.ru

12437 @srv_admin

Авторская информация о системном администрировании.

ServerAdmin.ru

3 года назад
Открыть в
​​С появлением Docker стали бурно развиваться контейнеры. Одним из главных преимуществ по сравнению с виртуальными машинами была скорость запуска и размер контейнеров, а также экономия ресурсов хостовой машины. Разработчики активно начали развивать идею с размером образов. Насколько маленьким он может быть? Сначала по привычке использовали образы на основе традиционных Linux систем - Debian, Centos и т.д. Потом появился очень маленький Alpine, затем пустой образ scratch. Сейчас дошли до distroless образов, где вообще нет привязки к какой-то конкретной системе. Насколько я могу понять архитектуру подобных образов, там только ядро Linux, а из user space вырезано вообще всё (пакетный менеджер, оболочки и т.д.), что не требуется для запуска приложения. В погоне за минимализмом как-то стали забывать о производительности. Я встречал информацию, что некоторые приложения в образах Alpine работают заметно медленнее. Разница с типовым образом на Debian может достигать 20-30%. А ещё все эти минимальные образы очень неудобно отлаживать. В итоге экономия места оборачивается повышенной тратой рабочего времени разработчиков и поддержки. Насколько я понимаю, вся эта тема с минимализмом актуальна на очень больших инфраструктурах с сотнями серверов и тысячами контейнеров. Первые distroless образы анонсировал Google. У него есть несколько базовых образов для python, java, nodejs. Сейчас эту тему подхватили и начали развивать. Например, есть большая коллекция готовых distroless образов у chainguard. Там не только среда исполнения для различных языков, но и distroless образы nginx, php, posgresql и т.д. 💡Я к чему всё это написал. Если у вас нет большой необходимости в очень маленьких образах, то не используйте всех этих кастратиков. Постоянно приходится пользоваться готовыми образами. Очень не нравится, когда внутри ничего нет. Экономия на спичках оборачивается потом лишними хлопотами в отладке. #docker #devops