თამაშის სერვერის განახლებების უსაფრთხო ავტომატიზაცია

ავტომატური განახლებები vanilla სერვერებზე ჩართე, mod-ებიანზე კი ხელით აკეთე. vanilla Steam-ის თამაშის სერვერს შეუძლია უსაფრთხოდ განახლდეს ყოველ restart-ზე, რადგან სერვერი კლიენტებს უნდა ემთხვეოდეს, კლიენტები კი თავს ანახლებენ იმ წამსვე, როგორც კი patch გამოვა; სერვერის ჩამორჩენა უბრალოდ ყველას გარეთ ტოვებს. mod-ებიანი სერვერი საპირისპირო შემთხვევაა: თამაშის patch ხშირად ამტვრევს mod-ებს, დილის ოთხ საათზე ავტომატური განახლება კი ნიშნავს სერვერს, რომელიც არ ჩაირთვება, როცა ხალხი სამსახურის შემდეგ მოვა. ამ ორს შორის დეტალებია - როდის გაუშვა validate, როგორ დაგეგმო განახლება, რომ სესიის შუაში არ მოხვდეს, როგორ გაიგო, რომ ის წარმატებით დასრულდა - და სწორედ ამას ეძღვნება პოსტის დანარჩენი ნაწილი.

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

რატომ სჭირდება თამაშის სერვერებს განახლება საერთოდ#

გამოყოფილ სერვერზე ზუსტად იგივე ვერსია უნდა მუშაობდეს, რაც მასთან დაკავშირებულ კლიენტებზე. Steam-ის თამაშების უმეტესობაში ეს იძულებითია: კლიენტი დაკავშირებისას თავის build-ის ნომერს აგზავნის და სერვერი ყველაფერ სხვას უარყოფს, ჩვეულებრივ ისეთი გამოუსადეგარი შეტყობინებით, როგორიცაა "Incompatible version" ან "Server is running a different version". როცა დეველოპერი patch-ს გამოუშვებს, ყველა მოთამაშის Steam კლიენტი მას რამდენიმე საათში ჩამოტვირთავს, და ამ მომენტიდან ძველ სერვერზე შესვლა შეუძლებელია.

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

• Minecraft Java არაფერს ანახლებს ავტომატურად, და მოთამაშეები კლიენტის ვერსიას launcher-ში ირჩევენ. 1.21.1-ზე მომუშავე სერვერზე 1.21.1 კლიენტები განუსაზღვრელი დროით შეძლებენ შესვლას, ხოლო ViaVersion-ის მსგავსი plugin-ები ახალ კლიენტებს ძველ სერვერთან დაკავშირების საშუალებას აძლევს.
• Factorio მოთამაშეებს საშუალებას აძლევს Steam-ის betas ჩანართში ძველი ვერსია აირჩიონ და განახლებას არავის აიძულებს, ამიტომ სერვერი შეიძლება ვერსიაზე დარჩეს იმდენ ხანს, რამდენსაც ჯგუფი შეთანხმდება.
• FiveM სერვერის build-ს ("artifact") თამაშისგან გამოყოფს. კლიენტები უკავშირდება იმას, რაც სერვერზე მუშაობს, იმ build-ების დიაპაზონში, რომელსაც პლატფორმა ჯერ კიდევ მხარს უჭერს.
• Terraria-ს კლიენტები Steam-ით ახლდება, მაგრამ გამოყოფილი სერვერი ცალკე ჩამოსატვირთია, ამიტომ ახალი ვიღაცამ ხელით უნდა მოიტანოს.

ყველაფერ დანარჩენს - Valheim, Rust, Palworld, Project Zomboid, 7 Days to Die, Counter-Strike 2, Unturned, Satisfactory, DayZ, Arma 3 - სჭირდება, რომ სერვერი კლიენტების იმავე build-ზე იყოს, და ერთდღიანი დაყოვნება ნიშნავს დღეს, როცა ვერავინ შედის.

განახლება restart-ისას: ნაგულისხმევი ვარიანტი vanilla სერვერებისთვის#

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

#!/bin/shset -e/home/steam/steamcmd/steamcmd.sh +force_install_dir /srv/valheim \    +login anonymous +app_update 896660 +quitcd /srv/valheimexec ./valheim_server.x86_64 -nographics -batchmode \    -name "Longship Crew" -port 2456 -world "Midgard" -password "$PASS"

Pterodactyl-ზე აგებულ პანელზე Steam-ის თამაშების egg-ების უმეტესობა იმავე ქცევას startup ცვლადის სახით გთავაზობს - ჩვეულებრივ ეს არის გადამრთველი, რომელსაც auto-update-ის მსგავსი სახელი აქვს - და SteamCMD-ს ყოველი ჩართვის წინ უშვებს. სახელი და ნაგულისხმევი მნიშვნელობა egg-ებს შორის განსხვავდება, ამიტომ ვარაუდის ნაცვლად შენს სერვერზე Startup ჩანართი შეამოწმე.

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

მისი სისუსტე ის არის, რომ უპირობოა. ის ისევე ადვილად ეშვება ავარიის შემდეგ restart-ზე დღის სამ საათზე, როგორც დაგეგმილზე დილის ხუთზე, ამიტომ შუადღეს გამოსული patch გამოიყენება მაშინ, როცა სერვერი შემდეგ ჯერზე გაჩერდება - რაც შეიძლება raid-ის შუაში მოხდეს. vanilla სერვერების უმეტესობისთვის ეს ნორმალურია, რადგან ალტერნატივა ისედაც სერვერია, რომელზეც ვერავინ შედის.

როდის არ უნდა განაახლო ავტომატურად#

ავტომატური განახლებები გამორთე, თუ რომელიმე ამათგანი მართალია:

1. სერვერზე მუშაობს mod-ები ან plugin-ები, რომლებიც თამაშის კოდში ერევა. BepInEx Valheim-ზე, Oxide ან Carbon Rust-ზე, UE4SS Palworld-ზე, Harmony mod-ები 7 Days to Die-სა და Rimworld-ზე, DayZ-ის სკრიპტ mod-ები, Unturned-ის RocketMod. ისინი თამაშის საკუთარ კოდს გაშვების დროს ცვლიან, თამაშის patch კი სწორედ იმ კოდს ამოძრავებს, რასაც ისინი ცვლიან. mod-ი ან ვერ ჩაიტვირთება, ან, უარესი, ჩაიტვირთება და რაღაცას დააზიანებს.
2. სერვერი მიზანმიმართულად ფიქსირებულ ან beta branch-ზეა. ავტომატური განახლება არასწორი branch-ის არგუმენტით public-ზე დაგაბრუნებს.
3. განახლებით სამყაროს ფორმატი იცვლება. დიდი განახლებები ზოგჯერ save-ს პირველი ჩატვირთვისას გარდაქმნის. გარდაქმნის შემდეგ ის ძველ ვერსიაში იშვიათად იტვირთება. გინდა, რომ ამის მოხდენამდე ერთი წუთით ადრე ხელით აღებული backup გქონდეს.
4. მიმდინარეობს შეჯიბრებითი ღონისძიება. ტურნირის შაბათ-კვირა არ არის დრო იმის აღმოსაჩენად, რომ patch-მა cvar-ის ნაგულისხმევი მნიშვნელობა შეცვალა.

ამ სერვერებისთვის პროცედურა არის ის, რაც აღწერილია სტატიაში განახლების დღის ჩამონათვალი: წაიკითხე patch notes, დაელოდე mod-ების ავტორებს, აიღე ჩაკეტილი backup, ჯერ საცდელი ასლი განაახლე და მერე რეალური სერვერი.

Validate: რას ასწორებს და რატომ არ უნდა გაუშვა ყოველ ჯერზე#

validate აიძულებს SteamCMD-ს, ინსტალაციის ყველა ფაილის hash დაითვალოს და ჩაანაცვლოს ყველაფერი, რაც გამოქვეყნებულ manifest-ს არ ემთხვევა. ეს სწორი ინსტრუმენტია შემდეგ შემთხვევებში:

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

ყოველ restart-ზე კი ის არასწორი ინსტრუმენტია, ორი მიზეზით. დიდ ინსტალაციაზე - Arma 3, DayZ და Rust თავიანთი კონტენტით ათეულობით გიგაბაიტს აღწევს - ყველაფრის hash-ის დათვლა მთელ ინსტალაციას დისკიდან კითხულობს და ყოველ ჩართვას წუთებს შეიძლება დაუმატოს. და validate აბრუნებს ნებისმიერ ფაილს, რომელიც აპლიკაციას მოჰყვა და შენ შეცვალე: გაშვების სკრიპტს, ნაგულისხმევ კონფიგ ფაილს ინსტალაციის საქაღალდეში, შეცვლილ .json-ს, რომელიც თამაშს მოჰყვება და შენ მოარგე. შენი ცვლილება ჩუმად ორიგინალით ჩანაცვლდება.

მომუშავე ნიმუში არის უბრალო განახლება ყოველ restart-ზე, validate კი მხოლოდ მაშინ, როცა რაღაც არასწორადაა:

app_update 896660            # normal: changed files onlyapp_update 896660 validate   # repair: hash and replace everything

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

განახლების დაგეგმვა ისე, რომ სესიის შუაში არ მოხვდეს#

აქტიური საზოგადოებისთვის უკეთესი ნიმუშია, რომ განახლებები შენ მიერ არჩეულ დროს ხდებოდეს. RE:NODE-ზე ეს ნიშნავს Schedules ჩანართს: cron-ის გამოსახულება და დავალებების დალაგებული სია დაყოვნებებით - კონსოლის ბრძანება, backup, კვების მოქმედება. vanilla სერვერისთვის, რომელსაც განახლება restart-ისას ჩართული აქვს, ღამის განახლება და restart ასე გამოიყურება:

Cron     0 5 * * *Task 1   command  say Restarting for updates in 5 minutes      (delay 0)Task 2   command  say Restarting in 1 minute                   (delay 240 s)Task 3   command  save                                         (delay 60 s)Task 4   backup                                                (delay 30 s)Task 5   power    restart                                      (delay 60 s)

restart განახლებას იწვევს, მის წინ აღებული backup ნიშნავს, რომ ცუდი patch-ის გაუქმება შესაძლებელია, გაფრთხილებები კი ნიშნავს, რომ არავინ გაუკვირდება. ჩასვი შენი თამაშის შესაბამისი შენახვისა და შეტყობინების ბრძანებები; დაგეგმილი დავალებები, რომლებიც ღირს მათ ჩამოთვლის, ხოლო cron-ის გამოსახულებების ახსნა cron-ის სინტაქსსა და დროის სარტყლებს განიხილავს.

დატვირთულ სერვერზე ორი დახვეწის დამატება ღირს:

• restart-მდე შეამოწმე. თუ საკუთარ მანქანას მართავ, შეადარე დაინსტალირებული build უახლესს და გამოტოვე restart, როცა ემთხვევა. დაინსტალირებული build არის steamapps/appmanifest_<appid>.acf-ში, როგორც "buildid"; უახლესს ბეჭდავს +app_info_update 1 +app_info_print <appid>, branches-ის და შემდეგ public-ის ქვეშ. app_info_print-ის გამოტანის ფორმატი სტაბილური ინტერფეისი არ არის, ამიტომ სკრიპტი, რომელიც მას აანალიზებს, SteamCMD-ის ყოველი განახლების შემდეგ შესამოწმებლად ჩათვალე.
• ნუ ეომები restart-ის პოლიტიკას. განრიგი, რომელიც ყოველ ღამე აკეთებს restart-ს, და plugin, რომელიც ასევე ტაიმერით გადატვირთავს სერვერს, ადრე თუ გვიან ერთმანეთს გადაფარავს. ერთი აირჩიე.

როგორ გაიგო, რომ განახლება წარმატებით დასრულდა#

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

1. SteamCMD-ის წარმატების ხაზი. დასრულებული განახლება ბეჭდავს Success! App '<appid>' fully installed.. შეცდომები, როგორიცაა Error! App '<appid>' state is 0x202 after update job. (ჩვეულებრივ დისკის ადგილი) ან 0x6 / 0x602 (გაჭედილი ჩამოტვირთვა), ნიშნავს, რომ არ დასრულდა. თუ განახლებებს სკრიპტით აკეთებ, ეძებე წარმატების ხაზი და ნუ ენდობი გასვლის კოდს, რომელიც ყოველთვის საიმედო არ ყოფილა.
2. თამაშის საკუთარი ვერსიის ხაზი. თითქმის ყველა სერვერი თავის ვერსიას გაშვების ლოგის დასაწყისში ბეჭდავს. Valheim ბეჭდავს Valheim version: ხაზს, Minecraft ბეჭდავს Starting minecraft server version, Source-ის თამაშები version-ის საპასუხოდ build-ის ნომერს ბეჭდავს. განახლების შემდეგ შეამოწმე, რომ შეიცვალა.
3. ერთი რეალური შესვლა. კლიენტის შესვლა ერთადერთი შემოწმებაა, რომელიც ამტკიცებს, რომ კლიენტი და სერვერი ერთმანეთს ეთანხმება.

$ grep -E "Success! App|Error! App" steamcmd-update.logSuccess! App '896660' fully installed.

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

თამაშები, რომლებიც SteamCMD-ს არ იყენებენ#

საკმაოდ ბევრ პოპულარულ სერვერს საკუთარი განახლების გზა აქვს, და SteamCMD-ის განახლება restart-ისას მათთვის არაფერს აკეთებს.

Minecraft-ისთვის Paper-ის build-ის განახლება იმავე Minecraft-ის ვერსიის ფარგლებში ჩვეულებრივ შეცდომის გასწორებაა და განრიგით გამოყენება უსაფრთხოა - თუმცა დროდადრო build ცვლის ქცევას, რომელსაც plugin-ები ეყრდნობა. Minecraft-ის ვერსიებს შორის გადასვლა, მაგალითად 1.21.4-დან 1.21.5-ზე, სამყაროს პირველი ჩატვირთვისას გარდაქმნის და შენი plugin-ების ნახევარი შეიძლება გატეხოს. ეს ყოველთვის ხელით, backup-ით შესასრულებელი ოპერაციაა, აღწერილი სტატიაში Minecraft-ის ვერსიის განახლებები. FiveM-ისთვის უსაფრთხო განახლების გზა მოცემულია სტატიაში FiveM სერვერის განახლებები და artifact-ები.

Workshop-ის კონტენტიც ახლდება#

Steam Workshop-ის mod-ები საკუთარი განრიგით ახლდება, თამაშისგან დამოუკიდებლად, და სერვერი, რომელიც Workshop-ის ელემენტებს ჩართვისას ჩამოტვირთავს, mod-ის ახალ ვერსიას შემდეგ restart-ზე აიღებს, გინდოდა თუ არა. ეს იმავე პრობლემის უფრო ჩუმი ვერსიაა: mod-ის ავტორი ცვლილებას გამოუშვებს, სერვერი ღამით გადაიტვირთება, დილით კი სერვერი ჩატვირთვისას ავარიულად ითიშება, ან კლიენტები ვერ უკავშირდებიან, რადგან მათი mod-ის ასლი ჯერ არ განახლებულა.

სხვადასხვა თამაში ამას სხვადასხვანაირად უმკლავდება. Project Zomboid Workshop-ის ელემენტებს მოთამაშის შესვლისას ამოწმებს და აგდებს მოთამაშეებს, რომელთა ვერსიებიც განსხვავდება; Garry's Mod, Arma 3 და DayZ Workshop-ის კონტენტს SteamCMD-ით ან თამაშის საკუთარი loader-ით იღებს. ზოგადი დაცვა იგივეა, რაც თამაშისთვის: საღამოს განახლების ფანჯარა, მის წინ backup და საცდელი სერვერი ყველაფრისთვის, რასაც გრძელი mod-ების სია აქვს. Steam Workshop-ის mod-ები გამოყოფილ სერვერებზე აღწერს, როგორ იღებს თითოეული თამაში კონტენტს და სად ინახავს cache-ს.

გონივრული პოლიტიკა, სერვერის ტიპის მიხედვით#

ყველაფერი ერთად:

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

FAQ#

ჩავრთო auto-update ჩემს თამაშის სერვერზე?

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

ანელებს თუ არა განახლება restart-ისას ყოველ restart-ს?

მხოლოდ ოდნავ, როცა არაფერი შეცვლილა - SteamCMD manifest-ებს ადარებს და გამოდის. ნელი validate-ია, რადგან ყველა ფაილს კითხულობს. რუტინული ჩართვებისთვის validate გამორთული დატოვე.

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

ან განახლება ჩავარდა და სერვერი ძველ build-ზე ჩაირთო, ან სერვერი და კლიენტები სხვადასხვა branch-ზე არიან. შეამოწმე ვერსიის ხაზი გაშვების ლოგში, შემდეგ კი ნახე, ხომ არ არის beta branch დაყენებული ერთ მხარეს და არა მეორეზე.

შემიძლია განახლება გადავდო, სანამ mod-ები მზად იქნება?

მხოლოდ იმ თამაშებში, რომლებიც ამის საშუალებას იძლევა. Steam-ის თამაშები კლიენტებს ახალ build-ზე აიძულებს, ამიტომ სერვერის დაყოვნება ნიშნავს, რომ ვერავინ შევა. ზოგიერთი გამომცემელი წინა ვერსიას beta branch-ად ინახავს, რაც საშუალებას გაძლევს ცოტა ხნით კიდევ ამუშაო ის იმ მოთამაშეებთან ერთად, რომლებიც საკუთარ კლიენტს იმავე branch-ზე გადართავენ.

რა ხდება, თუ სერვერი გადაიტვირთება, სანამ განახლება იტვირთება?

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