Hogyan képes a Docker Business fejlesztők millióit kiszolgálni, 2. rész: Kimenő adatok

Hogyan képes a Docker Business fejlesztők millióit kiszolgálni, 2. rész: Kimenő adatok

Ez a második cikk egy cikksorozatban, amely a tárolóképek letöltésével kapcsolatos korlátozásokat tárgyalja.

В az első rész Megnéztük közelebbről a Docker Hubban, a legnagyobb konténerkép-nyilvántartásban tárolt képeket. Ezt azért írjuk, hogy jobban megértse, hogyan érintik frissített Általános Szerződési Feltételeink a Docker Hubot használó fejlesztőcsapatokat a konténerképek és CICD-folyamatok kezelésére.

A letöltési gyakoriságra vonatkozó korlátozásokat korábban közöltük lapunkban Szolgáltatás feltételei. Megnézzük közelebbről a 1. november 2020-től életbe lépő frekvenciakorlátozásokat:

Ingyenes csomag, névtelen felhasználók: 100 letöltés 6 óra alatt
Ingyenes csomag, jogosult felhasználók: 200 letöltés 6 óra alatt
Pro terv: Korlátlan
Csapat tarifacsomag: korlátlan

A Docker letöltési gyakorisága a Docker Hub felé küldött jegyzékkérelmek száma. A képek letöltési gyakoriságának korlátozása a képet kérő fiók típusától függ, nem pedig a képet birtokló fiók típusától. Anonim (jogosulatlan) felhasználók esetében a letöltési gyakoriság az IP-címhez van kötve.

NB További finomságokat és legjobb gyakorlati példákat fog kapni a Docker tanfolyamon gyakorlóktól. Sőt, bármikor elviheti, amikor Önnek kényelmes - mind az idő, mind a hangulat szempontjából.

Az ügyfelektől és a közösségtől kapunk kérdéseket a konténerképrétegekkel kapcsolatban. A letöltési gyakoriság korlátozásakor nem számolunk képrétegekkel, mert korlátozzuk a jegyzékletöltéseket, és a rétegek (blob-kérelmek) száma jelenleg korlátlan. Ez a változás a közösségi visszajelzéseken alapul, hogy felhasználóbarátabb legyen, így a felhasználóknak nem kell minden képen megszámolniuk a rétegeket.

A Docker Hub képletöltési arányának részletes elemzése

Sok időt töltöttünk a Docker Hubról származó képletöltések elemzésével, hogy meghatározzuk, mi okozza a sebességkorlátozást, és pontosan hogyan kell korlátozni. A látottak megerősítették, hogy gyakorlatilag minden felhasználó kiszámítható sebességgel töltötte le a képeket a tipikus munkafolyamatokhoz. A névtelen felhasználók kis száma azonban észrevehetően befolyásolja, például az összes letöltés körülbelül 30%-a a névtelen felhasználók mindössze 1%-ától származik.

Hogyan képes a Docker Business fejlesztők millióit kiszolgálni, 2. rész: Kimenő adatok

Az új korlátozások ezen az elemzésen alapulnak, így a legtöbb felhasználónkat nem érinti. Ezek a korlátozások az általános fejlesztői használatot tükrözik – Docker tanulás, kód fejlesztés, képek létrehozása stb.

Segítsen a fejlesztőknek, hogy jobban megértsék a letöltési sebesség korlátozását

Most, hogy megértettük a hatást, és azt is, hogy hol legyenek a határok, meg kellett határoznunk e korlátozások működésének technikai feltételeit. A képek letöltésének korlátozása a Docker rendszerleíró adatbázisból meglehetősen nehéz. A rendszerleíró adatbázis leírásában nem talál feltöltési API-t – egyszerűen nem létezik. Valójában a kép letöltése az API-ban található jegyzékkérelmek és blobok kombinációja, amelyek végrehajtása a fájl állapotától függően eltérő. ügyfél és a kért kép.

Például, ha már rendelkezik képpel, a Docker Engine kiad egy jegyzékkérést, felismeri, hogy az elfogadott jegyzék alapján már rendelkezik az összes szükséges réteggel, majd leáll. Másrészt, ha olyan lemezképet tölt le, amely több architektúrát is támogat, a jegyzéklekérdezés minden támogatott architektúrához visszaadja a képjegyzék-leírások listáját. A Docker Engine ezután újabb jegyzékkérést ad ki az adott architektúrához, amelyen fut, és cserébe megkapja a kép összes rétegének listáját. Ezután minden hiányzó réteget (blob) lekérdez.

NB Ezzel a témával szélesebb körben foglalkozunk Docker tanfolyam, amelyben minden eszközét elemezzük: az alapvető absztrakcióktól a hálózati paraméterekig, a különféle operációs rendszerekkel és programozási nyelvekkel való munka árnyalataiig. Megismerheti a technológiát, és megértheti, hol és hogyan használja a legjobban a Dockert.

Kiderült, hogy egy kép letöltése valójában egy vagy két jegyzékkérelem, valamint nullától a végtelenig - rétegkérések (blob). Történelmileg a Docker rétegről rétegre követte a letöltési gyakoriságot, mivel ez leginkább a sávszélesség-használathoz kapcsolódik. Ennek ellenére meghallgattuk a közösséget, hogy ez nehezebb, mert követni kell a kért rétegszámot, ami a Dockerfile-lel való munkavégzés legjobb gyakorlatainak figyelmen kívül hagyásához vezet, és intuitívabb azok számára, akik csak dolgozni szeretnének a rendszerleíró adatbázist anélkül, hogy sokat értene a részletekhez.

Ezért korlátozzuk a kérelmek számát a manifest kérések alapján. Ez közvetlenül kapcsolódik a képek letöltéséhez, ami könnyen érthető a felhasználók számára. Van azonban egy kis árnyalat – ha már létező képet próbál letölteni, a kérést akkor is figyelembe veszi a rendszer, ha nem tölti le a rétegeket. Mindenesetre reméljük, hogy a letöltési gyakoriság korlátozásának ez a módszere tisztességes és kényelmes lesz a felhasználók számára.

Várjuk visszajelzését

Figyelni fogjuk a korlátozásokat, és a tipikus használati esetek alapján megfelelő kiigazításokat végzünk annak érdekében, hogy a korlátozások minden felhasználótípusnak megfelelőek legyenek, és különösen arra törekszünk, hogy soha ne akadályozzuk meg a fejlesztőket munkájuk elvégzésében.

Maradjon velünk a következő hetekben egy újabb cikkért, amely a CI és a harci rendszerek felállításáról szól ezen változások fényében.

Végül, a nyílt forráskódú közösség támogatásának részeként november 1-ig új díjszabási terveket biztosítunk a nyílt forráskódhoz. A jelentkezéshez kérjük töltse ki az űrlapot itt.

A szolgáltatási feltételek legújabb változásaival kapcsolatos további információkért látogasson el a következő oldalra FAQ.

Azok számára, akiknek meg kell emelniük a képek letöltési gyakoriságának korlátját, a Docker korlátlan számú képletöltést kínál. Profi vagy csapat tervek. Mint mindig, szívesen fogadjuk a visszajelzéseket és kérdéseket. itt.

Forrás: will.com

Hozzászólás