როგორ მუშაობს Docker Business Scales, რათა მოემსახუროს მილიონობით დეველოპერს, ნაწილი 2: გამავალი მონაცემები

ეს არის სტატიების სერიის მეორე სტატია, რომელიც მოიცავს შეზღუდვებს კონტეინერის სურათების ჩამოტვირთვისას.

В პირველი ნაწილი ჩვენ უფრო ახლოს დავაკვირდით Docker Hub-ში შენახულ სურათებს, კონტეინერის სურათების უდიდეს რეესტრში. ჩვენ ვწერთ ამას, რათა დაგეხმაროთ უკეთ გაიგოთ, როგორ იმოქმედებს ჩვენი განახლებული მომსახურების პირობები განვითარების გუნდებზე, რომლებიც იყენებენ Docker Hub-ს კონტეინერის სურათებისა და CICD მილსადენების სამართავად.

ჩამოტვირთვის სიხშირეზე შეზღუდვები წინასწარ იყო გამოცხადებული ჩვენში Მომსახურების პირობები. ჩვენ უფრო დეტალურად ვუყურებთ სიხშირის შეზღუდვებს, რომლებიც ძალაში შევა 1 წლის 2020 ნოემბრიდან:

უფასო გეგმა, ანონიმური მომხმარებლები: 100 ჩამოტვირთვა 6 საათში
უფასო გეგმა, ავტორიზებული მომხმარებლები: 200 ჩამოტვირთვა 6 საათში
პრო გეგმა: შეუზღუდავი
გუნდის სატარიფო გეგმა: შეუზღუდავი

Docker ჩამოტვირთვის სიხშირე განისაზღვრება, როგორც Docker Hub-ზე მანიფესტის მოთხოვნების რაოდენობა. სურათების ჩამოტვირთვის სიხშირის შეზღუდვები ეფუძნება იმ ანგარიშის ტიპს, რომელიც ითხოვს სურათს და არა იმ ანგარიშის ტიპს, რომელსაც ეკუთვნის სურათი. ანონიმური (არაავტორიზებული) მომხმარებლებისთვის ჩამოტვირთვის სიხშირე მიბმულია IP მისამართთან.

NB თქვენ მიიღებთ მეტ დახვეწილობას და საუკეთესო პრაქტიკის შემთხვევებს დოკერის კურსზე პრაქტიკოსებისგან. უფრო მეტიც, შეგიძლიათ აიღოთ ის, როცა თქვენთვის მოსახერხებელია - როგორც დროის, ასევე განწყობის თვალსაზრისით.

ჩვენ ვიღებთ კითხვებს მომხმარებლებისგან და საზოგადოებისგან კონტეინერის გამოსახულების ფენებთან დაკავშირებით. ჩვენ არ ვითვლით გამოსახულების შრეებს ჩამოტვირთვის სიხშირის შეზღუდვისას, რადგან ჩვენ ვზღუდავთ მანიფესტების ჩამოტვირთვებს და შრეების რაოდენობა (blob მოთხოვნები) ამჟამად შეუზღუდავია. ეს ცვლილება ეფუძნება საზოგადოების გამოხმაურებას, რათა ის უფრო მოსახერხებელი გახდეს მომხმარებლისთვის, რათა მომხმარებლებს არ მოუწიონ ფენების დათვლა თითოეულ სურათზე, რომელსაც იყენებენ.

Docker Hub-ის სურათების ჩამოტვირთვის მაჩვენებლების დეტალური ანალიზი

ჩვენ დიდი დრო დავხარჯეთ Docker Hub-დან სურათების ჩამოტვირთვების ანალიზზე, რათა განვსაზღვროთ, თუ რა იწვევდა განაკვეთის ლიმიტს და ზუსტად როგორ უნდა შეიზღუდოს იგი. ის, რაც ჩვენ ვნახეთ, დაადასტურა, რომ პრაქტიკულად ყველა მომხმარებელმა ჩამოტვირთა სურათები პროგნოზირებადი სიჩქარით ტიპიური სამუშაო პროცესებისთვის. თუმცა, შესამჩნევია ანონიმური მომხმარებლების მცირე რაოდენობის გავლენა, მაგალითად, ჩამოტვირთვების დაახლოებით 30% მოდის ანონიმური მომხმარებლების მხოლოდ 1%-ზე.

ახალი შეზღუდვები ეფუძნება ამ ანალიზს, ამიტომ ჩვენი მომხმარებლების უმეტესობა არ დაზარალდება. ეს შეზღუდვები შექმნილია დეველოპერების საერთო გამოყენების ასახვის მიზნით - Docker-ის სწავლა, კოდის შემუშავება, სურათების შექმნა და ა.შ.

დაეხმარეთ დეველოპერებს ჩამოტვირთვის სიჩქარის შეზღუდვის უკეთესად გაგებაში

ახლა, როცა გავიგეთ გავლენა, ისევე როგორც სად უნდა იყოს საზღვრები, დაგვჭირდა ამ შეზღუდვების მოქმედების ტექნიკური პირობების დადგენა. Docker რეესტრიდან სურათების ჩამოტვირთვის შეზღუდვა საკმაოდ რთულია. თქვენ ვერ იპოვით ატვირთვის API-ს რეესტრის აღწერილობაში - ის უბრალოდ არ არსებობს. ფაქტობრივად, სურათის ჩამოტვირთვა არის API-ში მანიფესტის მოთხოვნისა და ბლომების ერთობლიობა და ისინი განსხვავებულად სრულდება, რაც დამოკიდებულია მდგომარეობის მდგომარეობაზე. კლიენტი და მოთხოვნილი სურათი.

მაგალითად, თუ უკვე გაქვთ სურათი, Docker Engine გამოსცემს მანიფესტის მოთხოვნას, გააცნობიერებს, რომ მას უკვე აქვს ყველა საჭირო ფენა მიღებული მანიფესტის საფუძველზე და შემდეგ შეწყვეტს. მეორეს მხრივ, თუ ჩამოტვირთავთ სურათს, რომელიც მხარს უჭერს მრავალ არქიტექტურას, მანიფესტის მოთხოვნა დააბრუნებს გამოსახულების მანიფესტების სიას თითოეული მხარდაჭერილი არქიტექტურისთვის. შემდეგ Docker Engine გამოსცემს სხვა მანიფესტის მოთხოვნას კონკრეტული არქიტექტურისთვის, რომელზედაც მუშაობს და სანაცვლოდ მიიღებს სურათის ყველა ფენის ჩამონათვალს. შემდეგ ის მოთხოვნის თითოეულ გამოტოვებულ ფენას (blob).

NB ეს თემა უფრო ფართოდ არის გაშუქებული დოკერის კურსი, რომელშიც გავაანალიზებთ მის ყველა ხელსაწყოს: ძირითადი აბსტრაქციებიდან ქსელის პარამეტრებამდე, სხვადასხვა ოპერაციულ სისტემებთან და პროგრამირების ენებთან მუშაობის ნიუანსებამდე. თქვენ გაეცნობით ტექნოლოგიას და გაიგებთ სად და როგორ საუკეთესოდ გამოიყენოთ Docker.

გამოდის, რომ სურათის ჩამოტვირთვა რეალურად არის ერთი ან ორი მანიფესტი მოთხოვნა, ასევე ნულიდან უსასრულობამდე - ფენის მოთხოვნა (blob). ისტორიულად, Docker აკონტროლებდა ჩამოტვირთვის სიხშირეს ფენა-ფენაზე, რადგან ეს ყველაზე მეტად ასოცირდება გამტარუნარიანობის გამოყენებასთან. მაგრამ, მიუხედავად ამისა, ჩვენ მოვუსმინეთ საზოგადოებას, რომ ეს უფრო რთულია, რადგან თქვენ უნდა აკონტროლოთ ფენების მოთხოვნილი რაოდენობა, რაც გამოიწვევს Dockerfile-თან მუშაობის საუკეთესო პრაქტიკის უგულებელყოფას და ასევე უფრო ინტუიციურია მომხმარებლებისთვის, რომლებსაც უბრალოდ სურთ მუშაობა. რეესტრში დეტალების დიდი გაგების გარეშე.

ასე რომ, ჩვენ ვზღუდავთ მოთხოვნების რაოდენობას მანიფესტის მოთხოვნების საფუძველზე. ეს პირდაპირ კავშირშია სურათების ჩამოტვირთვასთან, რაც მომხმარებლისთვის ადვილი გასაგებია. თუმცა არის პატარა ნიუანსი - თუ უკვე არსებული სურათის ჩამოტვირთვას ცდილობთ, მოთხოვნა მაინც იქნება გათვალისწინებული, თუნდაც არ გადმოწეროთ ფენები. ნებისმიერ შემთხვევაში, ვიმედოვნებთ, რომ ჩამოტვირთვის სიხშირის შეზღუდვის ეს მეთოდი სამართლიანი და მოსახერხებელი იქნება მომხმარებლებისთვის.

ველოდებით თქვენს გამოხმაურებას

ჩვენ დავაკვირდებით შეზღუდვებს და გავაკეთებთ შესაბამის კორექტირებას ტიპიური გამოყენების შემთხვევებზე დაყრდნობით, რათა დავრწმუნდეთ, რომ შეზღუდვები შესაბამისია თითოეული ტიპის მომხმარებლისთვის და, კერძოდ, ვეცდებით არასოდეს შევუშალოთ ხელი დეველოპერებს თავიანთი სამუშაოს შესრულებაში.

თვალყური ადევნეთ მომავალ კვირებში სხვა სტატიას CI და საბრძოლო სისტემების დაყენების შესახებ ამ ცვლილებების გათვალისწინებით.

და ბოლოს, როგორც ჩვენი მხარდაჭერის ნაწილი ღია კოდის საზოგადოებისთვის, ჩვენ შემოგთავაზებთ ახალ ფასების გეგმებს ღია წყაროსთვის 1 ნოემბრამდე. განაცხადის მისაღებად გთხოვთ შეავსოთ ფორმა აქ.

დამატებითი ინფორმაციისთვის მომსახურების პირობების უახლესი ცვლილებების შესახებ, გთხოვთ ეწვიოთ კითხვა-პასუხი.

მათთვის, ვისაც სურათების ჩამოტვირთვის სიხშირის ლიმიტის გაზრდა სჭირდება, Docker გთავაზობთ შეუზღუდავი სურათების ჩამოტვირთვას, როგორც ფუნქციას პრო ან გუნდის გეგმები. როგორც ყოველთვის, ჩვენ მივესალმებით გამოხმაურებას და კითხვებს. აქ.

წყარო: www.habr.com