როდესაც დადგა აპლიკაციის განლაგების დრო, მე ვცადე AWS, მაგრამ გულწრფელად რომ ვთქვა, მე ვიყავი შეწუხებული იმ ინფორმაციისა და სერვისების რაოდენობით, რომელსაც ისინი აწვდიან, და ძალიან მინდოდა ჩემი აპლიკაციის ნახვა ველურში. ასე რომ, ვერსელს წავაწყდი. გარდა ამისა, მე ვისწავლე დოკერის შესახებ და მინდოდა გამომეყენებინა ის, რაც აქამდე ვისწავლე, ეს იყო სწორი შესაძლებლობა. Vercel კარგად არის ცნობილი მათი ნულოვანი კონფიგურაციის განლაგებით. მხოლოდ რამდენიმე დაწკაპუნებით შეგიძლიათ განათავსოთ თქვენი აპლიკაცია. თქვენ ასევე შეგიძლიათ დააკავშიროთ თქვენი საცავი და Vercel მყისიერად აშენებს და განათავსებს თქვენს პროექტს ყოველი ჩაბარების შემდეგ. ამაზე უფრო მოსახერხებელი ვერ იქნება 😀 . კიდევ ერთი მიზეზი, რის გამოც Vercel ავირჩიე AWS-ზე, იყო მათი „უსერვერო“ ფუნქცია, რომელიც მე გამოვიყენე დოკუმენტების გადმოსაცემად ჩემი მონაცემთა ბაზიდან Express API-ის მეშვეობით. მართალი გითხრათ, მათ სამსახურს ვერ ვუჩივი. მე არასდროს მქონია პრობლემა ჩემს პროექტთან დაკავშირებით. აქ საქმე ის არის, რომ მინდოდა მეტი გამეგო ჩემი აპლიკაციის უკანა ნაწილის შესახებ და მივხვდი, რომ მისი განლაგების გაგება დამეხმარებოდა ამაში. მე მინახავს ბევრი ადამიანი, ვინც ირჩევს AWS-ს Vercel-ის ნაცვლად მათი ფასების გეგმის გამო. ეს არ ეხება ჩემს შემთხვევას, რადგან ჩემს აპლიკაციას არ აქვს ამდენი ტრეფიკი და მას ძირითადად სასწავლო მიზნებისთვის ვიყენებ. მაგრამ კარგია აღვნიშნო, რომ Vercel-ს აქვს ესკალაციის „საკითხი“, როდესაც საქმე ფასს ეხება. Toronto Food Basket-ის აპლიკაცია შეიძლება დაიყოს სამ სხვადასხვა ნაწილად: Webscraper ადგილობრივი სასურსათო მაღაზიიდან ინფორმაციის შეგროვებისთვის Express API, რომელიც აწესრიგებს ინფორმაციას და შეუძლია შეასრულოს მათემატიკური ოპერაციები ამისათვის. React აპლიკაცია, რომელიც ასახავს აპლიკაციას და ყველა საჭირო ინფორმაციას. ამ დროისთვის მე მხოლოდ ვაყენებ Webscraper-ს AWS-ზე, რადგან ჯერ კიდევ მჭირდება ვისწავლო მეტი სერვერებისა და მარშრუტების შესახებ Express API-სა და React აპის განსათავსებლად. დასაწყისისთვის, მე გავუშვი AWS EC2 ინსტანცია და დავაყენე ბიუჯეტის მაღვიძარა, ასე რომ ნებისმიერ დროს, როცა ჩემს ეგზემპლარზე დახარჯული 0,01$-ზე მეტია, მე მივიღებ შეტყობინებას - გავიგე, რომ რთული გზა იყო DocumentDB მაგალითზე დარიცხვის შემდეგ, რაც ჩემს ანგარიშზე დეკემბრიდან გაშვებული მქონდა. /2023 და წარმოდგენა არ მქონდა 😂. Amazon გთავაზობთ უფასო დონეებს 750 საათის t2.micro (ან t3.micro რეგიონებში, სადაც t2.micro მიუწვდომელია), 30 გიბ EBS საცავი, 2 მილიონი IO, 1 GB სნეპშოტი და 100 GB გამტარუნარიანობა ინტერნეტში. როდესაც ვისწავლე, თუ როგორ უნდა განვათავსო ჩემი დოკერირებული აპლიკაცია AWS-ზე, მივხვდი, რომ სულ მცირე ორი განსხვავებული მიდგომა არსებობს - შეიძლება იყოს მეტი: შექმენით დოკერის კონტეინერი ადგილობრივად და გაგზავნეთ მხოლოდ კონტეინერი AWS-ში. გააგზავნე ყველაფერი AWS-ში და ავაშენე ჩემი კონტეინერი დისტანციურად. მე ავირჩიე მეორე მიდგომა, რადგან მსურდა მქონოდა ჩემს აპლიკაციაზე სრულიად დისტანციურად მუშაობის გამოცდილება, საჭიროების შემთხვევაში. მე ყოველთვის არ ვმუშაობ საკუთარ კომპიუტერზე და EC2 ინსტანციაზე ჩემი აპლიკაციის მიღება ნამდვილად მოსახერხებელი იქნება ამ სიტუაციებში. ასევე, მე იძულებული ვიქნებოდი ვიმუშაო Vim-თან, რაც მე მინდოდა გამეკეთებინა. სანამ ფაილებს ჩემს EC2 ინსტანციაზე გავაგზავნიდი, მე მოვამზადე ჩემი დისტანციური გარემო Node.js და Docker-ის დაყენებით. ფაილების ჩემს EC2 ინსტანციაზე გასაგზავნად მე გამოვიყენე უსაფრთხო ასლის პროტოკოლი (scp). ბრძანება ასე გამოიყურებოდა: scp -i ubuntu.pem -r LOCAL_DIRECTORY ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws : ეს დროშა განსაზღვრავს პირადობის ფაილს (პირადი გასაღები), რომელიც გამოიყენება საჯარო გასაღების ავთენტიფიკაციისთვის. ამ შემთხვევაში, არის პირადი გასაღების ფაილი, რომელიც გამოიყენება დისტანციურ სერვერზე ავთენტიფიკაციისთვის. -i ubuntu.pem ubuntu.pem : ეს დროშა მიუთითებს, რომ ოპერაცია უნდა იყოს რეკურსიული, რაც ნიშნავს, რომ ის დააკოპირებს დირექტორიებსა და მათ შინაარსს რეკურსიულად. -r : ეს არის დანიშნულების სპეციფიკაცია. იგი შეიცავს მომხმარებლის სახელს ( ) და IP მისამართს ( ) დისტანციური სერვერის, რასაც მოჰყვება დირექტორია გზა ( ), სადაც მოხდება ფაილების კოპირება. ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws ubuntu 35.183.21.127 /home/ubuntu/downloads მას შემდეგ რაც ყველა ფაილი გადავიდა ჩემს EC2 ინსტანციაზე, მე შევძელი ჩემი დოკერის კონტეინერის აგება. და აი, შეცდომები დაიწყო - ჰოი! ჩემი Webscraper-ის ყველაზე მნიშვნელოვანი ბიბლიოთეკაა Puppeteer, რომელიც უზრუნველყოფს მაღალი დონის API-ს Chrome/Chromium-ის სამართავად DevTools Protocol-ზე. Puppeteer მუშაობს უთავო რეჟიმში, რაც აჩქარებს მის შესრულებას. მაგრამ როდესაც ვცდილობდი ჩემი განაცხადის დოკერიზაციას, მე წავაწყდი რამდენიმე პრობლემას: ნაგულისხმევად, როდესაც Puppeteer დაინსტალირებულია, ის ჩამოტვირთავს Chrome-ს ტესტირებისთვის და chrome-headless-shell ბინარს. ბრაუზერი ჩამოტვირთულია $HOME/.cache/puppeteer საქაღალდეში. პრობლემა ის არის, რომ AWS არ შეიცავს $HOME/.cache-ს Ubuntu-ის ინსტანციაში. მე გავარკვიე ეს საკითხი გარკვეული გამოკვლევის შემდეგ, და გადასაჭრელად ყველაფერი რაც უნდა გამეკეთებინა იყო /.cache საქაღალდის root დირექტორიაში გადატანა - ეს საკითხი კარგად არის დოკუმენტირებული Puppeteers-ის npm პორტალზე. ერთი აშკარა რამ, რაც ვერ მივხვდი, იყო ის, რომ აქამდე ჩემს აპლიკაციას ვატარებდი OS-ში, როგორიცაა Windows და MacO. მაგრამ ახლა საქმე მქონდა Ubuntu-სთან. და რადგან ეს ცარიელი ინსტანცია იყო, მას არ ჰქონდა წინასწარ დაინსტალირებული პაკეტი/აპი, ამიტომ დავაყენე კვანძი და დოკერი, როგორც კი პირველად გავუშვი ეგზემპლარი. მაგრამ დამავიწყდა მართლაც მნიშვნელოვანი აპლიკაცია ჩემი Webscraper-ისთვის: Google Chrome. გახსოვს ადრე რა ვთქვი თოჯინების შესახებ? ისე, მე უნდა დავრწმუნებულიყავი, რომ მქონდა Chromium-ის სწორი ვერსია ჩემს ეგზემპლარზე. Node.js-ის ყველა ძირითადი ვერსია აგებულია Debian-ის ვერსიაზე და ეს Debian ვერსია მოყვება Chromium-ის ძველ ვერსიას, რომელიც ზოგჯერ არ არის თავსებადი Puppeteer-ის უახლეს ვერსიასთან. გარკვეული გამოკვლევის შემდეგ აღმოვაჩინე, რომ მომიწია ინსტრუქციის ჩასმა ჩემს Dockerfile-ში, რათა Chromium-ის სწორი ვერსია ჩამოიტვირთოს მანამ, სანამ Docker დააინსტალირებს ჩემი აპის ყველა დამოკიდებულებას და გაუშვებს მას. ჩემი Docker ფაილი ასე გამოიყურებოდა: წინა პრობლემის გადაჭრის შემდეგ კიდევ ერთი გაჩნდა. ახლა შეცდომის შეტყობინება ამბობს: "გამოყენებული ქვიშის ყუთი არ არის". ამის გამოსასწორებლად, რაც უნდა გამეკეთებინა, იყო ჩემი კოდის შეცვლა და შემემატა –no-sandbox არგუმენტი puppeteer.launch() ფუნქციაზე თითოეული ჩემი სასურსათო პროდუქტისთვის. შესრულებულია. ახლა ჩემი Webscraper მუშაობს კონტეინერში ჩემს AWS EC2 მაგალითზე. თუმცა ის არ ასუფთავებს 65-ვე პროდუქტს. მეხუთე პროდუქტის შემდეგ აპლიკაცია იშლება. მე მჯერა, რომ ეს დაკავშირებულია ხელმისაწვდომ რესურსებთან, რაც მე მაქვს ამ მაგალითზე - მე იგივე პრობლემის წინაშე ვდგებოდი, როდესაც სკრაპერი გიტჰუბის მოქმედებებით ვმართავდი. ყოველ შემთხვევაში, ჩემი მიზანი იყო AWS EC2 ინსტანციის გაშვება და ჩემი აპლიკაციის დისტანციურად გაშვება და ეს გავაკეთე. წინ ბევრი!
