To je drugi članek v nizu člankov, ki bodo obravnavali omejitve pri prenosu slik vsebnika.
В smo si podrobneje ogledali slike, shranjene v Docker Hubu, največjem registru slik vsebnikov. To pišemo, da bi vam pomagali bolje razumeti, kako bodo naši posodobljeni pogoji storitve vplivali na razvojne skupine, ki uporabljajo Docker Hub za upravljanje slik vsebnikov in cevovodov CICD.
Omejitve pogostosti prenosov so bile predhodno objavljene v našem . Podrobneje si oglejmo frekvenčne omejitve, ki bodo začele veljati 1. novembra 2020:
Brezplačen paket, anonimni uporabniki: 100 prenosov v 6 urah
Brezplačen paket, pooblaščeni uporabniki: 200 prenosov v 6 urah
Pro načrt: neomejeno
Ekipni načrt: neomejeno
Pogostost prenosa Dockerja je opredeljena kot število zahtev manifesta za Docker Hub. Omejitve pogostosti prenosa slike so odvisne od vrste računa, ki zahteva sliko, ne od vrste računa lastnika slike. Pri anonimnih (nepooblaščenih) uporabnikih je pogostost prenosa vezana na ip-naslov.
Opomba: Prejeli boste več podrobnosti in primere najboljše prakse . Poleg tega lahko greste skozi to, ko vam ustreza - tako po času kot po razpoloženju.
Prejemamo vprašanja od strank in skupnosti v zvezi s slikovnimi plastmi vsebnika. Pri omejevanju pogostosti prenosov ne upoštevamo slojev slike, ker omejujemo prenose manifesta, število slojev (zahtev blob) pa je trenutno neomejeno. Ta sprememba temelji na povratnih informacijah skupnosti, da bi bila uporabniku prijaznejša, tako da uporabnikom ni treba šteti plasti pri vsakem videzu, ki ga uporabijo.
Podrobna analiza frekvenc prenosa slik Docker Hub
Veliko časa smo porabili za analizo prenosa slik iz Docker Huba, da bi ugotovili razlog za omejitev hitrosti, pa tudi, kako natančno jo omejiti. Kar smo videli, je potrdilo, da skoraj vsi uporabniki prenašajo slike s predvidljivo hitrostjo za tipične poteke dela. Opazen pa je vpliv majhnega števila anonimnih uporabnikov, na primer približno 30 % vseh prenosov prihaja od le 1 % anonimnih uporabnikov.
Nove omejitve temeljijo na tej analizi, tako da večina naših uporabnikov ne bo prizadeta. Te omejitve so narejene tako, da odražajo običajno uporabo s strani razvijalcev – učenje Dockerja, razvijanje kode, izdelava slik itd.
Pomaga razvijalcem pri boljšem razumevanju omejitev pogostosti prenosov
Zdaj, ko smo razumeli vpliv in tudi, kje naj bodo meje, smo morali določiti tehnične pogoje za delovanje teh omejitev. Omejitev prenosa slik iz registra Docker je precej težavna. V opisu registra ne boste našli API-ja za prenose – preprosto ne obstaja. Pravzaprav je prenos slike kombinacija manifestnih zahtev in blobov v API-ju, ki se izvajajo različno, odvisno od stanja stranko in zahtevano sliko.
Na primer, če že imate sliko, bo Docker Engine izdal zahtevo za manifest, ugotovil, da že ima vse potrebne plasti na podlagi sprejetega manifesta, in se nato ustavil. Po drugi strani pa, če prenašate sliko, ki podpira več arhitektur, bo zahteva manifesta vrnila seznam slikovnih manifestov za vsako podprto arhitekturo. Docker Engine bo nato izdal še eno manifestno zahtevo glede določene arhitekture, na kateri se izvaja, in v zameno prejel seznam vseh plasti na sliki. Nato bo izvedel poizvedbo za vsako manjkajočo plast (blob).
Opomba: Ta tema je širše obravnavana v , v katerem bomo analizirali vsa njegova orodja: od osnovnih abstrakcij do omrežnih parametrov, nianse dela z različnimi operacijskimi sistemi in programskimi jeziki. Spoznali boste tehnologijo in razumeli, kje in kako najbolje uporabiti Docker.
Izkazalo se je, da je prenos slike pravzaprav ena ali dve manifestni zahtevi, pa tudi od nič do neskončnosti - zahteve za plasti (blob). V preteklosti je Docker spremljal pogostost prenosov po slojih, saj je to najbolj povezano z uporabo pasovne širine. Vendar smo kljub temu prisluhnili skupnosti, kar je težje, ker morate slediti zahtevanemu številu slojev, kar bo vodilo v ignoriranje najboljših praks glede dela z datoteko Dockerfile, in tudi bolj intuitivno za uporabnike, ki želijo samo delo z registrom brez veliko razumevanja podrobnosti.
Zato omejimo število zahtev na podlagi manifestnih zahtev. To je neposredno povezano s prenosom slik, kar uporabniki zlahka razumejo. Res je majhen odtenek - če poskušate prenesti sliko, ki že obstaja, bo zahteva še vedno upoštevana, tudi če ne prenesete plasti. Vsekakor pa upamo, da bo ta način omejevanja pogostosti prenosov pošten in uporabniku prijazen.
Veselimo se vaših povratnih informacij
Spremljali bomo omejitve in naredili ustrezne prilagoditve na podlagi običajnih primerov uporabe, da bi zagotovili, da so omejitve primerne za vsako vrsto uporabnika, še posebej pa se bomo trudili, da razvijalcem nikoli ne preprečimo opravljanja njihovega dela.
Ostanite z nami v prihodnjih tednih za nov članek o prilagajanju CI in bojnih sistemov v luči teh sprememb.
Nazadnje, kot del naše podpore za odprtokodno skupnost, bomo do 1. novembra zagotavljali nove cenovne načrte za odprto kodo. Za prijavo izpolnite obrazec .
Za več informacij o zadnjih spremembah pogojev storitve obiščite .
Za tiste, ki morajo povečati svoje omejitve pogostosti prenosa slik, Docker ponuja neomejeno število prenosov slik kot funkcijo. . Kot vedno smo veseli povratnih informacij in vprašanj. .
Vir: www.habr.com