მიწოდების ხელსაწყოების ევოლუცია ან აზრები Docker-ის, deb-ის, jar-ის და სხვათა შესახებ

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

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

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

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

კალკულატორების ეპოქა

არა, იყო კიდევ უფრო ადრეული მომენტი, იყო კალკულატორიც MK-61 и MK-52.

ასე რომ, როცა მქონდა MK-61, მაშინ პროგრამის გადატანის გზა იყო ჩვეულებრივი ფურცელი ყუთში, რომელზეც ეწერა პროგრამა, რომელიც საჭიროების შემთხვევაში ხელით გასაშვებად იწერებოდა კალკულატორში. თუ თამაში გინდა (დიახ, ამ ანტიდილუვიურ კალკულატორსაც ჰქონდა თამაშები) - დაჯექი და შედი პროგრამა კალკულატორში. ბუნებრივია, როდესაც კალკულატორი გამორთული იყო, პროგრამა დავიწყებას მიეცა. ქაღალდზე პირადად დაწერილი კალკულატორის კოდების გარდა, გადაცემები გამოქვეყნდა ჟურნალებში "რადიო" და "ტექნოლოგია ახალგაზრდებისთვის", ასევე იბეჭდებოდა იმდროინდელ წიგნებში.

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

ყველაზე დიდი პროგრამის ზომა კალკულატორში იყო 105 ნაბიჯი, ხოლო მუდმივი მეხსიერების ზომა MK-52-ში იყო 512 ნაბიჯი.

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

• ემულატორი MK-61 Android-ისთვის
• პროგრამის კატალოგი MK-61-ისთვის

მოკლე გადახვევა MK-52-ის შესახებ (ვიკიპედიიდან)

MK-52 კოსმოსში გაფრინდა Soyuz TM-7 კოსმოსური ხომალდით. ის უნდა გამოეყენებინათ სადესანტო ტრაექტორიის გამოსათვლელად იმ შემთხვევაში, თუ ბორტ კომპიუტერი ვერ მოხერხდა.

52 წლიდან MK-1988 Elektronika-Astro მეხსიერების გაფართოების განყოფილებით მიეწოდება საზღვაო ძალების გემებს, როგორც ნავიგაციის გამოთვლითი ნაკრების ნაწილი.

პირველი პერსონალური კომპიუტერები

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

კასეტაზე შენახვა ჩვეულებრივ იყო ერთი ან ორი ბინარული ფაილის სახით, დანარჩენი ყველაფერი შიგნით იყო. საიმედოობა ძალიან დაბალი იყო, პროგრამის 2-3 ასლის შენახვა მომიწია. ჩატვირთვის დრო ასევე იმედგაცრუებული იყო და ენთუზიასტები ცდილობდნენ ექსპერიმენტებს სხვადასხვა სიხშირის კოდირებით ამ ხარვეზების დასაძლევად. იმ დროს მე თვითონ ჯერ არ ვიყავი ჩართული პროფესიონალური პროგრამული უზრუნველყოფის შემუშავებაში (არ ჩავთვლით მარტივ პროგრამებს BASIC-ში), ასე რომ, სამწუხაროდ, დეტალურად არ გეტყვით, თუ როგორ იყო ყველაფერი შიგნით მოწყობილი. თავად ის ფაქტი, რომ კომპიუტერს უმეტესწილად მხოლოდ ოპერატიული მეხსიერება ჰქონდა, განსაზღვრა მონაცემთა შენახვის სქემის სიმარტივე.

საიმედო და დიდი საცავის მედიის გაჩენა

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

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

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

იმ დროს ლინუქსის არსებობა ჩემთვის ჯერ არ იყო ღია; მე ვცხოვრობდი MS DOS-ის და, მოგვიანებით, Windows-ის სამყაროში და ვწერდი Borland Pascal-სა და Delphi-ში, ზოგჯერ C++-ისკენ ვიყურები. ბევრი ადამიანი იყენებდა InstallShield პროდუქციის მიწოდებას მაშინ. ru.wikipedia.org/wiki/InstallShield, რომელმაც საკმაოდ წარმატებით გადაჭრა პროგრამული უზრუნველყოფის განლაგებისა და კონფიგურაციის ყველა დაკისრებული ამოცანა.

ინტერნეტის ეპოქა

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

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

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

მახსოვს დრო, როდესაც ჩვენს კომპანიაში, სადაც მაშინ ვმუშაობდი (სახელს არ დავასახელებ), იმის ნაცვლად, რომ ჭიანჭველა აეშენებინათ (მავენი ჯერ არ იყო პოპულარული ან საერთოდ არ არსებობდა), ხალხი უბრალოდ აგროვებდა ქილებს IDE-ში და მშვიდად ასრულებდა საქმეს. ის SVN-ში. შესაბამისად, განლაგება მოიცავდა ფაილის SVN-დან მოძიებას და SSH-ის საშუალებით სასურველ მანქანაზე გადაწერას. ეს ისეთი მარტივი და მოუხერხებელია.

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

RPM და DEB პაკეტები

მეორეს მხრივ, ინტერნეტის განვითარებასთან ერთად, UNIX-ის მსგავსმა სისტემებმა უფრო და უფრო მეტი პოპულარობის მოპოვება დაიწყეს, კერძოდ, სწორედ ამ დროს აღმოვაჩინე RedHat Linux 6, დაახლოებით 2000 წელს. ბუნებრივია, არსებობდა პროგრამული უზრუნველყოფის მიწოდების გარკვეული საშუალებებიც; ვიკიპედიის თანახმად, RPM, როგორც პაკეტის მთავარი მენეჯერი, გამოჩნდა უკვე 1995 წელს, RedHat Linux 2.0 ვერსიაში. და მას შემდეგ და დღემდე სისტემა მიეწოდება RPM პაკეტების სახით და საკმაოდ წარმატებით არსებობს და ვითარდება.

Debian-ის ოჯახის დისტრიბუციები მსგავს გზას გაჰყვა და განხორციელდა მიწოდება deb პაკეტების სახით, რომელიც დღემდე უცვლელი დარჩა.

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

Cloud Computing-მა დაამატა ინსტალაცია პაკეტის მენეჯერებს არა მხოლოდ ფიზიკური მედიიდან, არამედ ღრუბლოვანი საცავებიდან, მაგრამ ფუნდამენტურად ცოტა რამ შეიცვალა.

აღსანიშნავია, რომ ამჟამად არის გარკვეული ნაბიჯები დებიდან გადასვლისა და სნეპ პაკეტებზე გადასვლისკენ, მაგრამ ამაზე მოგვიანებით.

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

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

შევეცდები გაგიზიაროთ ჩემი გამოცდილება იმის შესახებ, თუ როგორ განვახორციელეთ Docker და რა მოხდა შედეგად.

თვითნაწერი სკრიპტები

თავდაპირველად, იყო bash სკრიპტები, რომლებიც განათავსებდნენ jar არქივებს საჭირო მანქანებზე. ამ პროცესს ჯენკინსი მართავდა. ამან წარმატებით იმუშავა, რადგან თავად ქილის არქივი უკვე არის ასამბლეა, რომელიც შეიცავს კლასებს, რესურსებს და კონფიგურაციასაც კი. თუ მასში ყველაფერს მაქსიმუმს დებთ, მაშინ მისი სკრიპტში გაფართოება არ არის ყველაზე რთული რამ, რაც გჭირდებათ

მაგრამ სკრიპტებს აქვთ რამდენიმე უარყოფითი მხარე:

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

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

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

docker

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

რა უხერხულობა შეგვხვდა?

• ქსელის პრობლემები ხიდის რეჟიმში
• არასასიამოვნოა ჟურნალების ნახვა კონტეინერში (თუ ისინი ცალკე არ არის შენახული მასპინძელი მანქანის ფაილურ სისტემაში)
• ElasticSearch ზოგჯერ უცნაურად იყინება კონტეინერის შიგნით, მიზეზი არ არის დადგენილი, კონტეინერი ოფიციალურია
• აუცილებელია ჭურვის გამოყენება კონტეინერის შიგნით - ყველაფერი ძალიან მოხსნილია, არ არის ჩვეულებრივი ხელსაწყოები
• დიდი ზომის შეგროვებული კონტეინერები - ძვირია შესანახად
• კონტეინერების დიდი ზომის გამო, რთულია მრავალი ვერსიის მხარდაჭერა
• აშენების უფრო გრძელი დრო, სხვა მეთოდებისგან განსხვავებით (სკრიპტები ან დებ პაკეტები)

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

როგორც პრაქტიკამ აჩვენა, სინამდვილეში ეს არ არის აუცილებელი, დებ პაკეტი საკმარისია 90% შემთხვევაში.

როდის იშლება ძველი კარგი დებ და როდის გვჭირდება დოკერი?

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

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

Snap პაკეტები

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

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

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

რას იყენებთ მიწოდებისთვის?

• თვითნაწერი სკრიპტები

• დააკოპირეთ ხელით FTP-ზე

• დებ პაკეტები

• rpm პაკეტები

• ვადამდელი პაკეტები

• დოკერ-გამოსახულებები

• ვირტუალური მანქანის სურათები

• მთელი HDD-ის კლონირება

• მარიონეტული

• პასუხისმგებელი

• სხვა

მისცა ხმა 109 მომხმარებელმა. 32 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com