Pterodactyl-ის egg-ები თამაშის სერვერებისთვის

Pterodactyl-ის egg ერთი JSON ფაილია, რომელიც პანელს ეუბნება, როგორ დააყენოს, გაუშვას, დააკონფიგურიროს და გააჩეროს ერთი სახის სერვერი. ის ასახელებს Docker image-ებს, რომლებშიც სერვერი შეიძლება მუშაობდეს, ინახავს გაშვების ბრძანებას {{VARIABLES}}-ით, განსაზღვრავს ამ ცვლადებს ნაგულისხმევი მნიშვნელობებითა და ვალიდაციის წესებით, ჩამოთვლის, რომელი კონფიგ ფაილები უნდა გადაიწეროს გაშვებისას, შეიცავს bash-ის ინსტალაციის სკრიპტს, რომელიც ერთხელ ეშვება ერთჯერად კონტეინერში, და ამბობს, ლოგის რომელი ხაზი ნიშნავს "გაეშვა"-ს და რომელი ბრძანება - "გაჩერება"-ს. ყველაფერი, რასაც პანელის Startup ჩანართზე ხედავ, ფორმად გამოსახული egg-ია. როცა იცი, როგორაა ის აწყობილი, ხვდები, რატომ რჩება ზოგი ცვლილება და ზოგი უკან ბრუნდება, რატომ რჩება სერვერი "starting"-ზე სამუდამოდ, და რატომ ინახავს Stop ღილაკი სამყაროს ერთ თამაშში და მეორეში არა.

თუ ჯერ არ წაგიკითხავს, Pterodactyl პანელი - ახსნა აღწერს პანელს, Wings daemon-ს და "ერთი კონტეინერი ერთ სერვერზე" მოდელს. ეს სტატია თავად egg-ს ხსნის.

საიდან მოდის egg-ები#

Pterodactyl-ს egg-ების მცირე ნაკრები მოყვება - Minecraft-ის ვარიანტები, რამდენიმე Source-ის თამაში, Rust, ერთი-ორი ხმოვანი სერვერი - nest-ებად დაჯგუფებული. გამოყენებაში მყოფი თითქმის ყველა სხვა თამაშის egg საზოგადოებრივი კოლექციიდან მოდის GitHub-ზე, რომელიც წლების განმავლობაში parkervcp/eggs-ის ქვეშ ინახებოდა და ახლა pelican-eggs ორგანიზაციის ქვეშაა, თითო საქაღალდით თითო თამაშზე. ჰოსტინგები მათ იმპორტს უკეთებენ, ცვლიან ან საკუთარს წერენ.

egg ექსპორტდება და იმპორტდება JSON-ად ფორმატში, რომელსაც პანელი PTDL_v2-ს უწოდებს. Pelican-ს, Pterodactyl-ის fork-ს, ფორმატის საკუთარი რედაქცია აქვს და Pterodactyl-ის egg-ების უმეტესობის იმპორტი შეუძლია. წყაროს მიუხედავად, egg-ის ინსტალაციის სკრიპტი იმპორტამდე წაიკითხე: ის ქსელზე წვდომით ეშვება და სერვერის ფაილებში წერს, და egg ისეთივე კოდია, რომელიც შენ არ დაგიწერია, როგორც plugin.

egg-ის აგებულება#

მნიშვნელოვან ნაწილებამდე შემოკლებული Minecraft-ის სტილის egg ასე გამოიყურება:

{  "meta": { "version": "PTDL_v2", "update_url": null },  "name": "Paper",  "features": ["eula", "java_version"],  "docker_images": {    "Java 21": "ghcr.io/pterodactyl/yolks:java_21",    "Java 17": "ghcr.io/pterodactyl/yolks:java_17"  },  "file_denylist": [],  "startup": "java -Xms128M -Xmx{{SERVER_MEMORY}}M -jar {{SERVER_JARFILE}}",  "config": {    "files": "{\"server.properties\":{\"parser\":\"properties\",\"find\":{\"server-ip\":\"0.0.0.0\",\"server-port\":\"{{server.build.default.port}}\"}}}",    "startup": "{\"done\":\")! For help, type \"}",    "logs": "{}",    "stop": "stop"  },  "scripts": {    "installation": {      "container": "ghcr.io/pterodactyl/installers:alpine",      "entrypoint": "ash",      "script": "#!/bin/ash\ncd /mnt/server\n..."    }  },  "variables": [    {      "name": "Server Jar File",      "env_variable": "SERVER_JARFILE",      "default_value": "server.jar",      "user_viewable": true,      "user_editable": true,      "rules": "required|regex:/^([\\w\\d._-]+)(\\.jar)$/",      "field_type": "text"    }  ]}

config-ის მნიშვნელობები JSON-ად არის კოდირებული სტრიქონების შიგნით, ამიტომაა ისინი escape-ირებული ბრჭყალებით სავსე. ეს მახინჯია და ხელით ადვილად ფუჭდება; არედაქტირე პანელის ადმინის ინტერფეისში ან სიფრთხილით.

Docker image-ები: runtime და არა თამაში#

image ის გარემოა, რომელშიც თამაში მუშაობს: ოპერაციული სისტემის ბიბლიოთეკები, Java-ს, .NET-ის ან Wine-ის ვერსია და entrypoint სკრიპტი. თამაშს ის არ შეიცავს. თამაშის ფაილები სერვერის volume-ზე ცხოვრობს, რომელიც /home/container-ზეა მიმაგრებული, და image-ის ცვლილებებს გადაურჩება.

image-ები, რომლებსაც egg-ების უმეტესობა იყენებს, "yolks" image-ებია: ghcr.io/pterodactyl/yolks ოფიციალური ნაკრებისთვის და ghcr.io/parkervcp/yolks და ghcr.io/parkervcp/steamcmd საზოგადოებრივისთვის. tag-ები runtime-ს ასახელებს - java_21, debian, dotnet_8, Wine-ის tag-ები მხოლოდ Windows-ის თამაშებისთვის და ა.შ. tag-ების სახელები და შიგთავსი დროთა განმავლობაში იცვლება, ამიტომ რეპოზიტორია შეამოწმე და tag ძველი egg-იდან ნუ დააკოპირებ.

ყოველი yolks image ერთსა და იმავე სქემას მიჰყვება. კონტეინერი მუშაობს არაპრივილეგირებული მომხმარებლით, სახელად container, იწყებს /home/container-ში და უშვებს entrypoint-ს, რომელიც იღებს STARTUP გარემოს ცვლადს, {{VAR}}-ს ${VAR}-ად გარდაქმნის და შეასრულებს:

cd /home/containerMODIFIED_STARTUP=$(echo -e ${STARTUP} | sed -e 's/{{/${/g' -e 's/}}/}/g')echo ":/home/container$ ${MODIFIED_STARTUP}"eval ${MODIFIED_STARTUP}

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

არასწორი image-ის არჩევა ხშირი ჩავარდნაა. Minecraft-ის ვერსია, რომელსაც Java 21 სჭირდება, Java 17-ის image-ში გაშვებული UnsupportedClassVersionError-ით ვარდება; ვერსიების ცხრილი მოცემულია სტატიაში Minecraft-ის JVM flag-ები და Java-ს ვერსიები.

გაშვების ხაზი და ცვლადები#

startup ველი შაბლონია. ზოგ მნიშვნელობას Wings თავად აწვდის, სერვერის build-იდან:

ყველაფერი დანარჩენი egg-ის variables მასივიდან მოდის, და ყოველი ცვლადი კონტეინერის შიგნით გარემოს ცვლადად იქცევა და გაშვების ხაზშიც ჩაისმება. ამიტომ შეიძლება ცვლადის ორივე ადგილას გამოყენება: startup-ში როგორც {{MAX_PLAYERS}}, ხოლო shell სკრიპტში ან თავად თამაშში როგორც $MAX_PLAYERS.

თითოეულ ცვლადს აქვს:

• env_variable - სახელი, რომელიც გაშვების ხაზსა და გარემოში გამოიყენება.
• default_value - რას იღებს ახალი სერვერი.
• user_viewable და user_editable - ხედავს თუ არა მას კლიენტი Startup ჩანართზე და შეუძლია თუ არა შეცვლა. ჰოსტინგები მალავენ ცვლადებს, რომლებიც მათ საკუთარ საიდუმლოებებს ინახავს, და ბლოკავენ მათ, რომლებიც გეგმას გააფუჭებდა, მაგალითად მეხსიერების გადაფარვას.
• rules - Laravel-ის ვალიდაციის წესები, იგივე სინტაქსი, რომელსაც პანელი ყველგან იყენებს: required|string|max:32, nullable|string, required|integer|between:1,100, required|in:true,false, regex:/.../. მნიშვნელობა, რომელიც წესს ვერ აკმაყოფილებს, ველის შენახვისას უარყოფილია.

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

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

კონფიგის parser-ები: რატომ ბრუნდება ზოგი ცვლილება#

config.files ეუბნება Wings-ს, რომ ყოველ გაშვებამდე გახსნას კონკრეტული ფაილები და დააყენოს კონკრეტული გასაღებები. parser არის ერთ-ერთი: properties, ini, json, yaml, xml ან file (უბრალო ტექსტი, ხაზის პრეფიქსით დამთხვევა), ხოლო find ჩამოთვლის გასაღებებს და ძალით დასაყენებელ მნიშვნელობებს.

ჩვეულებრივი გამოყენება პორტები და მისამართებია. ზემოთ მოცემული Minecraft-ის egg ძალით აყენებს server-port-ს {{server.build.default.port}}-ზე - სერვერის ძირითად allocation-ზე - და server-ip-ს 0.0.0.0-ზე, ასე რომ თამაში ყოველთვის იქ ებმება, სადაც პანელი ამბობს. proxy-ის egg-ები ჩადგმულ YAML გასაღებებს წერტილებიანი გზით აყენებენ, მაგალითად listeners[0].host. სხვა egg-ები query პორტებს, RCON პორტებს ან მოთამაშეების მაქსიმალურ რაოდენობას ცვლადებიდან აყენებენ.

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

ინსტალაციის სკრიპტი#

ინსტალაცია გაშვებისგან ცალკე კონტეინერია. როცა სერვერი იქმნება ან თავიდან ყენდება, Wings:

1. ჩამოტვირთავს scripts.installation.container-ში დასახელებულ image-ს (ინსტალერის image curl-ით, jq-ით, git-ით, unzip-ით და მსგავსი ხელსაწყოებით).
2. სერვერის volume-ს /mnt/server-ზე მიამაგრებს.
3. egg-ის ცვლადებს გარემოს ცვლადებად გადასცემს.
4. სკრიპტს დასახელებული entrypoint-ით უშვებს (bash ან ash).
5. კონტეინერს აგდებს, და მხოლოდ ამის შემდეგ აძლევს სერვერს თავის runtime image-ში გაშვების უფლებას.

ტიპური SteamCMD-ზე დაფუძნებული ინსტალაციის სკრიპტი SteamCMD-ს /mnt/server/steamcmd-ში ჩამოტვირთავს, app_update-ს egg-ის app ID-ისა და ბრენჩის ცვლადებით უშვებს, Steam-ის კლიენტის ბიბლიოთეკებს, რომლებსაც თამაში ელის, .steam/sdk64-ში ან .steam/sdk32-ში აკოპირებს და ნაგულისხმევ კონფიგს წერს, თუ არცერთი არ არსებობს. Minecraft-ის სკრიპტი ვერსიების API-ს იძახებს და jar-ს ჩამოტვირთავს. SteamCMD-ის ნახევრის დეტალები მოცემულია სტატიაში SteamCMD app ID-ები და beta ბრენჩები.

ინსტალაციის სკრიპტების ორ თვისებას აქვს მნიშვნელობა კლიენტებისთვის:

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

გაშვების ამოცნობა და გაჩერების ბრძანება#

config.startup.done სტრიქონია (ან სტრიქონების სია), რომელსაც Wings კონსოლში ადევნებს თვალს. როცა ის ჩნდება, სერვერის მდგომარეობა "starting"-იდან "running"-ზე იცვლება. Minecraft-ისთვის ეს )! For help, type -ია, რაც შეესაბამება ხაზს, რომელსაც Paper ბეჭდავს ჩატვირთვის დასრულებისას. Valheim-ისთვის ეს ჩვეულებრივ ხაზია იმის შესახებ, რომ თამაშის სერვერი დაკავშირდა. თუ თამაშის გამონატანი განახლებისას შეიცვლება და ეს ტექსტი აღარ იქნება, სერვერი იდეალურად მუშაობს, მაგრამ პანელი სამუდამოდ "starting"-ს აჩვენებს. მოთამაშეებისთვის ეს მხოლოდ ვიზუალურია, განრიგებისთვის კი, რომლებიც running მდგომარეობას ელოდებიან, გამაღიზიანებელი.

config.stop ისაა, როგორ სთხოვს Wings გაჩერებას. ეს ან კონსოლის ბრძანებაა, რომელიც სერვერის input-ში იწერება - stop Minecraft-ისთვის, quit Source-ის თამაშებისთვის - ან ^C, რომელიც პროცესს SIGINT-ს უგზავნის. თუ სერვერი Wings-ის timeout-ის განმავლობაში არ დასრულდება, kill-ს მიიღებს.

სწორედ აქ იგება ან იკარგება სამყაროები. egg, რომლის გაჩერების ბრძანება save-სა და სუფთა გასვლას იწვევს, გაძლევს უსაფრთხო Stop და Restart ღილაკს. egg, რომელიც ^C-ს უგზავნის თამაშს, რომელიც მას იგნორირებს ან ამ სიგნალზე შენახვის გარეშე გამოდის, გაძლევს ღილაკს, რომელიც kill-ივით იქცევა. ერთხელ შეამოწმე ნებისმიერ თამაშზე, რომელიც შენთვის მნიშვნელოვანია: რამე შეცვალე, გააჩერე, გაუშვი, შეამოწმე. სტატია Restart-ის განრიგები, რომლებიც შველის ხსნის, რატომ აქვს ამ განსხვავებას მნიშვნელობა, ხოლო თამაშის სერვერის autosave-ის ინტერვალები - როგორ შეზღუდო ზიანი, როცა გაჩერება სუფთა არ არის.

საკუთარი egg-ის დაწერა ან შეცვლა#

თუ საკუთარ პანელს მართავ და გინდა egg თამაშისთვის, რომელიც არავის შეუფუთავს:

1. დაიწყე ყველაზე ახლო არსებული egg-იდან. მსგავსი engine-ის SteamCMD თამაშის egg გზის 80 პროცენტს გაგატარებს.
2. ჯერ ინსტალაცია ხელით აამუშავე. ინსტალერის image ლოკალურად Docker-ით გაუშვი, ცარიელი საქაღალდე /mnt/server-ზე მიამაგრე და შენი სკრიპტი უშვი, სანამ მომუშავე ინსტალაციას არ მოგცემს.
3. გაშვების ხაზი runtime image-ში აამუშავე. იგივე image, იგივე საქაღალდე /home/container-ზე მიმაგრებული, ბრძანება რეალური მნიშვნელობებით გაუშვი.
4. დაამატე ცვლადები ყველაფრისთვის, რაც მომხმარებელმა უნდა შეცვალოს, წესებით, რომლებიც ცუდ მნიშვნელობებს უარყოფს.
5. კონფიგის parser-ები დაამატე მხოლოდ იმ გასაღებებისთვის, რომლებიც პანელს უნდა ეკუთვნოდეს - პორტები, bind მისამართი. ყველაფერი დანარჩენი მომხმარებლის რედაქტირებისთვის უნდა იყოს.
6. დააყენე done სტრიქონი, რომელიც ყოველ წარმატებულ გაშვებაზე ჩნდება, და გაჩერების ბრძანება, რომლის შესახებაც შემოწმებით იცი, რომ სამყაროს ინახავს.

ჰოსტინგის პანელზე egg-ების იმპორტი ჩვეულებრივ არ შეგიძლია; მათ ჰოსტინგი ინახავს. RE:NODE-ზე egg-ებს ჰოსტინგის მხარე ინახავს, მათი ცვლადები კი Startup ჩანართზე ჩანს, გარემოს ცვლადებთან ერთად, ხოლო პორტები Network ჩანართზეა. ადმინის, RCON-ისა და მონაცემთა ბაზის პაროლები ინსტალაციისას თითოეული სერვერისთვის გენერირდება, Minecraft Paper-ზე ეშვება შესაბამისი Java-ს ვერსიით და მიღებული EULA-თი, ხოლო თამაშები, რომლებსაც შენი საკუთარი Steam login ან ლიცენზიის გასაღები სჭირდებათ, Setup ჩანართზე ელოდებიან, სანამ მას არ მიუთითებ. თუ გჭირდება stack, რომელსაც არცერთი egg არ ფარავს, გამოყოფილი სერვერი მთელ მანქანას გაძლევს.

egg-ების პრობლემების მოგვარება#

სერვერი სამუდამოდ "starting"-ს აჩვენებს, მაგრამ მოთამაშეებს შესვლა შეუძლიათ. done სტრიქონი თამაშის გამონატანს აღარ ემთხვევა. ვიზუალურია, მაგრამ ჰოსტინგს უთხარი ან egg გაასწორე.

კონფიგ ფაილში პარამეტრი გამუდმებით ბრუნდება. ეს გასაღები egg-ის კონფიგის parser-ს ეკუთვნის. შეცვალე Startup ან Network ჩანართზე.

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

`exec format error` ან `not found` ბინარზე, რომელიც აშკარად იქაა. image თამაშს არ ემთხვევა: 64-ბიტიანი ბინარი image-ში, რომელსაც მისი ბიბლიოთეკები აკლია, ან Windows-ის .exe, გაშვებული Wine-ის გარეშე.

კონსოლის პირველი ხაზი ცარიელ მნიშვნელობას აჩვენებს. ცვლადი ცარიელია. Startup ჩანართზე მოძებნე სავალდებულო ველი ნაგულისხმევის გარეშე.

FAQ#

რა არის egg Pterodactyl-ში?

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

რა განსხვავებაა nest-სა და egg-ს შორის?

nest egg-ების ჯგუფია, მაგალითად Minecraft-ის ყველა ვარიანტი ან Source-ის ყველა თამაში. egg თავად განსაზღვრებაა. nest-ები ორგანიზაციულია და არაფერს ცვლის იმაში, როგორ მუშაობს სერვერი.

რატომ სჭირდება ზოგჯერ Startup ცვლადის შეცვლას ხელახალი ინსტალაცია?

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

შემიძლია საზოგადოებრივი რეპოზიტორიის egg-ები ნებისმიერ პანელზე გამოვიყენო?

პანელზე, რომელსაც შენ მართავ, კი - JSON-ის იმპორტი ადმინის ზონაში გააკეთე. ჰოსტინგის პანელზე egg-ების თავად დამატება ჩვეულებრივ არ შეგიძლია. ნებისმიერი egg-ის ინსტალაციის სკრიპტი იმპორტამდე შეამოწმე, რადგან ის ქსელზე წვდომით ეშვება.

Docker image-ის შეცვლა ჩემს ფაილებს შლის?

არა. image მხოლოდ runtime-ია. სერვერის ფაილები /home/container-ზე მიმაგრებულ volume-ზე ცხოვრობს და ადგილზე რჩება; იცვლება მხოლოდ მათ გარშემო არსებული ბიბლიოთეკები და ხელსაწყოები.