Toto je druhý článek ze série článků, které se budou týkat omezení při stahování obrázků kontejnerů.
В jsme se blíže podívali na obrázky uložené v Docker Hub, největším registru obrázků kontejnerů. Píšeme vám proto, abychom vám lépe porozuměli tomu, jak naše aktualizované smluvní podmínky ovlivní vývojové týmy používající Docker Hub ke správě obrázků kontejnerů a kanálů CICD.
Limity frekvence stahování byly dříve oznámeny v našem . Podrobněji se podíváme na limity frekvence, které vstoupí v platnost 1. listopadu 2020:
Bezplatný plán, anonymní uživatelé: 100 stažení za 6 hodin
Plán zdarma, oprávnění uživatelé: 200 stažení za 6 hodin
Pro tarif: neomezeně
Týmový plán: neomezený
Frekvence stahování Dockeru je definována jako počet požadavků manifestu do Docker Hub. Limity frekvence stahování obrázku závisí na typu účtu, který obrázek požaduje, nikoli na typu účtu vlastníka obrázku. U anonymních (neoprávněných) uživatelů je frekvence stahování vázána na ip-adresu.
NB Získáte více jemností a případů osvědčených postupů . Navíc si to můžete projít, když se vám to hodí – časově i náladově.
Od zákazníků a komunity dostáváme dotazy týkající se vrstev obrázků kontejnerů. Při omezování frekvence stahování nebereme v úvahu vrstvy obrázků, protože omezujeme stahování manifestů a počet vrstev (požadavek objektů blob) je v současné době neomezený. Tato změna je založena na zpětné vazbě komunity, aby byla uživatelsky přívětivější, takže uživatelé nemusí počítat vrstvy u každého vzhledu, který použijí.
Podrobná analýza frekvencí stahování obrázků Docker Hub
Strávili jsme spoustu času analýzou stahování obrázků z Docker Hub, abychom zjistili důvod omezení rychlosti a také jak přesně jej omezit. To, co jsme viděli, potvrdilo, že prakticky všichni uživatelé stahují obrázky předvídatelnou rychlostí pro typické pracovní postupy. Je zde však patrný vliv malého počtu anonymních uživatelů, například asi 30 % všech stahování pochází pouze od 1 % anonymních uživatelů.
Nové limity jsou založeny na této analýze, takže většina našich uživatelů nebude ovlivněna. Tyto limity jsou vytvořeny tak, aby odrážely běžné používání vývojáři – učení se Dockeru, vývoj kódu, vytváření obrázků a tak dále.
Pomáhá vývojářům lépe porozumět limitům frekvence stahování
Nyní, když jsme pochopili dopad a také to, kde by měly být hranice, museli jsme určit technické podmínky pro fungování těchto omezení. Omezení stahování obrázků z registru Docker je poměrně obtížné. V popisu registru nenajdete API pro stahování - prostě neexistuje. Stahování obrázku je ve skutečnosti kombinací požadavků na manifest a objektů BLOB v API a jsou prováděny různě v závislosti na stavu klienta a požadovaného obrázku.
Pokud například již máte obrázek, Docker Engine vydá požadavek na manifest, pochopí, že již má všechny potřebné vrstvy založené na přijatém manifestu, a poté se zastaví. Na druhou stranu, pokud stahujete obraz, který podporuje více architektur, žádost o manifest vrátí seznam manifestů obrazu pro každou podporovanou architekturu. Docker Engine poté vydá další manifest žádost pro konkrétní architekturu, na které běží, a na oplátku dostane seznam všech vrstev v obrazu. Poté se bude dotazovat na každou chybějící vrstvu (blob).
NB Toto téma je pokryto šířeji , ve kterém rozebereme všechny jeho nástroje: od základních abstrakcí po síťové parametry, nuance práce s různými operačními systémy a programovacími jazyky. Seznámíte se s technologií a pochopíte, kde a jak nejlépe Docker používat.
Ukazuje se, že stahování obrázku je ve skutečnosti jeden nebo dva manifestové požadavky, stejně jako od nuly do nekonečna - požadavky na vrstvy (blob). Historicky Docker sledoval frekvenci stahování na základě vrstvy po vrstvě, protože to nejvíce souvisí s využitím šířky pásma. Ale přesto jsme naslouchali komunitě, což je složitější, protože je potřeba sledovat požadovaný počet vrstev, což povede k ignorování osvědčených postupů při práci s Dockerfile a také intuitivnější pro uživatele, kteří chtějí jen pracovat s registrem bez velkého pochopení detailů.
Omezujeme tedy počet požadavků na základě manifestních požadavků. To přímo souvisí se stahováním obrázků, což je pro uživatele snadno pochopitelné. Je tu opravdu malá nuance - pokud se pokusíte stáhnout obrázek, který již existuje, požadavek bude stále vzat v úvahu, i když vrstvy nestáhnete. V každém případě doufáme, že tento způsob omezení frekvence stahování bude férový a uživatelsky přívětivý.
Těšíme se na vaši zpětnou vazbu
Omezení budeme sledovat a upravovat podle běžných případů použití, abychom se ujistili, že omezení jsou vhodná pro každý typ uživatele, a zejména se budeme snažit vývojářům nikdy bránit v jejich práci.
Zůstaňte naladěni v následujících týdnech na další článek o vyladění CI a bojových systémů ve světle těchto změn.
A konečně, jako součást naší podpory pro open source komunitu, budeme až do 1. listopadu poskytovat nové cenové plány pro open source. Chcete-li se přihlásit, vyplňte formulář .
Další informace o nejnovějších změnách podmínek služby naleznete na adrese .
Pro ty, kteří potřebují zvýšit limity frekvence stahování obrázků, nabízí Docker jako funkci neomezené stahování obrázků. . Jako vždy vítáme zpětnou vazbu a dotazy. .
Zdroj: www.habr.com