Итоги недели в мире бэкенда и обзоры новых сервисов: как уменьшить Docker-образ с помощью многоэтапной сборки

Источник

Многие Dockerfile включают в себя как зависимости для сборки приложения, так и зависимости для его выполнения в продакшене. Это приводит к тому, что в финальные Docker-образы попадает куда больше компонентов, чем необходимо для запуска приложения. А ведь большие образы с ненужными зависимостями не только занимают лишнее место, но и повышают вероятность появления уязвимостей.

У приложений есть зависимости двух типов:

Когда мы используем один и тот же образ для сборки и запуска, то в продакшен попадают лишние инструменты – интерпретаторы, компиляторы, линтеры и т. д. Избежать этого можно только с помощью разделения этапов сборки и выполнения.

Рассмотрим Dockerfile для Go- и Node.js-приложений, где допущены ошибки, приводящие к ненужному раздуванию образов.

Неправильный Dockerfile для Go-приложения

Здесь использован образ golang:1.23, который включает не только скомпилированное приложение, но и весь инструментарий Go вместе с зависимостями – больше 800 Мб, множество из которых становятся уязвимостями в продакшене:

Структура этого раздутого образа выглядит так:

Неправильный Dockerfile для Node.js-приложения

Здесь используются команды npm ci и npm run build. Первая команда устанавливает зависимости и для разработки, и для продакшена. Но при попытке убрать девелоперские зависимости команда npm run build не сможет завершиться, так как для сборки нужны оба типа зависимостей:

Такой докерфайл создает образ с 500 Мб лишних компонентов:

Мы запустили еженедельную email-рассылку, посвященную последним новостям и тенденциям в мире бэкенда. В еженедельных письмах ты найдешь:

Концепция многоэтапной сборки основана на паттерне проектирования «Строитель». Чтобы понять, как этот подход работает в Docker, сначала нужно познакомиться с двумя мощными возможностями Dockerfile – копированием файлов из другого образа и определением нескольких образов в одном докерфайле.

Копирование файлов из другого образа

Одна из самых распространенных инструкций в Dockerfile – это COPY. Обычно команда используется для копирования файлов с хоста в образ:

Однако файлы можно также копировать напрямую из других Docker-образов. Например, можно скопировать файл конфигурации nginx.conf из официального образа nginx:latest прямо в свой текущий образ:

Именно фича COPY --from=<another-image> помогает реализовать паттерн «Строитель» – например, при создании образа для Node.js:

Определение нескольких образов в одном Dockerfile

С 2018 года Docker поддерживает многоцелевые Dockerfile: в одном файле можно указать несколько инструкций FROM, каждая из которых создает отдельный целевой образ. Здесь определены три разных образа с их собственными настройками:

Эта особенность позволяет выбрать цель сборки с помощью параметра --target в команде docker build, давая возможность одному Dockerfile создавать разные образы в зависимости от выбранной цели:

1. Собрать образ на основе первого FROM:

2. Собрать образ на основе второго FROM:

3. Собрать образ на основе третьего FROM:

Как использовать эти две возможности для многоэтапной сборки

Dockerfile для сборки и Dockerfile для выполнения можно объединить в один файл с несколькими инструкциями FROM. Здесь на первом этапе происходит сборка приложения с помощью npm run build, а второй этап копирует результат сборки и запускает приложение:

Важно помнить:

Приложение на Go

Go-приложения всегда компилируются на этапе сборки. Итоговый бинарник может быть двух типов:

В большинстве случаев выбор базового образа для этапа выполнения не меняет структуру многоэтапного Dockerfile – вы просто выбираете подходящий образ в зависимости от нужного типа бинарника:

Приложение на Rust

Rust-приложения обычно компилируются из исходного кода с помощью утилиты cargo. Официальный Docker-образ для Rust включает cargo, rustc (компилятор) и другие инструменты для разработки и сборки. Из-за этого размер образа получается довольно большим – почти 2 Гб. Поэтому для Rust-приложений обязательно используют многоэтапную сборку, чтобы итоговый образ для выполнения приложения был как можно более компактным и не содержал лишних инструментов. Финальный выбор базового образа для этапа выполнения будет зависеть от того, какие библиотеки нужны вашему Rust-приложению:

Приложение на Java

Java-приложения компилируются из исходного кода с помощью Maven или Gradle, и для их выполнения нужна Java Runtime Environment (JRE). Когда Java-приложение запускается в контейнере, обычно используют разные базовые образы для этапов сборки и выполнения. На этапе сборки нужен Java Development Kit (JDK), который включает инструменты для компиляции и упаковки кода. А вот для этапа выполнения достаточно более легкой Java Runtime Environment (JRE), так как она содержит только необходимое для запуска приложения. Dockerfile выглядит намного сложнее, чем сценарии для приложений на Go и Rust, поскольку файл для Java включает дополнительный этап тестирования, да и сам процесс сборки включает больше действий:

Время ожидания (latency) – это время, которое требуется на доставку пакета данных от источника к пункту назначения. В контексте распределенных систем это особенно важно: данные хранятся и обрабатываются на разных серверах, и высокая задержка может сделать приложение практически непригодным к использованию. А медленные приложения раздражают пользователей даже больше, чем совсем неработающие: те, по крайней мере, не тратят зря их время. Поэтому разработчикам стоит уделять особое внимание выбору оптимальной стратегии (или их комбинации) для максимального снижения времени ожидания.

Кэширование – базовая техника улучшения производительности и уменьшения нагрузки на бэкенд-сервисы в распределенных системах. Основная цель кэширования – минимизировать затратные запросы к базе данных и избегать повторного выполнения высокозатратных вычислений. Для этого часто запрашиваемые данные хранятся в кэше, что позволяет быстро их получать, а не тратить время на обращение к источнику (базе данных или удаленному сервису).

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

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

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

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

Когда клиент отправляет запрос в распределенную систему, балансировщик нагрузки становится первым пунктом контакта. Он получает запрос и перенаправляет его на один из доступных серверов, исходя из заранее заданных алгоритмов. Наиболее распространенные алгоритмы балансировки нагрузки включают:

Подробнее алгоритмы балансировки нагрузки разобраны здесь.

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

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

Отдельный фоновый процесс (или пул процессов) постоянно следит за этой очередью, извлекая задачи, как только они становятся доступными. Рабочий процесс выполняет долгосрочную задачу асинхронно, не блокируя основной поток приложения и не влияя на отзывчивость системы. Это позволяет системе оставаться быстрой и отзывчивой, даже если некоторые операции занимают много времени.

Базы данных могут стать значительным источником задержек. Для обеспечения оптимальной производительности базы данных и более быстрого выполнения запросов важно правильно настроить индексы и выявлять, а затем оптимизировать медленные запросы. Индексы – это специальные структуры данных, которые значительно ускоряют поиск и извлечение данных из базы данных. Если для часто используемых столбцов или их комбинаций создаются индексы, база данных может быстро найти нужную информацию, не просматривая всю таблицу.

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

Алгоритмы сжатия находят и удаляют повторяющиеся элементы в данных, заменяя их более компактными представлениями. В результате:

Предварительное кэширование – техника, при которой данные заранее загружаются в кэш до того, как они действительно понадобятся пользователю. Система предварительного кэширования анализирует, какие данные, скорее всего, потребуются пользователю (например, похожие товары в онлайн-магазине или музыкальные треки в стриминговом сервисе). Когда пользователь запрашивает эти данные, они уже готовы к быстрой выдаче.

TCP-рукопожатие (процесс установления соединения между клиентом и сервером) требует как минимум 3 этапа обмена данными:

Каждое такое «рукопожатие» занимает время и ресурсы. Постоянное соединение (Keep-Alive) решает эту проблему и позволяет существенно ускорить работу веб-приложений за счет повторного использования существующих соединений вместо создания новых:

Автор рассылки: Наталья Кайда