სტატიკური საიტები ხელახალი გამოქვეყნებისას აქტიურად რჩება

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

როგორ მიეწოდება სტატიკური საიტი

სტატიკური საიტი არის ფაილებით შედგენილი საიტი: HTML გვერდები, JavaScript, CSS, სურათები. როცა Mythex-ზე ასეთს აქვეყნებთ, ჩვენ ვაგებთ, შედეგს ობიექტურ საცავში ვატვირთავთ თქვენი საიტის საქაღალდეში და ედჟ ქსელით ვემსახურებით — სერვერებით, რომლებიც თქვენს ვიზიტორებთან ახლოს არიან, საცავიდან ფაილებს იღებენ და გარკვეხნის ასლებს ინახავენ. (თუ ეს თქვენთვის ახალია, ჩვენი გზამკვლევი რა არის CDN იდეას ხსნის.)

ორი რამ იყო არასწორად: რიგი, რომლითაც ხელახალი გამოქვეყნება ფაილებს ცვლიდა, და რამდენ ხანს ინახებოდა ძველი ასლები.

პრობლემა 1: ატვირთვა საიტს ჯერ ცარიელს ხდიდა

ხელახალი გამოქვეყნება ჯერ თქვენი საიტის საქაღალდის ყველაფერს შლიდა, შემდეგ ატვირთავდა ახალ ბილდს. ატვირთვის მთელ დროს — ჩვენს ლოკალურ ტესტში 250-ფაილიანი საიტისთვის 12 წამი — ვიზიტორი, რომლის მოთხოვნაც ედჟზე ჯერ არ იყო ქეშირებული, 404-ს იღებდა, ან HTML გვერდს, რომლის სკრიპტებიც 404-ს აბრუნებდა.

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

გამოსწორება: ზემოდან ვწერთ, გვერდები ბოლოს, ნაშთები მოგვიანებით

1. ჯერ არ შლით. ახალი ბილდი ძველზე იტვირთება.
2. აქტივები გვერდებამდე. გვერდი ასახელებს იმ სკრიპტებსა და სტილებს, რაც სჭირდება, ამიტომ გვერდები ბოლოს ავა. სანამ ახალი გვერდები არ ავა, ვიზიტორი ძველ გვერდს იღებს, რომელიც ძველ აქტივებს ასახელებს, ისინი კი კვლავ იქ არის. როცა ახალი გვერდები ავა, მათ მიერ დასახელებული ახალი აქტივები უკვე ადგილზეა.
3. ნაშთები მოგვიანებით წაიშლება. ატვირთვამდე ვიღებთ სიას, რისგანაც საიტი შედგება. წარმატებული ატვირთვიდან სამი წუთის შემდეგ ამ სიიდან ყველაფერი, რაც ახალმა ბილდმა არ გადაწერა, იშლება. სამი წუთი უფრო გრძელია, ვიდრე 60 წამი, რომელზეც გვერდი ედჟზე და ბრაუზერში შეიძლება იყოს ქეშირებული, ამიტომ ძველ გვერდს დაჩერებულმა ვიზიტორმა შეიძლება მაინც იპოვოს აქტივები, რომლებსაც ის ასახელებს.
4. ეჭვის შემთხვევაში არაფერს შლით. თუ ატვირთვამდე სიის აღება ვერ მოხერხდა, ნაშთი არ წაიშლება. ზედმეტი ფაილები უვნებელია, შემდეგი გამოქვეყნება კი მათ გაასუფთავებს. რაც არ იცით, რა იყო, იმის წაშლა არის ის, რაც საიტს ცარიელს ტოვებს.

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

ჩვენ ეს ბოლომდე ლოკალურად ვატესტეთ: რეალური ატვირთვის სკრიპტით, რეალური ატვირთვის მარშრუტითა და საცავის მომსახურებით, ცივილი ედჟ ქეშით შემოსულ ვიზიტორებთან. ძველი კოდით 91-დან 55 ვიზიტი დაზიანდა ხელახალი გამოქვეყნებისას, ხოლო 92-დან 61 — წარუმატებლისას. ახალი კოდით 0 დაზიანდა დაახლოებით 3500 ვიზიტზე, რომლებიც მოიცავდა ორივე ატვირთვის გზას, წარუმატებელ ატვირთვას და მის შემდგომ გამოქვეყნებას — და წაიშალა სწორედ ის ნაშთი ფაილები, რაც უნდა წაშლილიყო.

პრობლემა 2: ხელახალი გამოქვეყნება ჩანდა ძალიან ნელა

მაშინაც კი, როცა ატვირთვა კარგად წავიდა, ცვლილებები ნელა ჩანდა. ედჟი თავის ასლს გვერდისთვის 60 წამს ინახავდა, ყველა სხვა ფაილისთვის კი — დღეს, და იგივეს ეუბნებოდა ბრაუზერებსაც. ფიქსირებული სახელის ფაილებს — logo.png, შრიფტი, რაიმე public/ საქაღალდიდან — ხელახალი გამოქვეყნების შემდეგ დღის განმავლობაში შეეძლო ძველი ვერსია ეჩვენებინა.

გამოსწორება: ფაილების ასლები ბილდის ქვეშ

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

ბრაუზერები ორ სხვადასხვა წესს იღებენ:

• ჰეშირებული ბილდის გამოსავალი — ფაილები, როგორიცაა assets/index-CzLcxDO8.js, რომელთა სახელიც იცვლება, როცა შიგთავსი იცვლება — ერთი წლით ქეშდება და იმუტაბელად აღინიშნება. ასეთი სახელით ის არასდროს შეიძლება იყოს მოძველებული.
• ყველაფერი დანარჩენი — გვერდები და ფიქსირებული სახელის ფაილები, როგორიცაა ლოგო — აღინიშნება no-cache-ით, რაც ნიშნავს „შეამოწმე გამოყენებამდე“. თუ არაფერი შეცვლილა, პასუხი არის პატარა 304 Not Modified უსხეულოდ, რადგან ახლა ვპატივს ვცემთ ბრაუზერის If-None-Match შემოწმებას.

ამ ორის ერთმანეთისგან გარჩევას სიფრთხილე უნდა: public/assets/-იდან კოპირებული ფაილი თავის სახელს ინარჩუნებს, და assets/logo.png-ის ერთი წლით ქეშირება ძველ ლოგოს ერთი წლით დააფიქსირებდა. ამიტომ ფაილი ჰეშირებულად ითვლება მხოლოდ მაშინ, თუ ის ბილდის გამოსავლის საქაღალდეშია და მის სახელში არის ჰეშის მსგავსი სეგმენტი, და არა ჩვეულებრივი სიტყვა.

ლოკალურად, ახალი გვერდი და ლოგო 6 წამის შემდეგ ჩანდა გამოქვეყნების მერე. წინათ ეს იყო 60 წამი გვერდისთვის და დღე ლოგოსთვის.

ორი პატარა გასწორება გზად

• ცარიელი გვერდები HEAD მოთხოვნებიდან. HEAD მოთხოვნა გვერდის ჰედერებს ითხოვს სხეულის გარეშე. ამ ცარიელ პასუხებს ვინახავდით, ამიტომ მომდევნო ვიზიტორი ცარიელ გვერდს ხედავდა. HEAD პასუხები ახლა აღარ ქეშირდება.
• რეალური გვერდი „აქ არაფერია“-სთვის. მისამართი აპის გარეშე ადრე ჩვეულებრივ ტექსტს აბრუნებდა — „ეს გამოქვეყნებული აპი გათიშულია ან ბმული ვერ მოიძებნა“ — 502 კოდით. ახლა მას სათანადო გვერდი ეძლევა, „აქ აპი არ არის“, 404 სტატუსითა და გზით მეპატრონისთვის უკან Mythex-ზე. უცნობი ხელით დადებული დომენებიც იგივე გვერდს იღებენ.

რა ვისწავლეთ

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

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