Dette er den andre artikkelen i en serie med artikler som vil dekke begrensninger ved nedlasting av containerbilder.
В vi tok en nærmere titt på bildene som er lagret i Docker Hub, det største registret for containerbilder. Vi skriver dette for å gi deg en bedre forståelse av hvordan våre oppdaterte vilkår for bruk vil påvirke utviklingsteam som bruker Docker Hub til å administrere containerbilder og CICD-pipelines.
Nedlastingsfrekvensgrenser ble tidligere annonsert i vår . Vi ser nærmere på frekvensgrensene som trer i kraft 1. november 2020:
Gratis plan, anonyme brukere: 100 nedlastinger på 6 timer
Gratis plan, autoriserte brukere: 200 nedlastinger på 6 timer
Pro-plan: ubegrenset
Teamplan: ubegrenset
Docker-nedlastingsfrekvens er definert som antall manifestforespørsler til Docker Hub. Frekvensgrenser for nedlasting av bilder avhenger av typen konto som ber om bildet, ikke typen bildeeierkonto. For anonyme (uautoriserte) brukere er nedlastingsfrekvensen knyttet til ip-adressen.
NB Du vil motta flere finesser og beste praksis-cases . Dessuten kan du gå gjennom det når det passer deg - både i tid og humør.
Vi får spørsmål fra kunder og samfunnet angående beholderbildelag. Vi tar ikke hensyn til bildelag når vi begrenser nedlastingsfrekvensen, fordi vi begrenser manifestnedlastinger, og antallet lag (blob-forespørsler) er for øyeblikket ubegrenset. Denne endringen er basert på tilbakemeldinger fra fellesskapet for å gjøre den mer brukervennlig slik at brukerne ikke trenger å telle lag på hvert utseende de bruker.
Detaljert analyse av nedlastingsfrekvenser for Docker Hub-bilder
Vi brukte mye tid på å analysere nedlastingen av bilder fra Docker Hub for å finne årsaken til fartsgrensen, samt nøyaktig hvordan vi skulle begrense den. Det vi så bekreftet at praktisk talt alle brukere laster ned bilder med en forutsigbar hastighet for typiske arbeidsflyter. Det er imidlertid en merkbar påvirkning fra et lite antall anonyme brukere, for eksempel kommer omtrent 30 % av alle nedlastinger fra kun 1 % av anonyme brukere.
De nye grensene er basert på denne analysen, så de fleste av våre brukere vil ikke bli berørt. Disse begrensningene er laget for å gjenspeile normal bruk av utviklere – lære Docker, utvikle kode, bygge bilder og så videre.
Hjelper utviklere med å bedre forstå grensene for nedlastingsfrekvens
Nå som vi forsto virkningen, og også hvor grensene skulle gå, måtte vi bestemme de tekniske betingelsene for driften av disse restriksjonene. Å begrense nedlastingen av bilder fra Docker-registeret er ganske vanskelig. Du vil ikke finne et API for nedlastinger i registerbeskrivelsen – det eksisterer bare ikke. Faktisk er nedlasting av et bilde en kombinasjon av manifestforespørsler og blobs i APIen, og de utføres forskjellig, avhengig av tilstanden til klienten og det forespurte bildet.
For eksempel, hvis du allerede har et bilde, vil Docker Engine utstede en forespørsel om et manifest, forstå at det allerede har alle nødvendige lag basert på det aksepterte manifestet, og deretter stoppe. På den annen side, hvis du laster ned et bilde som støtter flere arkitekturer, vil en manifestforespørsel returnere en liste over bildemanifester for hver støttet arkitektur. Docker Engine vil da utstede en ny manifestforespørsel for den spesielle arkitekturen den kjører på, til gjengjeld vil den få en liste over alle lagene i bildet. Den vil deretter spørre etter hvert manglende lag (blob).
NB Dette emnet dekkes mer omfattende i , der vi vil analysere alle verktøyene: fra grunnleggende abstraksjoner til nettverksparametere, nyansene ved å jobbe med ulike operativsystemer og programmeringsspråk. Du vil bli kjent med teknologien og forstå hvor og hvordan du best kan bruke Docker.
Det viser seg at nedlasting av et bilde faktisk er en eller to manifestforespørsler, så vel som fra null til uendelig - forespørsler om lag (blob). Historisk sett har Docker sporet nedlastingsfrekvens på lag-for-lag-basis, da dette er mest relatert til båndbreddebruk. Men likevel lyttet vi til fellesskapet, noe som er vanskeligere, fordi du må holde styr på det forespurte antallet lag, noe som vil føre til å ignorere beste praksis angående arbeid med Dockerfile, og også mer intuitivt for brukere som ønsker å bare arbeide med registret uten mye forståelse av detaljene.
Så vi begrenser antallet forespørsler basert på manifestforespørsler. Dette er direkte relatert til nedlasting av bilder, noe som er lett for brukere å forstå. Det er egentlig en liten nyanse - hvis du prøver å laste ned et bilde som allerede eksisterer, vil forespørselen fortsatt bli tatt i betraktning, selv om du ikke laster ned lagene. Uansett håper vi at denne metoden for å begrense nedlastingsfrekvensen vil være både rettferdig og brukervennlig.
Ser frem til tilbakemeldingen din
Vi vil overvåke restriksjonene og gjøre passende justeringer basert på vanlige brukstilfeller for å sikre at begrensningene er passende for hver type bruker, og spesielt vil vi prøve å aldri hindre utviklere i å gjøre jobben sin.
Følg med i de kommende ukene for en annen artikkel om tilpasning av CI og kampsystemer i lys av disse endringene.
Til slutt, som en del av vår støtte til åpen kildekode-fellesskapet, vil vi tilby nye prisplaner for åpen kildekode frem til 1. november. For å søke, vennligst fyll ut skjemaet .
For mer informasjon om de siste endringene i tjenestevilkårene, vennligst besøk .
For de som trenger å øke frekvensgrensene for bildenedlasting, tilbyr Docker ubegrensede bildenedlastinger som en funksjon. . Som alltid tar vi gjerne imot tilbakemeldinger og spørsmål. .
Kilde: www.habr.com