Dette er den anden artikel i en serie af artikler, hvor vi vil se nærmere på begrænsninger ved download af containerbilleder.
I Vi har detaljeret gennemgået billeder, der opbevares på Docker Hub, den største containerbillede-registrering. Vi skriver om 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.
Begrænsningerne for downloadfrekvens blev tidligere annonceret i vores . Vi vil nærmere undersøge downloadfrekvensbegrænsningerne, der træder i kraft den 1. november 2020:
Gratis plan, anonyme brugere: 100 downloads hver 6. time
Gratis plan, autoriserede brugere: 200 downloads hver 6. time
Pro-plan: ingen begrænsninger
Team-plan: ingen begrænsninger
Downloadfrekvensen fra Docker defineres som antallet af anmodninger om manifest til Docker Hub. Downloadfrekvensbegrænsningerne for billeder afhænger af typen af konto, der anmoder om billedet, snarere end typen af konto, der ejer billedet. For anonyme (uautoriserede) brugere er downloadfrekvensen knyttet til IP-adressen.
N.B. Du vil få flere detaljer og best practice cases Og du kan tage det, når det passer dig — både hvad angår tid og stemning.
Vi modtager spørgsmål fra kunder og samfundet vedrørende lagene af containerbilleder. Vi tager ikke hensyn til lagene af billedet ved begrænsning af downloadfrekvensen, fordi vi begrænser download af manifester, mens antallet af lag (blob-anmodninger) ikke er begrænset i øjeblikket. Denne ændring er baseret på tilbagemeldinger fra samfundet for at gøre det mere brugervenligt, så brugerne ikke behøver at tælle lagene på hvert billede, de bruger.
En detaljeret analyse af downloadfrekvenserne for Docker Hub-billeder.
Vi har brugt meget tid på at analysere download af billeder fra Docker Hub for at finde årsagen til hastighedsbegrænsningen, samt hvordan den bør begrænses. Det, vi har observeret, bekræftede, at stort set alle brugere downloader billeder med en forudsigelig hastighed for typiske arbejdsprocesser. Derimod er der en mærkbar indflydelse fra et lille antal anonyme brugere, eksempelvis kommer omkring 30% af alle downloads fra kun 1% af de anonyme brugere.
De nye begrænsninger er baseret på denne analyse, så de fleste af vores brugere vil ikke lide under dem. Disse begrænsninger er lavet for at afspejle den almindelige brug blandt udviklere — som at udforske Docker, udvikle kode, bygge billeder osv.
Hjælp til udviklere for bedre at forstå begrænsningen af downloadhastigheden
Nu, hvor vi har fået indsigt i indflydelsen samt hvor grænserne skal være, skulle vi definere de tekniske betingelser for, hvordan disse begrænsninger skulle fungere. At begrænse downloads af billeder fra Docker registry er ret kompliceret. Du finder ikke et API til uploads i beskrivelsen af registry — det eksisterer simpelthen ikke. Faktisk repræsenterer download af et billede en kombination af anmodninger om manifester og blobs i API'et, og disse udføres forskelligt, afhængigt af klientens tilstand og det anmodede billede.
For eksempel, hvis du allerede har et billede, vil Docker Engine sende en anmodning om manifestet, forstå at den allerede har alle nødvendige lag baseret på det accepterede manifest, hvorefter den stopper. På den anden side — hvis du downloader et billede, der understøtter flere arkitekturer, vil anmodningen om manifestet returnere en liste over billeder for hver understøttet arkitektur. Derefter vil Docker Engine sende endnu en anmodning om manifestet for den specifikke arkitektur, som den arbejder på, og i svaret modtage en liste over alle lagene i billedet. Derefter vil den anmode om hver manglende lag (blob).
N.B. Emnet er behandlet mere grundigt i , hvor vi dækker alle dets værktøjer: fra de grundlæggende abstraktioner til netværksparametre, detaljer vedrørende arbejde med forskellige operativsystemer og programmeringssprog. Du vil lære teknologien at kende og forstå, hvor og hvordan Docker bedst kan anvendes.
Det viser sig, at download af et billede i virkeligheden er en eller to anmodninger om manifestet samt fra nul til uendelig — anmodninger om lag (blob). Historisk set har Docker sporet downloadfrekvensen baseret på lag, da det er mest relateret til brug af båndbredde. Men vi har taget imod samfundets feedback, da det er sværere, fordi man skal spore det antal lag, der anmodes om, hvilket vil føre til ignorering af best practices i forhold til arbejdet med Dockerfile. Det er også intuitivt vanskeligere for brugere, der bare ønsker at arbejde med registreringen uden at dykke for meget ned i detaljerne.
Så vi begrænser antallet af anmodninger baseret på anmodninger om manifester. Dette er direkte relateret til download af billeder, hvilket er nemt for brugerne at forstå. Der er dog et lille nuance — hvis du prøver at downloade et billede, som du allerede har, vil anmodningen stadig blive talt med, selvom du ikke downloader lagene. Under alle omstændigheder håber vi, at denne metode til at begrænse downloadfrekvensen både vil være retfærdig og praktisk for brugerne.
Vi ser frem til jeres feedback
Vi vil overvåge begrænsningerne og foretage de nødvendige justeringer baseret på typiske anvendelsesmønstre for at sikre, at begrænsningerne passer til hver type bruger, og derudover vil vi forsøge at gøre alt for ikke at forstyrre udviklernes arbejde.
Hold øje med meddelelser i de kommende uger, der vil være en anden artikel om opsætning af CI og produktionssystemer i lyset af disse ændringer.
Endelig, som en del af støtten til fællesskabet af open source-udviklere, vil vi indføre nye takster for open source inden 1. november. For at ansøge skal du udfylde formularen .
For yderligere information om de seneste ændringer i servicevilkårene, kontakt .
Dem, der har brug for at hæve begrænsningerne for downloadfrekvensen af billeder, tilbyder Docker ubegribelig download af billeder som en funktion . Som altid ser vi frem til feedback og spørgsmål .
Kilde: habr.com
