Ĉi tiu estas la dua artikolo en serio de artikoloj, kiuj kovros limigojn dum elŝutado de ujbildoj.
В ni rigardis pli detale la bildojn konservitajn en Docker Hub, la plej granda registro de ujbildoj. Ni skribas ĉi tion por doni al vi pli bonan komprenon pri kiel niaj ĝisdatigitaj Servokondiĉoj efikos al evoluteamoj uzante Docker Hub por administri ujajn bildojn kaj CICD-duktojn.
Elŝutaj frekvencaj limoj antaŭe estis anoncitaj en nia . Ni rigardu pli detale la frekvenclimojn, kiuj ekvalidos la 1-an de novembro 2020:
Senpaga plano, anonimaj uzantoj: 100 elŝutoj en 6 horoj
Senpaga plano, rajtigitaj uzantoj: 200 elŝutoj en 6 horoj
Profesia plano: senlima
Teama plano: senlima
Docker-elŝutofteco estas difinita kiel la nombro da manifestaj petoj al Docker Hub. Bildaj frekvenclimoj dependas de la speco de konto, kiu petas la bildon, ne de la speco de bilda posedanto-konto. Por anonimaj (neaŭtorizitaj) uzantoj, la elŝuta ofteco estas ligita al la ip-adreso.
NB Vi ricevos pli da subtilecoj kaj plej bonaj praktikaj kazoj . Krome, vi povas trairi ĝin kiam ĝi estas oportuna por vi - kaj en tempo kaj en humoro.
Ni ricevas demandojn de klientoj kaj la komunumo pri ujbildaj tavoloj. Ni ne konsideras bildtavolojn kiam limigas elŝutfrekvencon, ĉar ni limigas manifestajn elŝutojn, kaj la nombro da tavoloj (blobpetoj) estas nuntempe senlima. Ĉi tiu ŝanĝo baziĝas sur komunumaj sugestoj por igi ĝin pli uzebla por ke uzantoj ne devas kalkuli tavolojn laŭ ĉiu aspekto, kiun ili uzas.
Detala analizo de la frekvencoj de elŝuto de bildoj de Docker Hub
Ni pasigis multan tempon analizante la elŝuton de bildoj de Docker Hub por determini la kialon de la rapidlimo, kaj ankaŭ precize kiel limigi ĝin. Kion ni vidis konfirmis, ke preskaŭ ĉiuj uzantoj elŝutas bildojn je antaŭvidebla rapideco por tipaj laborfluoj. Tamen, estas rimarkinda influo de malgranda nombro da anonimaj uzantoj, ekzemple, ĉirkaŭ 30% de ĉiuj elŝutoj venas de nur 1% de anonimaj uzantoj.
La novaj limoj baziĝas sur ĉi tiu analizo, do plej multaj el niaj uzantoj ne estos tuŝitaj. Ĉi tiuj limoj estas faritaj por reflekti normalan uzadon de programistoj - lernado de Docker, disvolvado de kodo, konstruado de bildoj ktp.
Helpante programistojn pli bone kompreni elŝutajn frekvenclimojn
Nun kiam ni komprenis la efikon, kaj ankaŭ kie la limoj devus esti, ni devis determini la teknikajn kondiĉojn por la funkciado de ĉi tiuj limigoj. Limigi la elŝuton de bildoj de la Docker-registro estas sufiĉe malfacila. Vi ne trovos API por elŝutoj en la registra priskribo - ĝi simple ne ekzistas. Fakte, elŝuti bildon estas kombinaĵo de manifestpetoj kaj blobs en la API, kaj ili estas ekzekutitaj malsame, depende de la stato de la kliento kaj la petita bildo.
Ekzemple, se vi jam havas bildon, Docker Engine elsendos peton por manifesto, komprenos, ke ĝi jam havas ĉiujn necesajn tavolojn bazitajn sur la akceptita manifesto, kaj poste ĉesos. Aliflanke, se vi elŝutas bildon, kiu subtenas plurajn arkitekturojn, manifestpeto resendos liston de bildmanifestoj por ĉiu subtenata arkitekturo. La Docker Engine tiam eligos alian manifestan peton por la aparta arkitekturo, sur kiu ĝi funkcias, ĝi ricevos liston de ĉiuj tavoloj en la bildo. Ĝi tiam demandos por ĉiu mankanta tavolo (blobo).
NB Ĉi tiu temo estas traktata pli vaste en , en kiu ni analizos ĉiujn ĝiajn ilojn: de bazaj abstraktaĵoj ĝis retaj parametroj, la nuancoj labori kun diversaj operaciumoj kaj programlingvoj. Vi konatiĝos kun la teknologio kaj komprenos kie kaj kiel plej bone uzi Docker.
Montriĝas, ke elŝuti bildon fakte estas unu aŭ du manifestaj petoj, same kiel de nulo ĝis senfine - petoj por tavoloj (blob). Historie, Docker spuris elŝutofrekvencon laŭ tavolo-post-tavola bazo, ĉar tio plej rilatas al bendolarĝa uzado. Sed tamen ni aŭskultis la komunumon, kio estas pli malfacila, ĉar vi devas konservi trakon de la petita nombro da tavoloj, kio kondukos al ignori plej bonajn praktikojn pri laboro kun la Dockerfile, kaj ankaŭ pli intuicia por uzantoj kiuj volas nur labori kun la registro sen multe da kompreno de la detaloj.
Do ni limigas la nombron da petoj surbaze de manifestaj petoj. Ĉi tio rekte rilatas al elŝutado de bildoj, kio estas facile komprenebla por uzantoj. Estas vere malgranda nuanco - se vi provas elŝuti bildon kiu jam ekzistas, la peto ankoraŭ estos konsiderata, eĉ se vi ne elŝutas la tavolojn. Ĉiukaze, ni esperas, ke ĉi tiu metodo de limigado de la ofteco de elŝutoj estos kaj justa kaj uzebla.
Atendas viajn komentojn
Ni kontrolos la limigojn kaj faros taŭgajn ĝustigojn bazitajn sur oftaj uzkazoj por certigi, ke la limigoj taŭgas por ĉiu tipo de uzanto, kaj precipe, ni provos neniam malhelpi programistojn fari sian laboron.
Restu agordita en la venontaj semajnoj por alia artikolo pri ĝustigo de CI kaj batalsistemoj laŭ ĉi tiuj ŝanĝoj.
Fine, kiel parto de nia subteno por la malfermkoda komunumo, ni disponigos novajn prezajn planojn por malfermfonteco ĝis la 1-a de novembro. Por kandidatiĝi, bonvolu plenigi la formularon .
Por pliaj informoj pri la plej novaj ŝanĝoj al la servokondiĉoj, bonvolu viziti .
Por tiuj, kiuj bezonas altigi siajn bildajn elŝutajn frekvenclimojn, Docker ofertas senlimajn bildajn elŝutojn kiel funkcion. . Kiel ĉiam, ni bonvenigas komentojn kaj demandojn. .
fonto: www.habr.com