Detta är den andra artikeln i en serie artiklar som kommer att täcka begränsningar vid nedladdning av behållarbilder.
В vi tog en närmare titt på bilderna som lagrats i Docker Hub, det största registret av containerbilder. Vi skriver detta för att hjälpa dig att bättre förstå hur våra uppdaterade användarvillkor kommer att påverka utvecklingsteam som använder Docker Hub för att hantera containerbilder och CICD-pipelines.
Gränser för nedladdningsfrekvens tillkännagavs tidigare i vår . Vi tittar närmare på frekvensgränserna som träder i kraft den 1 november 2020:
Gratis plan, anonyma användare: 100 nedladdningar på 6 timmar
Gratis plan, auktoriserade användare: 200 nedladdningar på 6 timmar
Pro-plan: obegränsat
Lagplan: obegränsat
Docker-nedladdningsfrekvens definieras som antalet manifestförfrågningar till Docker Hub. Frekvensgränserna för bildnedladdning beror på vilken typ av konto som begär bilden, inte typen av bildägares konto. För anonyma (obehöriga) användare är nedladdningsfrekvensen bunden till ip-adressen.
NB Du kommer att få fler finesser och bästa praxisfall . Dessutom kan du gå igenom det när det passar dig - både i tid och i humör.
Vi får frågor från kunder och samhället angående lager av behållare. Vi tar inte hänsyn till bildlager när vi begränsar nedladdningsfrekvensen, eftersom vi begränsar manifestnedladdningar och antalet lager (blob-förfrågningar) för närvarande är obegränsat. Denna förändring är baserad på feedback från communityn för att göra den mer användarvänlig så att användarna inte behöver räkna lager på varje look de använder.
Detaljerad analys av Docker Hub-bildnedladdningsfrekvenser
Vi ägnade mycket tid åt att analysera nedladdningen av bilder från Docker Hub för att fastställa orsaken till hastighetsbegränsningen, samt exakt hur man begränsar den. Det vi såg bekräftade att praktiskt taget alla användare laddar ner bilder i en förutsägbar hastighet för typiska arbetsflöden. Det finns dock en märkbar påverkan av ett litet antal anonyma användare, till exempel kommer cirka 30 % av alla nedladdningar från endast 1 % av anonyma användare.
De nya gränserna är baserade på denna analys, så de flesta av våra användare kommer inte att påverkas. Dessa begränsningar är gjorda för att återspegla normal användning av utvecklare - lära sig Docker, utveckla kod, bygga bilder och så vidare.
Hjälper utvecklare att bättre förstå gränser för nedladdningsfrekvens
Nu när vi förstod konsekvenserna, och även var gränserna borde gå, var vi tvungna att fastställa de tekniska förutsättningarna för att dessa restriktioner ska fungera. Att begränsa nedladdningen av bilder från Docker-registret är ganska svårt. Du hittar inget API för nedladdningar i registerbeskrivningen – det existerar helt enkelt inte. Faktum är att nedladdning av en bild är en kombination av manifestförfrågningar och blobbar i API:t, och de exekveras på olika sätt, beroende på tillståndet för klienten och den efterfrågade bilden.
Till exempel, om du redan har en bild kommer Docker Engine att utfärda en begäran om ett manifest, förstå att det redan har alla nödvändiga lager baserat på det accepterade manifestet och sedan stoppa. Å andra sidan, om du laddar ner en bild som stöder flera arkitekturer, kommer en manifestbegäran att returnera en lista med bildmanifest för varje arkitektur som stöds. Docker Engine kommer sedan att utfärda ytterligare en manifestbegäran för den specifika arkitekturen den körs på, i gengäld kommer den att få en lista över alla lager i bilden. Det kommer sedan att fråga efter varje saknat lager (blob).
NB Detta ämne täcks mer brett i , där vi kommer att analysera alla dess verktyg: från grundläggande abstraktioner till nätverksparametrar, nyanserna av att arbeta med olika operativsystem och programmeringsspråk. Du kommer att bekanta dig med tekniken och förstå var och hur du bäst använder Docker.
Det visar sig att nedladdning av en bild faktiskt är en eller två manifestförfrågningar, såväl som från noll till oändlighet - förfrågningar om lager (blob). Historiskt sett har Docker spårat nedladdningsfrekvens på lager-för-lager-basis, eftersom detta är mest relaterat till bandbreddsanvändning. Men ändå lyssnade vi på communityn, vilket är svårare, eftersom du behöver hålla reda på det begärda antalet lager, vilket kommer att leda till att man ignorerar bästa praxis när det gäller att arbeta med Dockerfilen, och även mer intuitivt för användare som vill bara arbeta med registret utan större förståelse för detaljerna.
Så vi begränsar antalet förfrågningar baserat på manifestförfrågningar. Detta är direkt relaterat till nedladdning av bilder, vilket är lätt för användare att förstå. Det finns verkligen en liten nyans - om du försöker ladda ner en bild som redan finns, kommer begäran fortfarande att beaktas, även om du inte laddar ner lagren. Vi hoppas i alla fall att denna metod för att begränsa nedladdningsfrekvensen kommer att vara både rättvis och användarvänlig.
Ser fram emot dina synpunkter
Vi kommer att övervaka begränsningarna och göra lämpliga justeringar baserat på vanliga användningsfall för att säkerställa att begränsningarna är lämpliga för varje typ av användare, och i synnerhet kommer vi att försöka aldrig hindra utvecklare från att göra sitt arbete.
Håll utkik under de kommande veckorna för ytterligare en artikel om att justera CI och stridssystem i ljuset av dessa förändringar.
Slutligen, som en del av vårt stöd för öppen källkod, kommer vi att tillhandahålla nya prisplaner för öppen källkod fram till 1 november. För att ansöka, vänligen fyll i formuläret .
För mer information om de senaste ändringarna av användarvillkoren, besök .
För dem som behöver höja gränserna för nedladdning av bilder, erbjuder Docker obegränsade nedladdningar av bilder som en funktion. . Som alltid tar vi gärna emot feedback och frågor. .
Källa: will.com