company_banner

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

Автор оригинала: JEAN-LAURENT DE MORLHON
  • Перевод


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


В первой части мы подробно рассмотрели образы, хранимые в 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% анонимных пользователей.



Новые ограничения основаны на этом анализе, так что большинство наших пользователей не пострадают. Эти ограничения сделаны для отображения обычного использования разработчиками — изучения 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. Как всегда, мы ждем обратную связь и вопросы здесь.

Southbridge
Обеспечиваем стабильную работу highload-проектов

Похожие публикации

Комментарии 9

    +2

    Я считаю, что мало рекламы курсов — всего лишь два раза увидел. Надо в каждый абзац.
    Докер хабу же с таким подходом — гореть в аду. Их мотивация понятна, но уже слишком многое на них завязано, поэтому введение ограничений выглядит как шантаж пользователей. К чему это приведет? К более широкому распространению on-premise установок registry вроде Harbor, JFROG Container Registry (или Artifactory) в прокси режимах

      0
      К чему это приведет? К более широкому распространению on-premise установок registry вроде Harbor, JFROG Container Registry (или Artifactory) в прокси режимах

      Я не думаю, что владельцы Докера будут этим расстроены.

        0

        Мирантис (="новые владельцы Докера"), т.е.?

        0
        nexus еще не можно упомянуть
          0

          нет, не стоит. Так себе решение.

            0
            а есть еще какие-либо особо варианты для случая «нужен комбайн репозиториев» + opensource?
              0

              один пример — (во-первых, это не опенсурс, а скорее opencore) gitlab. Вроде бы опенсурс. А по факту — все использует его как "коробку". Никто в здравом уме не полезет в макаронный код гитлаба для его исправления (максимум — только лишь, потому что документация априори устаревает сразу как написана, а код — вот он). Поэтому нужно четко понимать зачем Вам нужен "opensource".


              Я уж не говорю о том, что в бесплатном Nexus нет HA (если надо — могу пруфы позже). А как только Вы его захотите — стоимость будет не дешевле платного же Artifactory. А какое хранилище артефактов без отказоустойчивости?

                0
                А какое хранилище артефактов без отказоустойчивости?

                гм, а простой бекап прямо совсем не подходит? Вы стараетесь примерить свое виденье/критичность данного сервиса на своей работе к другим. Давайте будем честны — настолько ли часто надо делать
                apt-get install что-то там из локального репо
                docker pull что-то из локального registry
                

                что в случае падения комбайна с репозиториями, не подождет некоторого времени, пока
                - сделаю rsync из бекапа
                - положу дамп баз в папку restore (речь про nexus)
                
                  0
                  гм, а простой бекап прямо совсем не подходит?

                  Удачи с бекапом 10Тб в нексусе (и это еще не очень много), разложенном на несколько докер регистров, потому что иначе это не работает.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое