Гэта другі артыкул з серыі артыкулаў, у ім будуць разгледжаны абмежаванні пры спампоўцы вобразаў кантэйнераў.
В мы падрабязна разгледзелі вобразы, якія захоўваюцца ў Docker Hub, найбуйнейшым registry вобразаў кантэйнераў. Мы пішам пра гэта для таго, каб вы лепш разумелі, як нашы абноўленыя Умовы абслугоўвання паўплываюць на каманды распрацоўшчыкаў, якія выкарыстоўваюць Docker Hub для кіравання выявамі кантэйнераў і канвеерамі CICD.
Аб абмежаваннях па частаце запампоўкі было абвешчана раней у нашых . Мы падрабязней разгледзім абмежаванні па частаце, якія набудуць моц з 1 лістапада 2020 гады:
Бясплатны тарыфны план, ананімныя карыстальнікі: 100 запамповак за 6 гадзін
Бясплатны тарыфны план, аўтарызаваныя карыстальнікі: 200 запамповак за 6 гадзін
Тарыфны план Pro: без абмежаванняў
Тарыфны план Team: без абмежаванняў
Частата запамповак з боку Docker вызначаецца як лік запытаў маніфестаў да Docker Hub. Абмежаванні па частаце запампоўкі выяў залежаць ад тыпу ўліковага запісу, запытвальнага выява, а не ад тыпу ўліковага запісу ўладальніка выявы. Для ананімных (неаўтарызаваных) карыстачоў частата запампоўкі прывязана да ip-адрасу.
NB Больш тонкасцяў і best practice кейсаў вы атрымаеце . Прычым вы можаце праходзіць яго, калі вам зручна - і па часе, і па настроі.
Мы атрымліваем пытанні ад кліентаў і супольнасці датычна пластоў вобразаў кантэйнераў. Мы не ўлічваем пласты выявы пры абмежаванні частаты запампоўкі, таму што мы абмяжоўваем запампоўку маніфестаў, а колькасць пластоў (запытаў blob) на дадзены момант не абмежавана. Гэтая змена заснавана на водгуках супольнасці, каб зрабіць яго больш прыязным да карыстачоў, так што карыстачам няма галечы ў падліку пластоў на кожным выкарыстоўваным імі выяве.
Падрабязны аналіз частот запампоўкі выяў Docker Hub
Мы патрацілі шмат часу аналізуючы спампоўванне вобразаў з Docker Hub, каб вызначыць прычыну абмежавання хуткасці, а таксама як менавіта трэба абмяжоўваць. Тое, што мы ўбачылі, пацвердзіла, што фактычна ўсе карыстачы спампоўваюць выявы з прадказальнай хуткасцю для тыпавых працоўных працэсаў. Аднак ёсць прыкметны ўплыў невялікай колькасці ананімных карыстальнікаў, напрыклад каля 30% усіх запамповак зыходзяць толькі ад 1% ананімных карыстальнікаў.
Новыя абмежаванні заснаваныя на гэтым аналізе, так што большасць нашых карыстальнікаў не пацерпяць. Гэтыя абмежаванні зроблены для адлюстравання звычайнага выкарыстання распрацоўшчыкамі - вывучэння Docker, распрацоўкі кода, стварэння вобразаў і да т.п.
Дапамога распрацоўнікам для лепшага разумення абмежавання частаты запампоўкі
Цяпер, калі нам стаў зразумелы ўплыў, а таксама дзе павінны быць межы, нам трэба было вызначыць тэхнічныя ўмовы працы гэтых абмежаванняў. Абмяжоўваць запампоўку выяў з Docker registry досыць складана. Вы не знойдзеце API для запамповак у апісанні registry – яго проста не існуе. Па факце запампоўка выявы ўяўляе сабой камбінацыю запытаў маніфесту і blobs у API, а яны выконваюцца па-рознаму, у залежнасці ад стану кліента і запытанай выявы.
Да прыкладу, калі ў вас ужо ёсць выява, Docker Engine выдасць запыт на маніфест, зразумее, што ў яго ўжо ёсць усе неабходныя пласты на аснове прынятага маніфеста, пасля чаго спыніцца. З іншага боку - калі вы спампоўваеце выяву, які падтрымлівае некалькі архітэктур, запыт на маніфест верне спіс маніфестаў выяў для кожнай падтрымоўванай архітэктуры. Затым Docker Engine выдасць яшчэ адзін запыт на маніфест датычна канкрэтнай архітэктуры, на якой ён працуе, у адказ атрымае спіс усіх пластоў выявы. Затым ён будзе запытваць кожны адсутны пласт (blob).
NB Больш шырока гэтая тэма расчынена на , у якім мы разбяром усе яго прылады: ад асноўных абстракцый да параметраў сеткі, нюансаў працы з рознымі АС і мовамі праграмавання. Вы пазнаёміцеся з тэхналогіяй і зразумееце, дзе і як лепш выкарыстоўваць Docker.
Атрымліваецца, што спампоўка выявы гэта насамрэч адзін ці два запыту маніфеста, а таксама ад нуля і да бясконцасці - запыты пластоў (blob). Гістарычна Docker адсочваў частату спампоўкі на аснове пластоў, паколькі гэта найболей звязана з выкарыстаннем паласы прапускання. Але тым не менш, мы прыслухаліся да супольнасці, што так складаней, бо трэба адсочваць запытаны лік пластоў, што прывядзе да ігнаравання best practices датычна працы з Dockerfile, а таксама інтуітыўна незразумела для карыстальнікаў, якія жадаюць проста працаваць з registry, не моцна разбіраючыся ў дэталях .
Так што мы абмяжоўваем колькасць запытаў на аснове запытаў на маніфесты. Гэта напрамую звязана са спампоўкай вобразаў, што лёгка зразумець карыстальнікам. Ёсць праўда невялікі нюанс - калі вы спрабуеце спампаваць выяву, які ўжо ёсць, запыт усё роўна будзе ўлічаны, нават калі вы і не будзеце пампаваць пласты. У любым выпадку мы спадзяемся, што такі метад абмежавання частаты спампоўкі будзе і справядлівым, і зручным для карыстачоў.
Чакаем вашыя водгукі
Мы будзем сачыць за абмежаваннямі і ўносіць адпаведныя праўкі на аснове тыпавых варыянтаў выкарыстання, каб быць упэўненымі, што абмежаванні падыходзяць кожнаму тыпу карыстальнікаў, а таксама, у прыватнасці, мы пастараемся ніколі не перашкаджаць распрацоўшчыкам выканаць іх працу.
Сачыце за паведамленнямі ў бліжэйшыя тыдні, будзе яшчэ адзін артыкул аб наладзе CI і баявых сістэм у святле гэтых змен.
Нарэшце, у рамках падтрымкі супольнасці распрацоўшчыкаў ПЗ з адкрытым зыходным кодам, да 1 лістапада мы дамо новыя тарыфныя планы для адкрытага зыходнага кода. Каб падаць заяўку - трэба запоўніць форму .
Для атрымання дадатковай інфармацыі аб апошніх зменах умоў абслугоўвання звярніцеся да .
Тым, каму трэба падняць абмежаванні на частату запампоўкі выяў, Docker прапануе неабмежаваную спампоўку выяў у якасці асаблівасці . Як заўсёды, мы чакаем зваротную сувязь і пытанні .
Крыніца: habr.com