Це друга стаття із серії статей, у ній будуть розглянуті обмеження при завантаженні образів контейнерів.
В ми докладно розглянули образи, що зберігаються в Docker Hub, найбільшому registry образів контейнерів. Ми пишемо про це для того, щоб ви краще розуміли, як наші оновлені Умови обслуговування вплинуть на команди розробників, які використовують Docker Hub для керування образами контейнерів та конвеєрами CICD.
Про обмеження за частотою скачування було оголошено раніше в наших . Ми докладніше розглянемо обмеження щодо частоти, які набудуть чинності з 1 листопада 2020 року:
Безкоштовний тарифний план, анонімні користувачі: 100 завантажень за 6 годин
Безкоштовний тарифний план, авторизовані користувачі: 200 скачувань за 6 годин
Тарифний план Pro: без обмежень
Тарифний план Team: без обмежень
Частота завантажень з боку Docker визначається як кількість запитів маніфестів до Docker Hub. Обмеження за частотою завантаження образів залежать від типу облікового запису, що запитує образ, а не від типу облікового запису власника образу. Для анонімних (неавторизованих) користувачів частота завантаження прив'язана до IP-адреси.
NB Більше тонкощів та best practice кейсів ви отримаєте . Причому ви можете проходити його, коли вам зручно – і за часом, і за настроєм.
Ми отримуємо питання від клієнтів та спільноти щодо шарів образів контейнерів. Ми не враховуємо шари образу при обмеженні частоти завантаження, тому що ми обмежуємо завантаження маніфестів, а кількість шарів (запитів blob) на даний момент не обмежена. Ця зміна заснована на відгуках спільноти, щоб зробити його більш дружелюбним до користувачів, так що користувачам немає потреби підрахувати шари на кожному використовуваному ними образі.
Детальний аналіз частот скачування образів Docker Hub
Ми витратили багато часу, аналізуючи скачування образів з Docker Hub, щоб визначити причину обмеження швидкості, а також як саме потрібно обмежувати. Те, що ми побачили, підтвердило, що фактично всі користувачі завантажують образи із передбачуваною швидкістю для типових робочих процесів. Однак є помітний вплив невеликої кількості анонімних користувачів, наприклад, близько 30% всіх завантажень виходять лише від 1% анонімних користувачів.
Нові обмеження ґрунтуються на цьому аналізі, тому більшість наших користувачів не постраждають. Ці обмеження зроблені для відображення звичайного використання розробниками - вивчення Docker, код, створення образів і т.п.
Допомога розробникам для кращого розуміння обмеження частоти завантаження
Зараз, коли нам став зрозумілим вплив, а також де мають бути межі, нам треба було визначити технічні умови роботи цих обмежень. Обмежувати завантаження образів з Docker registry досить складно. Ви не знайдете API для завантажень в описі registry - його просто не існує. За фактом завантаження образу є комбінацією запитів маніфесту і blobs в API, а вони виконуються по-різному, залежно від стану клієнта і образа, що запитується.
Наприклад, якщо у вас вже є образ, Docker Engine видасть запит на маніфест, зрозуміє, що він вже має всі необхідні шари на основі прийнятого маніфесту, після чого зупиниться. З іншого боку — якщо ви завантажуєте образ, який підтримує кілька архітектур, запит на маніфест поверне список маніфестів образів для кожної архітектури, що підтримується. Потім Docker Engine видасть ще один запит на маніфест щодо конкретної архітектури, на якій він працює, у відповідь отримає список усіх верств образу. Потім він буде вимагати кожен відсутній шар (blob).
NB Більше широко ця тема розкрита на У якому ми розберемо всі його інструменти: від основних абстракцій до параметрів мережі, нюансів роботи з різними ОС та мовами програмування. Ви познайомитеся з технологією та зрозумієте, де і як краще використовувати Docker.
Виходить, що скачування образу це насправді один або два запити маніфесту, а також від нуля до нескінченності - запити шарів (blob). Історично Docker відстежував частоту скачування на основі шарів, оскільки це найбільше пов'язано з використанням смуги пропускання. Проте, ми прислухалися до спільноти, що так складніше, адже потрібно відстежувати кількість шарів, що запитується, що призведе до ігнорування best practices щодо роботи з Dockerfile, а також інтуїтивно незрозуміліше для користувачів, які бажають просто працювати з registry, не сильно розбираючись в деталях .
Отже, ми обмежуємо кількість запитів на основі запитів на маніфести. Це безпосередньо пов'язане зі скачуванням образів, що легко зрозуміти користувачам. Є правда невеликий нюанс — якщо ви намагаєтеся завантажити образ, який вже є, запит все одно буде враховано, навіть якщо ви й не качатимете шари. У будь-якому випадку ми сподіваємося, що такий метод обмеження частоти скачування буде справедливим і зручним для користувачів.
Чекаємо на ваші відгуки
Ми будемо стежити за обмеженнями та вносити відповідні редагування на основі типових варіантів використання, щоб бути впевненими, що обмеження підходять кожному типу користувачів, а також, зокрема, ми постараємося ніколи не заважати розробникам виконати їхню роботу.
Слідкуйте за повідомленнями в найближчі тижні, буде ще одна стаття про налаштування CI та бойових систем у світлі цих змін.
Нарешті, в рамках підтримки спільноти розробників програмного забезпечення з відкритим вихідним кодом, до 1 листопада ми надамо нові тарифні плани для відкритого вихідного коду. Щоб подати заявку – треба заповнити форму .
Для отримання додаткової інформації про останні зміни умов обслуговування зверніться до .
Тим, кому треба підняти обмеження на частоту скачування образів, Docker пропонує необмежену скачування образів як особливість . Як завжди, ми чекаємо зворотний зв'язок та питання .
Джерело: habr.com