Valheim-ის სერვერი Docker-ში lloesche/valheim-server-ით

Valheim-ის Docker-ში გაშვების ყველაზე მარტივი გზა საზოგადოების image lloesche/valheim-server-ია (GitHub-ის registry-ში გამოქვეყნებული როგორც ghcr.io/lloesche/valheim-server). ის პირველ გაშვებაზე სერვერს SteamCMD-ით ტვირთავს, უშვებს მას supervisor-ის ქვეშ, რომელიც ასევე ყოველ თხუთმეტ წუთში განახლებებს ამოწმებს და ყოველ საათში დაარქივებულ backup-ს იღებს, და მთლიანად გარემოს ცვლადებით კონფიგურირდება: SERVER_NAME, WORLD_NAME, SERVER_PASS, პლუს SERVER_ARGS ყველაფრისთვის დანარჩენისთვის, მაგალითად -crossplay-ისთვის. აერთებ ორ volume-ს - /config სამყაროებისთვის, backup-ებისა და სიის ფაილებისთვის, /opt/valheim სერვერის ინსტალაციისთვის - ამისამართებ UDP 2456-2457-ს, აძლევ გაჩერებისთვის რამდენიმე წუთიან grace period-ს, და ის კარგად იქცევა. ნაგულისხმევი პარამეტრები vanilla სერვერისთვის გონივრულია; მოდებიანზე ორი უნდა შეცვალო - განახლების განრიგი და, თუ დისკის ადგილი გაინტერესებს, backup-ების შენახვის ვადა.

ეს პოსტი გულისხმობს, რომ მანქანაზე Docker და Compose უკვე მუშაობს. თუ არა, Docker VDS-ზე იქამდე მიგიყვანს. კონტეინერის გარეშე ინსტალაციისთვის იხილე Valheim Linux-ზე SteamCMD-ით.

რატომ უნდა გაუშვა Valheim კონტეინერში საერთოდ#

ნატიური ინსტალაცია systemd unit-ით სავსებით კარგია, ამიტომ კონტეინერმა თავისი ადგილი უნდა დაიმსახუროს. რას გაძლევს ის:

• ჰოსტზე არაფერი დგება Docker-ის გარდა. არც i386 არქიტექტურა, არც SteamCMD-ის პაკეტი, არც ბიბლიოთეკები crossplay-ისთვის. მანქანის თავიდან აწყობა ასე გამოიყურება: „დააყენე Docker, აღადგინე ორი საქაღალდე, docker compose up -d“.
• განახლებები, რესტარტები და backup-ები უკვე დაგეგმილია, უმოქმედობის შემოწმებით, ასე რომ არცერთი მათგანი მოთამაშეებს არ აწყვეტინებს. ნატიურ ინსტალაციაზე ამ ამოცანებს თავად დაწერდი.
• სუფთა გამიჯვნა, როცა იმავე მანქანაზე სხვა რამეებიც მუშაობს - Discord ბოტი, მეორე თამაშის სერვერი, ვებსაიტი. თითოეული საკუთარ კონტეინერში ცხოვრობს, საკუთარი პორტებითა და ფაილებით.

რა ღირს ეს: გამართვის კიდევ ერთი ფენა, ლოგები, რომლებიც supervisor-ის გავლით მოდის და არა პირდაპირ სერვერიდან, და დამოკიდებულება საზოგადოების მიერ მხარდაჭერილ image-ზე. image ფართოდ გამოიყენება და აქტიურად ვითარდება, მაგრამ Iron Gate-ის პროდუქტი არ არის; წაიკითხე მისი README, როცა რამე იცვლება, რადგან მის ცვლადებზე ავტორიტეტი README-ა და არა ეს პოსტი. ქვემოთ მოცემული ცვლადების სახელები და ნაგულისხმევი მნიშვნელობები ისაა, რასაც README წერის მომენტში აღწერს.

compose ფაილი#

docker-compose.yml იმ პარამეტრებით, რომლებსაც მნიშვნელობა აქვს:

services:  valheim:    image: ghcr.io/lloesche/valheim-server    container_name: valheim    cap_add:      - sys_nice    volumes:      - ./config:/config      - ./data:/opt/valheim    ports:      - "2456-2457:2456-2457/udp"    env_file:      - ./valheim.env    restart: unless-stopped    stop_grace_period: 2m

SERVER_NAME=Longship CrewWORLD_NAME=MidgardSERVER_PASS=herring-barrel-42SERVER_PUBLIC=trueTZ=Europe/Berlin

$ mkdir -p ~/valheim && cd ~/valheim$ docker compose up -d$ docker compose logs -f

პირველ გაშვებას რამდენიმე წუთი სჭირდება: კონტეინერი უშვებს SteamCMD-ს, სერვერს ./data-ში ტვირთავს, შემდეგ უშვებს მას და სამყაროს ქმნის. დაელოდე იმავე ლოგის ხაზებს, რომლებსაც ნატიური სერვერი ბეჭდავს - Load world: Midgard და Game server connected - სანამ შეერთებას სცდი.

compose ფაილში სამი ხაზი შენიშვნას იმსახურებს:

• stop_grace_period: 2m სერვერს შესანახად დროს აძლევს. docker compose down-ზე ან docker stop-ზე Docker გაჩერების სიგნალს აგზავნის, supervisor Valheim-ს სუფთა გათიშვას გადასცემს და სამყარო იწერება. Docker-ის ნაგულისხმევი grace period 10 წამია, რის შემდეგაც ის SIGKILL-ს აგზავნის - და დიდი სამყარო, რომელმაც შენახვა ვერ დაასრულა, ბოლო შენახვის შემდეგ ყველაფერს კარგავს. ეს ფაილში ყველაზე მნიშვნელოვანი ხაზია. docker run-ით მისი ეკვივალენტია --stop-timeout 120.
• cap_add: sys_nice სერვერს საკუთარი პროცესის პრიორიტეტის აწევის საშუალებას აძლევს, რასაც README გირჩევს. თუ გამოტოვებ, ზიანი არ არის; დატვირთვისას დაგეგმვის მცირე უპირატესობას კარგავ.
• restart: unless-stopped კონტეინერს გადატვირთვის ან ავარიის შემდეგ აბრუნებს, მაგრამ არა მაშინ, როცა შენ ის განზრახ გააჩერე.

env ფაილი პაროლს compose ფაილის გარეთ ინახავს, ასე რომ compose ფაილის გაზიარება ან commit შეგიძლია მისი გაჟონვის გარეშე. valheim.env მხოლოდ შენთვის იყოს წაკითხვადი.

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

image-ს ათობით ცვლადი აქვს. ეს ის ცვლადებია, რომლებსაც სერვერების უმეტესობა აყენებს ან რომლებიც უნდა იცოდე:

SERVER_ARGS-ში მიდის ყველაფერი, რასაც საკუთარი ცვლადი არ აქვს - crossplay, სამყაროს მოდიფიკატორები, შენახვის უფრო მოკლე ინტერვალი:

SERVER_ARGS=-crossplay -saveinterval 900 -preset casual -modifier portals casual

ნუ გაიმეორებ -name-ს, -world-ს, -password-ს ან -port-ს SERVER_ARGS-ში; image მათ უკვე შესაბამისი ცვლადებიდან აგებს, დუბლიკატები კი დამაბნეველ შედეგებს იძლევა. ყველა არგუმენტი და მისი ხაფანგები Valheim-ის გაშვების არგუმენტების ცნობარშია.

სიის ცვლადები მოსახერხებელია, მაგრამ ბასრი კიდე აქვთ: გაშვებისას image მათ სიის ფაილებში წერს, ასე რომ ID, რომელსაც adminlist.txt-ში ხელით დაამატებ და ADMINLIST_IDS-ში ჩაწერა დაგავიწყდება, შეიძლება შემდეგ რესტარტს ვერ გადაურჩეს. აირჩიე ერთი მეთოდი და მას მიჰყევი. ID-ების ფორმატები, იმ პლატფორმის პრეფიქსების ჩათვლით, რომლებიც crossplay-ს სჭირდება, Valheim-ის სიის ფაილების სახელმძღვანელოშია.

PUID და PGID წყვეტს, ვის ეკუთვნის ფაილები volume-ებში. ნაგულისხმევი 0-ის დროს ისინი ჰოსტზე root-ს ეკუთვნის, რაც მათ SFTP-ით ჩვეულებრივი მომხმარებლით რედაქტირებას მოუხერხებელს ხდის. თუ ჰოსტზე ფაილების რედაქტირებას აპირებ, პირველ გაშვებამდე ორივე შენი მომხმარებლის ID-ებზე დააყენე (id -u და id -g).

Volume-ები: სად ცხოვრობს სამყარო სინამდვილეში#

დასაცავი /config-ია. ის ნატიურ ინსტალაციაზე შენახვის საქაღალდის ეკვივალენტია: სამყაროები /config/worlds_local-ში, image-ის backup-ები /config/backups-ში, სამი სიის ფაილი ზედა დონეზე. /opt/valheim შეიძლება გადაყარო; თუ ის ცარიელია, კონტეინერი შემდეგ გაშვებაზე სერვერს ხელახლა ჩამოტვირთავს. მისი მიერთება მაინც ღირს, რომ კონტეინერის ხელახლა აწყობამ ყოველ ჯერზე ერთი-ორი გიგაბაიტი ხელახლა არ ჩამოტვირთოს.

არსებული სამყაროს შემოსატანად გააჩერე კონტეინერი, დააკოპირე Midgard.db და Midgard.fwl ./config/worlds_local/-ში, დააყენე WORLD_NAME=Midgard - მთავრული ასოების ზუსტი დამთხვევით - და გაუშვი. თუ ლოგი ამბობს, რომ სამყაროს ქმნის და არა ტვირთავს, სახელი არ ემთხვევა. სრული პროცედურა, Steam Cloud-იდან სამყაროების ჩათვლით, ლოკალური Valheim სამყაროს ატვირთვაშია.

/config-ისთვის გამოიყენე bind mount-ები (საქაღალდეები ჰოსტზე) და არა სახელიანი volume-ები. ფაილებს ხედავ, ჩვეულებრივი ხელსაწყოებით აკოპირებ და მათ backup-ს Docker-ის გავლის გარეშე აკეთებ.

განახლებები და რესტარტები განრიგით#

image კონტეინერის შიგნით cron-ის განრიგით განახლების შემოწმებას უშვებს:

როცა შემოწმება ახალ build-ს პოულობს და არავინ თამაშობს, image სერვერს სუფთად აჩერებს, ანახლებს და ისევ უშვებს. vanilla ჯგუფისთვის ეს ზუსტად სწორია: Valheim-ის პატჩის შემდეგ სერვერი ჩვეულებრივ განახლებულია მანამ, სანამ ვინმე საკუთარი თამაშის განახლებას დაასრულებს.

მოდებიანი სერვერისთვის ეს ზუსტად არასწორია. Valheim-ის პატჩი BepInEx მოდებს ამტვრევს, სანამ მათი ავტორები არ განაახლებენ, ხოლო image, რომელიც სერვერის დაცარიელებისთანავე თავს ანახლებს, პატჩის დღის მეორე დილას გაფუჭებულ სერვერს მოგცემს. გამორთე ეს UPDATE_CRON-ის ცარიელ მნიშვნელობაზე დაყენებით და განაახლე შეგნებულად, როცა შენი მოდები მზად არის: გააკეთე backup, შემდეგ docker compose restart - image გაშვებისას განახლებებს ამოწმებს - და გატესტე. Valheim-ის სერვერის განახლება დროს განიხილავს.

ყოველდღიური რესტარტის შენარჩუნება ღირს. დიდხანს მომუშავე სამყარო მეხსიერებაში იზრდება, ხოლო რესტარტი იმ საათზე, როცა არავინ თამაშობს, ამას ბრტყლად ინარჩუნებს. თუ შენი ჯგუფი ადგილობრივი დროით 05:00-ზე თამაშობს, გადაიტანე ის და დარწმუნდი, რომ TZ დაყენებულია, თორემ განრიგი UTC-ით იმუშავებს.

Backup-ები კონტეინერის შიგნით და მის გარეთ#

image საკუთარ backup-ებს იღებს, Valheim-ის ჩაშენებული -backups როტაციისგან ცალკე:

ყოველ საათში, სამი დღით შენახული, გონივრული ნაგულისხმევია: 72 snapshot სამყაროსი, რომელიც შეკუმშული იშვიათად აღემატება 100 MB-ს. backup-ები დისკზე არსებული ფაილებიდან იღება, ასე რომ ისინი სამყაროს ბოლო შენახვის მდგომარეობით შეიცავს და არა თამაშის ბოლო წუთით; უფრო მოკლე -saveinterval SERVER_ARGS-ში მათ უფრო ახალს ხდის.

სუსტი მხარე მდებარეობაა. /config/backups იმავე დისკზე დევს, რომელზეც სამყარო, რომელსაც იცავს. მკვდარი დისკი, წაშლილი საქაღალდე ან გატეხილი ჰოსტი ორივეს წაიღებს. დააკოპირე არქივები მანქანის გარეთ - სხვა სერვერზე, ობიექტურ საცავში rclone-ით ან AWS CLI-ით, სადმე სხვაგან - საკუთარი განრიგით. image გთავაზობს POST_BACKUP_HOOK-ს, ბრძანებას, რომელსაც ის ყოველი არქივის შემდეგ უშვებს და რომელშიც @BACKUP_FILE@-ის ადგილას ფაილის გზა ჩაისმება - ატვირთვის მისაბმელად მოწესრიგებული ადგილი. თამაშის სერვერის backup-ები S3-ზე ატვირთვის მხარეს აჩვენებს, ხოლო Valheim-ის სერვერის backup-ები და სამყაროს დაზიანება აღდგენასა და დაზიანებული სამყაროს ამოცნობას განიხილავს.

აღსადგენად გააჩერე კონტეინერი, გახსენი სასურველი არქივი ./config/worlds_local/-ში მიმდინარე .db და .fwl წყვილის თავზე (ჯერ მიმდინარე წყვილის ასლი შეინახე) და გაუშვი.

BepInEx და მოდები კონტეინერში#

დააყენე BEPINEX=true და image გაშვებისას Valheim-ისთვის BepInExPack-ს ჩამოტვირთავს და სერვერს მისი მეშვეობით უშვებს. მოდების .dll ფაილები შემდეგ plugins საქაღალდეში მიდის /config/bepinex/-ის ქვეშ image-ის მიმდინარე ვერსიებზე - შეამოწმე README ზუსტი გზისთვის, თუ საქაღალდე იქ არ არის, სადაც ელოდები - ხოლო მათი კონფიგურაციის ფაილები /config/bepinex/config-ის ქვეშ ჩნდება ჩატვირთული მოდით პირველი გაშვების შემდეგ. მოდის დამატების ან წაშლის შემდეგ კონტეინერი გადატვირთე.

BEPINEX=trueUPDATE_CRON=

არსებობს VALHEIM_PLUS=true-იც, რომელიც ამის ნაცვლად Valheim Plus-ს აყენებს. თავდაპირველი Valheim Plus პროექტი დიდი ხანია თამაშს ვეღარ ეწევა, და ჯგუფების უმეტესობა ახლა მხარდაჭერილ fork-ებს ან ცალკეულ მოდებს იყენებს; ნუ ჩართავ, თუ არ იცი, რომ ვერსია, რომელსაც მიიღებ, მიმდინარე თამაშთან მუშაობს. არასოდეს ჩართო ორივე.

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

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

კონტეინერი ეშვება, მაგრამ ვერავინ უერთდება. პორტის mapping-ს /udp სჭირდება; "2456-2457:2456-2457" მის გარეშე TCP-ს ამისამართებს და Valheim ვერაფერს იღებს. შემდეგ შეამოწმე ჰოსტის firewall - Docker საკუთარ iptables წესებს ამატებს, მაგრამ ღრუბლოვანი პროვაიდერის firewall-ში UDP 2456-2457 მაინც უნდა იყოს გახსნილი. Valheim-ის პორტების ახსნა სრულ სიას შეიცავს.

სამყარო ყოველ ხელახლა შექმნაზე ნულდება. /config მიერთებული არ არის, ან სხვა საქაღალდეზეა მიერთებული, ვიდრე წინა ჯერზე. docker compose down, რომელსაც up მოსდევს, კონტეინერს ანადგურებს, მაგრამ bind mount-ით მიერთებულ საქაღალდეს არასოდეს.

პროგრესი დაიკარგა `docker compose down`-ის შემდეგ. grace period ძალიან მოკლე იყო და სერვერი შენახვის შუაში მოკლეს. დააყენე stop_grace_period: 2m და შემდეგ გაჩერებაზე ლოგებში თვალი ადევნე შენახვის დასრულებას.

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

`./config`-ის ფაილები root-ს ეკუთვნის. PUID და PGID 0-ზე დარჩა. დააყენე ისინი და არსებულ საქაღალდეებზე ერთხელ chown გაუშვი.

RE:NODE-ზე ყველა სერვერი უკვე საკუთარ კონტეინერში მუშაობს, ასე რომ იმავე იზოლაციას image-ის მხარდაჭერის გარეშე იღებ: გაშვების არგუმენტები Startup ჩანართის ველებია, გაჩერება ყოველთვის სუფთა შენახვაა, backup-ები კი მანქანის გარეთ მიდის და ერთი ღილაკით აღდგება.

FAQ#

lloesche/valheim-server ოფიციალური image-ია?

არა. ეს საზოგადოების პროექტია, რომელიც არც Iron Gate-ს და არც Valve-ს არ გამოუქვეყნებია. ის პოპულარული და მხარდაჭერილია, მაგრამ მის ცვლადებსა და ქცევაზე ერთადერთი ავტორიტეტი მისი README-ა.

როგორ ვნახო crossplay-ის შესვლის კოდი Docker-ში?

დაამატე -crossplay SERVER_ARGS-ში, გადატვირთე და წაიკითხე docker compose logs-იდან. კოდი ყოველ გაშვებაზე იბეჭდება და ყოველ ჯერზე იცვლება.

როგორ გავუშვა ბრძანება სერვერის კონსოლში?

vanilla Valheim-ს სერვერზე არც კონსოლის შეყვანა აქვს და არც RCON. ადმინის ბრძანებებს თამაშში F5-ით კრეფს მოთამაშე, რომელიც adminlist.txt-შია, და ეს კონტეინერშიც ასევე მუშაობს.

შემიძლია ამ image-ით ორი Valheim სერვერი გავუშვა?

კი. გამოიყენე ორი სერვისი სხვადასხვა container_name-ით, ცალკე config და data საქაღალდეებით, სხვადასხვა SERVER_PORT მნიშვნელობებით, ერთმანეთისგან სულ მცირე სამით დაშორებული, და შესაბამისი პორტების mapping-ით. ორივეს შეუძლია ერთ მანქანაზე იცხოვროს, თუ მას საკმარისი მეხსიერება აქვს.

Docker lag-ს ამატებს?

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