Comment l'entreprise Docker évolue pour servir des millions de développeurs, partie 2 : Sorties

Ceci est le deuxième article d'une série d'articles, qui abordera les limitations liées au téléchargement des images de conteneurs.

Dans de la première partie Nous avons examiné en détail les images stockées dans Docker Hub, le plus grand registre d'images de conteneurs. Nous écrivons cela afin que vous compreniez mieux comment nos conditions de service mises à jour affecteront les équipes de développement utilisant Docker Hub pour gérer les images de conteneurs et les pipelines CICD.

Les limitations concernant la fréquence des téléchargements ont été annoncées précédemment dans nos Conditions de service. Nous examinerons plus en détail les limitations de fréquence qui entreront en vigueur à partir du 1er novembre 2020 :

Plan tarifaire gratuit, utilisateurs anonymes : 100 téléchargements toutes les 6 heures
Plan tarifaire gratuit, utilisateurs authentifiés : 200 téléchargements toutes les 6 heures
Plan tarifaire Pro : sans limitations
Plan tarifaire Équipe : sans limitations

La fréquence des téléchargements côté Docker est définie comme le nombre de requêtes de manifests à Docker Hub. Les limitations de fréquence des téléchargements d'images dépendent du type de compte demandant l'image, et non du type de compte propriétaire de l'image. Pour les utilisateurs anonymes (non authentifiés), la fréquence des téléchargements est liée à l'adresse IP.

N.B. Plus de subtilités et des meilleures pratiques vous seront fournies dans le cours Docker dispensé par des praticiens. De plus, vous pouvez le suivre quand cela vous convient — tant en termes de temps que d'humeur.

Nous recevons des questions de nos clients et de la communauté concernant les couches des images de conteneurs. Nous ne tenons pas compte des couches de l'image lors de la limitation de la fréquence de téléchargement, car nous limitons le téléchargement des manifests, et le nombre de couches (requêtes blob) n'est actuellement pas limité. Ce changement est basé sur les retours de la communauté, afin de le rendre plus convivial pour les utilisateurs, de sorte qu'il n'est pas nécessaire de compter les couches sur chaque image utilisée.

Analyse détaillée des fréquences de téléchargement des images de Docker Hub

Nous avons consacré beaucoup de temps à analyser le téléchargement des images depuis Docker Hub afin de déterminer la cause des limitations de vitesse ainsi que la manière dont celles-ci doivent être appliquées. Ce que nous avons observé a confirmé que, en fait, tous les utilisateurs téléchargent des images à une vitesse prévisible pour des flux de travail typiques. Cependant, il y a une influence notoire d'un petit nombre d'utilisateurs anonymes, par exemple, environ 30 % de tous les téléchargements proviennent seulement de 1 % d'utilisateurs anonymes.

Les nouvelles limitations sont basées sur cette analyse, donc la plupart de nos utilisateurs ne seront pas affectés. Ces limitations sont conçues pour refléter l'utilisation normale par les développeurs — exploration de Docker, développement de code, création d'images, etc.

Aide aux développeurs pour mieux comprendre la limitation du taux de téléchargement

Maintenant que nous avons compris l'influence ainsi que les limites qui doivent être établies, nous devions définir les conditions techniques de fonctionnement de ces limitations. Limiter le téléchargement des images depuis le registre Docker est assez complexe. Vous ne trouverez pas d'API pour les téléchargements dans la documentation du registre — elle n'existe tout simplement pas. En réalité, le téléchargement d'une image représente une combinaison de demandes de manifeste et de blobs via l'API, et celles-ci sont exécutées différemment, en fonction de l'état du client et de l'image demandée.

Par exemple, si vous avez déjà une image, Docker Engine fera une demande de manifeste, comprendra qu'il possède déjà toutes les couches nécessaires en fonction du manifeste fourni, puis s'arrêtera. D'autre part, si vous téléchargez une image qui prend en charge plusieurs architectures, la demande de manifeste retournera une liste de manifestes d'images pour chaque architecture prise en charge. Ensuite, Docker Engine fera une autre demande de manifeste concernant l'architecture spécifique sur laquelle il fonctionne, et en retour, il obtiendra la liste de toutes les couches de l'image. Il demandera alors chaque couche manquante (blob).

N.B. Ce sujet est abordé de manière plus approfondie dans le cours Docker, dans lequel nous examinerons tous ses outils : des abstractions de base aux paramètres réseau, en passant par les subtilités de travail avec différents systèmes d'exploitation et langages de programmation. Vous découvrirez la technologie et comprendrez où et comment utiliser Docker de manière optimale.

Il s'avère que le téléchargement d'une image implique en réalité une ou deux requêtes de manifeste, ainsi que d'innombrables requêtes de couches (blob). Historiquement, Docker a suivi la fréquence des téléchargements en fonction des couches, car cela est le plus lié à l'utilisation de la bande passante. Cependant, nous avons écouté la communauté, car cela complique les choses, puisque nous devons suivre le nombre de couches demandées, ce qui entraînera l'ignorance des meilleures pratiques concernant le travail avec Dockerfile, et sera également moins intuitif pour les utilisateurs souhaitant simplement travailler avec le registre sans trop se soucier des détails.

Nous limitons donc le nombre de requêtes en fonction des requêtes de manifeste. Cela est directement lié au téléchargement des images, ce qui est facile à comprendre pour les utilisateurs. Cependant, il y a un petit détail — si vous essayez de télécharger une image qui existe déjà, la requête sera tout de même prise en compte, même si vous ne téléchargerez pas les couches. Quoi qu'il en soit, nous espérons que cette méthode de limitation du taux de téléchargement sera à la fois équitable et pratique pour les utilisateurs.

Nous attendons vos retours

Nous surveillerons les limitations et apporterons les corrections nécessaires en fonction des scénarios d'utilisation typiques, afin de nous assurer que les limitations conviennent à chaque type d'utilisateur, et en particulier, nous nous efforcerons de ne jamais gêner les développeurs dans leur travail.

Restez à l'écoute des messages dans les semaines à venir, un autre article sur la configuration CI et les systèmes opérationnels sera publié à la lumière de ces changements.

Enfin, dans le cadre du soutien à la communauté des développeurs de logiciels open source, jusqu'au 1er novembre, nous fournirons de nouveaux plans tarifaires pour le code source ouvert. Pour postuler, vous devez remplir un formulaire ici.

Pour plus d'informations sur les dernières modifications des conditions de service, veuillez contacter FAQ.

Pour ceux qui doivent lever les limitations sur la fréquence de téléchargement des images, Docker propose un téléchargement illimité des images en tant que fonctionnalité des plans Pro ou Team. Comme toujours, nous attendons vos retours et vos questions ici.

Source : habr.com