Dette er den anden artikel i en serie af artikler, der vil dække begrænsninger ved download af containerbilleder.
В vi kiggede nærmere på billederne gemt i Docker Hub, det største register af containerbilleder. Vi skriver dette for at give dig en bedre forståelse af, hvordan vores opdaterede servicevilkår vil påvirke udviklingsteams, der bruger Docker Hub til at administrere containerbilleder og CICD-pipelines.
Grænser for downloadfrekvens blev tidligere annonceret i vores . Vi ser nærmere på de frekvensgrænser, der træder i kraft den 1. november 2020:
Gratis plan, anonyme brugere: 100 downloads på 6 timer
Gratis plan, autoriserede brugere: 200 downloads på 6 timer
Pro-plan: ubegrænset
Teamplan: ubegrænset
Docker-downloadfrekvens er defineret som antallet af manifestanmodninger til Docker Hub. Frekvensgrænser for billeddownload afhænger af typen af konto, der anmoder om billedet, ikke typen af billedejerkonto. For anonyme (uautoriserede) brugere er downloadfrekvensen bundet til ip-adressen.
NB Du vil modtage flere finesser og best practice cases . Desuden kan du gennemgå det, når det passer dig - både i tid og i humør.
Vi får spørgsmål fra kunder og fællesskabet vedrørende containerbilledlag. Vi tager ikke billedlag i betragtning, når vi begrænser downloadfrekvensen, fordi vi begrænser manifest-downloads, og antallet af lag (blob-anmodninger) er i øjeblikket ubegrænset. Denne ændring er baseret på community-feedback for at gøre den mere brugervenlig, så brugerne ikke behøver at tælle lag på hvert look, de bruger.
Detaljeret analyse af Docker Hub-billedoverførselsfrekvenser
Vi brugte meget tid på at analysere download af billeder fra Docker Hub for at bestemme årsagen til hastighedsgrænsen, samt præcis hvordan man begrænser den. Det, vi så, bekræftede, at stort set alle brugere downloader billeder med en forudsigelig hastighed for typiske arbejdsgange. Der er dog en mærkbar indflydelse fra et lille antal anonyme brugere, for eksempel kommer omkring 30 % af alle downloads fra kun 1 % af anonyme brugere.
De nye grænser er baseret på denne analyse, så de fleste af vores brugere vil ikke blive berørt. Disse begrænsninger er lavet for at afspejle normal brug af udviklere - at lære Docker, udvikle kode, bygge billeder og så videre.
Hjælper udviklere med bedre at forstå downloadfrekvensgrænser
Nu hvor vi forstod virkningen, og også hvor grænserne skulle være, var vi nødt til at bestemme de tekniske betingelser for driften af disse restriktioner. Det er ret svært at begrænse download af billeder fra Docker-registret. Du finder ikke en API til downloads i registreringsdatabasen - den eksisterer bare ikke. Faktisk er download af et billede en kombination af manifestanmodninger og blobs i API'et, og de udføres forskelligt afhængigt af tilstanden af klienten og det ønskede billede.
For eksempel, hvis du allerede har et billede, vil Docker Engine udstede en anmodning om et manifest, forstå, at det allerede har alle de nødvendige lag baseret på det accepterede manifest, og derefter stoppe. På den anden side, hvis du downloader et billede, der understøtter flere arkitekturer, vil en manifestanmodning returnere en liste over billedmanifester for hver understøttet arkitektur. Docker Engine vil derefter udsende endnu en manifest anmodning for den særlige arkitektur, den kører på, til gengæld vil den få en liste over alle lag i billedet. Det vil derefter forespørge efter hvert manglende lag (blob).
NB Dette emne er dækket mere bredt i , hvor vi vil analysere alle dets værktøjer: fra grundlæggende abstraktioner til netværksparametre, nuancerne ved at arbejde med forskellige operativsystemer og programmeringssprog. Du vil stifte bekendtskab med teknologien og forstå, hvor og hvordan du bedst bruger Docker.
Det viser sig, at download af et billede faktisk er en eller to manifestanmodninger, såvel som fra nul til uendelig - anmodninger om lag (blob). Historisk har Docker sporet downloadfrekvens på lag-for-lag-basis, da dette er mest relateret til båndbreddeforbrug. Men ikke desto mindre lyttede vi til fællesskabet, hvilket er vanskeligere, fordi du skal holde styr på det ønskede antal lag, hvilket vil føre til ignorering af bedste praksis vedrørende arbejde med Dockerfilen, og også mere intuitivt for brugere, der bare vil arbejde med registreringsdatabasen uden megen forståelse af detaljerne.
Så vi begrænser antallet af anmodninger baseret på manifest-anmodninger. Dette er direkte relateret til at downloade billeder, hvilket er nemt for brugerne at forstå. Der er virkelig en lille nuance - hvis du forsøger at downloade et billede, der allerede eksisterer, vil anmodningen stadig blive taget i betragtning, selvom du ikke downloader lagene. Under alle omstændigheder håber vi, at denne metode til at begrænse frekvensen af downloads vil være både fair og brugervenlig.
Ser frem til din feedback
Vi vil overvåge begrænsningerne og foretage passende justeringer baseret på almindelige brugstilfælde for at sikre, at begrænsningerne er passende for hver type bruger, og i særdeleshed vil vi forsøge aldrig at forhindre udviklere i at udføre deres arbejde.
Følg med i de kommende uger for endnu en artikel om justering af CI og kampsystemer i lyset af disse ændringer.
Endelig, som en del af vores støtte til open source-fællesskabet, vil vi levere nye prisplaner for open source indtil den 1. november. For at ansøge skal du udfylde formularen .
For mere information om de seneste ændringer af servicevilkårene, besøg venligst .
For dem, der har brug for at hæve deres frekvensgrænser for download af billeder, tilbyder Docker ubegrænsede billeddownloads som en funktion. . Som altid modtager vi gerne feedback og spørgsmål. .
Kilde: www.habr.com