Kaip „Docker Business“ gali aptarnauti milijonus kūrėjų, 2 dalis: siunčiami duomenys

Kaip „Docker Business“ gali aptarnauti milijonus kūrėjų, 2 dalis: siunčiami duomenys

Tai antras straipsnis iš straipsnių serijos, kurioje bus nurodyti apribojimai atsisiunčiant sudėtinio rodinio vaizdus.

В pirmoji dalis atidžiau pažvelgėme į vaizdus, ​​saugomus Docker Hub – didžiausiame konteinerių vaizdų registre. Rašome tai norėdami padėti jums geriau suprasti, kaip atnaujintos paslaugų teikimo sąlygos paveiks kūrimo komandas, naudojančias „Docker Hub“ konteinerių vaizdams ir CICD vamzdynams tvarkyti.

Atsisiuntimo dažnio apribojimai buvo anksčiau paskelbti mūsų Paslaugų teikimo sąlygos. Atidžiau pažvelgsime į dažnių limitus, kurie įsigalios nuo 1 m. lapkričio 2020 d.:

Nemokamas planas, anoniminiai vartotojai: 100 atsisiuntimų per 6 valandas
Nemokamas planas, įgalioti vartotojai: 200 atsisiuntimų per 6 valandas
Pro planas: neribotas
Komandos planas: neribotas

„Docker“ atsisiuntimo dažnis apibrėžiamas kaip „Docker Hub“ manifestų užklausų skaičius. Vaizdo atsisiuntimo dažnumo apribojimai priklauso nuo paskyros, kuri prašo vaizdo, tipo, o ne nuo vaizdo savininko paskyros tipo. Anoniminiams (neteisėtiems) vartotojams atsisiuntimo dažnis yra susietas su IP adresu.

NB Gausite daugiau subtilybių ir geriausios praktikos pavyzdžių Docker kurse iš praktikų. Be to, galite pereiti jį tada, kai jums patogu – tiek laiko, tiek nuotaikos metu.

Sulaukiame klientų ir bendruomenės klausimų dėl sudėtinio rodinio vaizdo sluoksnių. Apribodami atsisiuntimo dažnį neatsižvelgiame į vaizdo sluoksnius, nes ribojame manifestų atsisiuntimus, o sluoksnių (blob užklausų) skaičius šiuo metu yra neribotas. Šis pakeitimas pagrįstas bendruomenės atsiliepimais, kad būtų patogesnis vartotojui, kad naudotojams nereikėtų skaičiuoti sluoksnių kiekvienai jų naudojamai išvaizdai.

Išsami Docker Hub vaizdo atsisiuntimo dažnių analizė

Mes praleidome daug laiko analizuodami vaizdų atsisiuntimą iš „Docker Hub“, kad nustatytų greičio apribojimo priežastį ir kaip tiksliai jį apriboti. Tai, ką matėme, patvirtino, kad beveik visi vartotojai įprastoms darbo eigoms vaizdus atsisiunčia nuspėjamu greičiu. Tačiau pastebima nedidelė anoniminių vartotojų įtaka, pavyzdžiui, apie 30% visų atsisiuntimų gaunama tik iš 1% anoniminių vartotojų.

Kaip „Docker Business“ gali aptarnauti milijonus kūrėjų, 2 dalis: siunčiami duomenys

Nauji apribojimai pagrįsti šia analize, todėl daugumai mūsų naudotojų tai nebus paveikta. Šie apribojimai nustatyti taip, kad atspindėtų įprastą kūrėjų naudojimą – mokantis „Docker“, kurti kodą, kurti vaizdus ir pan.

Padėti kūrėjams geriau suprasti atsisiuntimo dažnio ribas

Dabar, kai suprantame poveikį ir kur turėtų būti ribos, turėjome nustatyti technines šių apribojimų veikimo sąlygas. Apriboti vaizdų atsisiuntimą iš „Docker“ registro yra gana sunku. Registro apraše nerasite atsisiuntimų API – jos tiesiog nėra. Tiesą sakant, vaizdo atsisiuntimas yra API užklausų ir dėmių derinys, ir jie vykdomi skirtingai, priklausomai nuo būsenos. klientas ir prašomas vaizdas.

Pavyzdžiui, jei jau turite vaizdą, „Docker Engine“ pateiks manifesto užklausą, supras, kad jame jau yra visi reikalingi sluoksniai, remiantis priimtu manifestu, ir tada sustos. Kita vertus, jei atsisiunčiate vaizdą, kuris palaiko kelias architektūras, manifesto užklausa pateiks kiekvienos palaikomos architektūros vaizdo aprašų sąrašą. Tada „Docker Engine“ pateiks kitą konkrečios architektūros, kurioje veikia, akivaizdžią užklausą, mainais ji gaus visų vaizdo sluoksnių sąrašą. Tada bus pateikta užklausa dėl kiekvieno trūkstamo sluoksnio (blob).

NB Ši tema nagrinėjama plačiau Dokerių kursas, kuriame išanalizuosime visus jo įrankius: nuo pagrindinių abstrakcijų iki tinklo parametrų, darbo su įvairiomis operacinėmis sistemomis ir programavimo kalbomis niuansų. Susipažinsite su technologija ir suprasite, kur ir kaip geriausia naudoti Docker.

Pasirodo, kad vaizdo atsisiuntimas iš tikrųjų yra viena ar dvi manifesto užklausos, taip pat nuo nulio iki begalybės – sluoksnių (blob) užklausos. Istoriškai „Docker“ stebėjo atsisiuntimo dažnį kiekvienam sluoksniui, nes tai labiausiai susiję su pralaidumo naudojimu. Tačiau vis dėlto įsiklausėme į bendruomenę, o tai yra sunkiau, nes reikia sekti pageidaujamą sluoksnių skaičių, todėl bus nepaisoma geriausios praktikos dirbant su Dockerfile, be to, tai bus intuityvesnis vartotojams, norintiems dirbti su registru daug nesuprasdamas smulkmenų.

Taigi ribojame užklausų skaičių pagal manifesto užklausas. Tai tiesiogiai susiję su vaizdų atsisiuntimu, kurį vartotojams lengva suprasti. Tikrai yra nedidelis niuansas – jei bandysite atsisiųsti jau egzistuojantį vaizdą, į prašymą vis tiek bus atsižvelgta, net jei sluoksnių neatsisiųsite. Bet kuriuo atveju tikimės, kad šis atsisiuntimų dažnio ribojimo būdas bus teisingas ir patogus.

Lauksime jūsų atsiliepimų

Stebėsime apribojimus ir atliksime atitinkamus koregavimus, atsižvelgdami į įprastus naudojimo atvejus, siekdami užtikrinti, kad apribojimai būtų tinkami kiekvienam naudotojo tipui, o ypač stengsimės, kad kūrėjai niekada netrukdytų atlikti savo darbo.

Artimiausiomis savaitėmis laukite kito straipsnio apie CI ir kovos sistemų koregavimą atsižvelgiant į šiuos pokyčius.

Galiausiai, remdami atvirojo kodo bendruomenę, iki lapkričio 1 d. pateiksime naujus atvirojo kodo kainodaros planus. Norėdami kreiptis, užpildykite formą čia.

Norėdami gauti daugiau informacijos apie naujausius paslaugų teikimo sąlygų pakeitimus, apsilankykite Dažnai užduodami klausimai.

Tiems, kuriems reikia padidinti vaizdų atsisiuntimo dažnio ribas, „Docker“ siūlo neribotą vaizdų atsisiuntimą kaip funkciją. Pro arba komandos planai. Kaip visada laukiame atsiliepimų ir klausimų. čia.

Šaltinis: www.habr.com

Добавить комментарий