Dit is het tweede artikel in een serie artikelen, waarin de beperkingen bij het downloaden van containerimages worden besproken.
In We hebben de images die zijn opgeslagen in Docker Hub, de grootste registry voor containerimages, uitgebreid besproken. We schrijven hierover zodat u beter begrijpt hoe onze bijgewerkte Servicevoorwaarden invloed zullen hebben op ontwikkelteams die Docker Hub gebruiken voor het beheren van containerimages en CI/CD-pijplijnen.
Over de beperkingen van de downloadfrequentie is eerder aangekondigd in onze . We bespreken de downloadfrequentiebeperkingen die ingaan op 1 november 2020:
Gratis abonnement, anonieme gebruikers: 100 downloads per 6 uur
Gratis abonnement, geregistreerde gebruikers: 200 downloads per 6 uur
Pro-abonnement: onbeperkt
Team-abonnement: onbeperkt
De downloadfrequentie vanuit Docker wordt gedefinieerd als het aantal manifestverzoeken aan Docker Hub. De downloadfrequentiebeperkingen zijn afhankelijk van het type account dat het image opvraagt, en niet van het type account van de eigenaar van het image. Voor anonieme (niet-geregistreerde) gebruikers is de downloadfrequentie gebonden aan het IP-adres.
N.B. Meer details en best practices krijgt u U kunt het op een tijdstip volgen dat u uitkomt — zowel qua tijd als gemoedstoestand.
We ontvangen vragen van klanten en de gemeenschap over de lagen van containerimages. We houden geen rekening met de lagen van een image bij het beperken van de downloadfrequentie, omdat we het downloaden van manifesten beperken, en het aantal lagen (blob-verzoeken) momenteel niet is beperkt. Deze verandering is gebaseerd op feedback van de gemeenschap, om het gebruiksvriendelijker te maken, zodat gebruikers niet elke laag in elk image dat ze gebruiken hoeven te tellen.
Een gedetailleerde analyse van de downloadfrequenties van Docker Hub-images
We spent a lot of time analyzing the download of images from Docker Hub to determine the cause of the speed limitations and how exactly they should be applied. What we observed confirmed that almost all users download images at predictable speeds for typical workflows. However, there is a noticeable impact from a small number of anonymous users, for instance, about 30% of all downloads come from only 1% of anonymous users.
The new limitations are based on this analysis, so most of our users will not be affected. These restrictions are designed to reflect the normal usage patterns of developers — exploring Docker, developing code, creating images, etc.
Assistance for developers to better understand download rate limiting
Now that we understand the impact and where the boundaries should be, we needed to define the technical conditions for implementing these limitations. Limiting image downloads from the Docker registry is quite complex. You won’t find an API for uploads in the registry documentation — it simply does not exist. In reality, downloading an image involves a combination of manifest requests and blobs in the API, and they are executed differently depending on the client's state and the requested image.
For example, if you already have an image, Docker Engine will issue a manifest request, realize that it already has all the necessary layers based on the accepted manifest, and then stop. On the other hand, if you are downloading an image that supports multiple architectures, the manifest request will return a list of image manifests for each supported architecture. Then Docker Engine will issue another manifest request for the specific architecture it is running on, receiving a list of all layers of the image in response. It will then request each missing layer (blob).
N.B. This topic is discussed in more detail on , where we will cover all its tools: from basic abstractions to network parameters, nuances of working with various operating systems and programming languages. You will become familiar with the technology and understand where and how to best use Docker.
Het blijkt dat het downloaden van een image in feite één of twee manifest-aanvragen is, evenals een onbeperkt aantal laag (blob) aanvragen. Historisch gezien heeft Docker het downloadvolume op basis van lagen gevolgd, omdat dit het meest gerelateerd is aan het gebruik van bandbreedte. Toch hebben we geluisterd naar de community, omdat het moeilijker is om het aantal opgevraagde lagen bij te houden, wat leidt tot een negeren van best practices met betrekking tot het werken met Dockerfile, en het intuïtief onbegrijpelijker is voor gebruikers die gewoon met de registry willen werken zonder te veel in de details te duiken.
Daarom beperken we het aantal aanvragen op basis van manifest-aanvragen. Dit is direct gerelateerd aan het downloaden van images, wat voor gebruikers gemakkelijk te begrijpen is. Er is echter een klein detail — als je probeert een image te downloaden die al bestaat, wordt de aanvraag nog steeds geteld, zelfs als je de lagen niet downloadt. In ieder geval hopen we dat deze methode om het downloadvolume te beperken zowel eerlijk als handig voor gebruikers zal zijn.
We kijken uit naar uw feedback
We zullen de limieten in de gaten houden en de nodige aanpassingen maken op basis van typische gebruiksscenario's, om ervoor te zorgen dat de limieten geschikt zijn voor elk type gebruiker, en we zullen er in het bijzonder naar streven om nooit ontwikkelaars in hun werkzaamheden te belemmeren.
Houd de berichten de komende weken in de gaten, er komt nog een artikel over het instellen van CI en productiesystemen in het licht van deze veranderingen.
Ten slotte zullen we ter ondersteuning van de open source softwareontwikkelaarsgemeenschap, totdat 1 november nieuwe tariefplannen voor open source aanbieden. Om een aanvraag in te dienen — moet je het formulier invullen .
Voor meer informatie over de laatste wijzigingen in de servicevoorwaarden kunt u contact opnemen met .
Degenen die de limieten voor het downloaden van images willen verhogen, biedt Docker onbeperkt downloaden van images als een kenmerk van de . Zoals altijd kijken we uit naar feedback en vragen .
Bron: habr.com
