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

Создание собственного реестра контейнеров – оптимальное решение, если:

Автор этой публикации разобрал по шагам процесс реализации такого реестра.

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

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

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

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

Существует несколько опенсорсных решений для создания реестров контейнеров. Наиболее популярное, однако, – это официально поддерживаемый Docker registry. Этот реестр предназначен для хранения и распространения образов контейнеров и артефактов, и он запускается прямо в контейнере.

Основные шаги для создания реестра:

Установка Docker и Docker Compose

Для начала вам понадобится сервер с установленным Docker. Например, это может быть виртуальная машина с Ubuntu на любой подходящей платформе. Установите Docker и Docker Compose (он упрощает управление приложениями со множеством контейнеров):

Конфигурация реестра

Для настройки контейнера реестра нужно создать файл compose.yaml со следующей конфигурацией:

Будут созданы два тома: один для хранения образов, второй для хранения файла с паролями. Для аутентификации пользователей необходимо создать файл с паролями с помощью команды htpasswd. Например, добавим пользователя busy с паролем bee:

Теперь можно запустить реестр командой docker-compose up. Если все настроено правильно, вы увидите сообщение о том, что реестр слушает порт 5000:

Настройка nginx для обработки TLS

Для безопасности реестр должен использовать защищенное SSL-соединение. Для проксирования запросов и обработки TLS можно использовать nginx, а для получения SSL-сертификата – Let’s Encrypt. Сертификат сохраняется в директории ./nginx/certs. В файле compose.yaml добавим секцию для nginx:

Пример файла конфигурации nginx (nginx.conf):

После настройки запустите контейнеры с реестром и nginx:

На стороне клиента необходимо войти в реестр:

Теперь можно создавать и загружать образы в наш реестр:

Для запуска реестра при желании можно использовать Kubernetes. Если требуется пользовательский интерфейс, пригодится joxit/docker-registry-ui. Полный код проекта есть в репозитории автора, а на YouTube можно посмотреть ролик о создании реестра.

Существуют три основных подхода к отправке сообщений, и каждый представляет собой определенный компромисс между надежностью, производительностью и сложностью реализации:

Разберем нюансы, преимущества и недостатки каждого из этих подходов.

Как работает:

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

Однако, если произойдет более серьезный сбой (например, сбой сети или поломка узла брокера), сообщение может быть утеряно, и система об этом не узнает.

Плюсы:

Минусы:

Когда использовать:

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

Как работает:

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

Плюсы:

Минусы:

Когда использовать:

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

Как работает:

Асинхронная отправка похожа на стратегию «отправить и забыть» с той лишь разницей, что вы используете функцию обратного вызова для обработки подтверждения или ошибок от Kafka. Программа не блокируется, как при синхронной отправке, но при этом есть возможность обработать успешное подтверждение или ошибку в коллбэке.

Плюсы:

Минус:

Когда использовать:

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

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

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