Toto je druhý článek ze série článků, který se zaměřuje na omezení při stahování obrazů kontejnerů.
V Podrobně jsme prozkoumali obrazy uložené na Docker Hub, největším registru obrazů kontejnerů. Píšeme o tom, abyste lépe chápali, jak naše aktualizované Podmínky služeb ovlivní vývojářské týmy, které používají Docker Hub k správě obrazů kontejnerů a CICD pipeline.
O omezení frekvence stahování jsme již dříve informovali v našich . Podrobněji se zaměříme na omezení frekvence, která nabydou účinnosti 1. listopadu 2020:
Bezplatný tarif, anonymní uživatelé: 100 stažení za 6 hodin
Bezplatný tarif, autorizovaní uživatelé: 200 stažení za 6 hodin
Pro tarif: bez omezení
Týmový tarif: bez omezení
Frekvence stahování ze strany Dockeru je definována jako počet požadavků na manifesty na Docker Hub. Omezení frekvence stahování obrazů závisí na typu účtu, který požaduje obraz, nikoli na typu účtu vlastníka obrazu. Pro anonymní (neautorizované) uživatele je frekvence stahování vázána na IP adresu.
N.B. Více podrobností a best practice případů získáte . Můžete ho absolvovat, kdykoli se vám to hodí — co se týče času i nálady.
Dostáváme otázky od zákazníků a komunity ohledně vrstev obrazů kontejnerů. Při omezování frekvence stahování nezohledňujeme vrstvy obrazu, protože omezujeme stahování manifestů, přičemž počet vrstev (požadavků blob) v současnosti není omezen. Toto změna je založena na zpětné vazbě komunity s cílem učinit ji uživatelsky přívětivější, takže uživatelé nemusí počítat vrstvy pro každý obraz, který používají.
Podrobná analýza frekvencí stahování obrazů Docker Hub
Strávili jsme spoustu času analýzou stahování obrazů z Docker Hub, abychom určili příčinu omezení rychlosti a také jak přesně omezovat. To, co jsme viděli, potvrdilo, že většina uživatelů stahuje obrazy s předvídatelnou rychlostí pro typické pracovní toky. Nicméně má znatelný vliv malé množství anonymních uživatelů, například přibližně 30 % všech stahování pochází pouze od 1 % anonymních uživatelů.
Nová omezení jsou založena na této analýze, takže většina našich uživatelů nebude postižena. Tato omezení byla navržena tak, aby odrážela běžné používání vývojáři — zkoumání Dockeru, vývoj kódu, vytváření obrazů atd.
Pomoc vývojářům pro lepší pochopení omezení frekvence stahování
Nyní, když jsme pochopili vliv a kde by měly být hranice, museli jsme určit technické podmínky pro fungování těchto omezení. Omezování stahování obrazů z Docker registry je dost složité. Nenajdete API pro nahrávání v popisu registry — prostě neexistuje. Ve skutečnosti stahování obrazu představuje kombinaci požadavků na manifest a blob v API, které se provádějí různě v závislosti na stavu klienta a požadovaném obrazu.
Například pokud již máte obraz, Docker Engine vydá požadavek na manifest, zjistí, že již má všechny potřebné vrstvy na základě přijatého manifestu, po čemž se zastaví. Na druhou stranu — pokud stahujete obraz podporující více architektur, požadavek na manifest vrátí seznam manifestů obrazů pro každou podporovanou architekturu. Poté Docker Engine vydá další požadavek na manifest týkající se konkrétní architektury, na které pracuje, a v odpovědi obdrží seznam všech vrstev obrazu. Následně bude požadovat každou chybějící vrstvu (blob).
N.B. Tato téma je podrobněji rozebrána na , ve kterém prozkoumáme všechny jeho nástroje: od základních abstrakcí po parametry sítě, 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 používat Docker.
Zdá se, že stahování obrazu je ve skutečnosti jeden nebo dva požadavky na manifest, a také od nuly až po nekonečno — požadavky na vrstvy (blob). Historicky Docker sledoval frekvenci stahování na základě vrstev, protože to nejvíce souvisí s využitím šířky pásma. Nicméně jsme naslouchali komunitě, že je to složitější, protože je třeba sledovat požadované množství vrstev, což povede k ignorování nejlepších praktik týkajících se práce s Dockerfile, a také to bude intuitivně méně jasné pro uživatele, kteří chtějí prostě pracovat s registry, aniž by se příliš zabývali detaily.
Proto omezujeme počet požadavků na základě požadavků na manifesty. To je přímo spojeno se stahováním obrazů, což uživatelé snadno pochopí. Opravu je tu jeden malý detail — pokud se pokusíte stáhnout obraz, který už máte, požadavek bude i tak zaznamenán, i když nebudete stahovat vrstvy. V každém případě doufáme, že tento způsob omezení frekvence stahování bude spravedlivý a pohodlný pro uživatele.
Těšíme se na vaše názory
Budeme sledovat omezení a provádět příslušné úpravy na základě běžných případů použití, abychom si byli jisti, že omezení vyhovují každému typu uživatelů, a konkrétně se budeme snažit nikdy neomezovat vývojáře ve vykonávání jejich práce.
Sledujte naše zprávy v následujících týdnech, bude tu další článek o nastavení CI a produkčních systémů v souvislosti s těmito změnami.
Nakonec, v rámci podpory komunity vývojářů s otevřeným zdrojovým kódem, do 1. listopadu poskytneme nové tarifní plány pro otevřený zdroj. Pro podání žádosti je nutné vyplnit formulář. .
Pro získání dalších informací o posledních změnách podmínek poskytování služeb se obraťte na .
Ti, kdo potřebují zvýšit omezení na frekvenci stahování obrazů, Docker nabízí neomezené stahování obrazů jako funkci . Jako vždy, těšíme se na zpětnou vazbu a otázky. .
Zdroj: habr.com
