[Перевод] Как масштабируется бизнес Docker для обслуживания миллионов разработчиков, часть 2: Исходящие данные

po-46qfjunh9cour_41gqebpqoq.jpeg

Это вторая статья из серии статей, в ней будут рассмотрены ограничения при скачивании образов контейнеров.

В первой части мы подробно рассмотрели образы, хранимые в Docker Hub, крупнейшем registry образов контейнеров. Мы пишем об этом для того, чтобы вы лучше понимали, как наши обновленные Условия обслуживания повлияют на команды разработчиков, использующих Docker Hub для управления образами контейнеров и конвейерами CI\CD.

Об ограничениях по частоте скачивания было объявлено ранее в наших Условиях обслуживания. Мы подробнее рассмотрим ограничения по частоте, которые вступят в силу с 1 ноября 2020 года:

Бесплатный тарифный план, анонимные пользователи: 100 скачиваний за 6 часов
Бесплатный тарифный план, авторизованные пользователи: 200 скачиваний за 6 часов
Тарифный план Pro: без ограничений
Тарифный план Team: без ограничений

Частота скачиваний со стороны Docker определяется как число запросов манифестов к Docker Hub. Ограничения по частоте скачивания образов зависят от типа учетной записи, запрашивающей образ, а не от типа учетной записи владельца образа. Для анонимных (неавторизованных) пользователей частота скачивания привязана к ip-адресу.

N.B. Больше тонкостей и best practice кейcов вы получите на курсе Docker от практиков. Причём вы можете проходить его, когда вам удобно — и по времени, и по настрою.

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


Подробный анализ частот скачивания образов Docker Hub

Мы потратили много времени анализируя скачивание образов из Docker Hub, чтобы определить причину ограничения скорости, а также как именно нужно ограничивать. То, что мы увидели, подтвердило, что фактически все пользователи скачивают образы с предсказуемой скоростью для типовых рабочих процессов. Однако есть заметное влияние небольшого числа анонимных пользователей, например порядка 30% всех скачиваний исходят только от 1% анонимных пользователей.

kdi3dpzmriptvl-rccgyhw8jn44.png

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


Помощь разработчикам для лучшего понимания ограничения частоты скачивания

Сейчас, когда нам стало понятно влияние, а также где должны быть границы, нам надо было определить технические условия работы этих ограничений. Ограничивать скачивание образов из Docker registry достаточно сложно. Вы не найдете API для закачек в описании registry — его просто не существует.По факту скачивание образа представляет собой комбинацию запросов манифеста и blobs в API, а они выполняются по-разному, в зависимости от состояния клиента и запрашиваемого образа.

К примеру, если у вас уже есть образ, Docker Engine выдаст запрос на манифест, поймет, что у него уже есть все необходимые слои на основе принятого манифеста, после чего остановится. С другой стороны — если вы скачиваете образ, поддерживающий несколько архитектур, запрос на манифест вернет список манифестов образов для каждой поддерживаемой архитектуры. Затем Docker Engine выдаст еще один запрос на манифест касательно конкретной архитектуры, на которой он работает, в ответ получит список всех слоев образа. Затем он будет запрашивать каждый отсутствующий слой (blob).

N.B. Более широко эта тема раскрыта на курсе Docker, в котором мы разберем все его инструменты: от основных абстракций до параметров сети, нюансов работы с различными ОС и языками программирования. Вы познакомитесь с технологией и поймете, где и как лучше использовать Docker.

Получается, что скачивание образа это на самом деле один или два запроса манифеста, а также от нуля и до бесконечности — запросы слоев (blob). Исторически Docker отслеживал частоту скачивания на основе слоев, поскольку это наиболее связано с использованием полосы пропускания. Но тем не менее, мы прислушались к сообществу, что так сложнее, ведь нужно отслеживать запрашиваемое число слоев, что приведет к игнорированию best practices касательно работы с Dockerfile, а также интуитивно непонятнее для пользователей, желающих просто работать с registry, не сильно разбираясь в деталях.

Так что мы ограничиваем число запросов на основе запросов на манифесты. Это напрямую связано с скачиванием образов, что легко понять пользователям. Есть правда небольшой нюанс — если вы пробуете скачать образ, который уже есть, запрос все равно будет учтен, даже если вы и не будете качать слои. В любом случае мы надеемся, что такой метод ограничения частоты скачивания будет и справедливым, и удобным для пользователей.


Ждем ваши отзывы

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

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

Наконец, в рамках поддержки сообщества разработчиков ПО с открытым исходным кодом, до 1 ноября мы предоставим новые тарифные планы для открытого исходного кода. Чтобы подать заявку — надо заполнить форму тут.

Для получения дополнительной информации о последних изменениях условий обслуживания обратитесь к FAQ.

Тем, кому надо поднять ограничения на частоту скачивания образов, Docker предлагает неограниченное скачивание образов в качестве особенности планов Pro или Team. Как всегда, мы ждем обратную связь и вопросы здесь.

© Habrahabr.ru