Pterodactyl პანელი ახსნილი: Wings, egg-ები და კონტეინერები

Pterodactyl არის ღია კოდის სამართავი პანელი გეიმ სერვერებისთვის, და ის ერთი პროგრამა კი არა, ორია. პანელი არის ვებ აპლიკაცია, რომელმაც იცის, ვინ ხარ, რომელი სერვერები გაქვს და რისი გაკეთების უფლება გაქვს. Wings არის პატარა daemon, რომელიც ყოველ ფიზიკურ მანქანაზე მუშაობს, Docker-თან ლაპარაკობს და ერთადერთი ნაწილია, რომელიც შენს ფაილებს ეხება. შენი სერვერი არის Docker კონტეინერი, რომელსაც Wings უშვებს მეხსიერების ლიმიტით, CPU წილით, დისკის კვოტით და ერთი-ორი მიბმული პორტით. თითქმის ყველა ბრაუზერული გეიმ ჰოსტი, რომელიც გიყენებია, ეს არის, სხვა ლოგოთი.

ამის ცოდნა წვრილმანი არ არის. ის განმარტავს, რატომ გაქვს console და არა shell, როგორ იქცევა მეხსიერების ლიმიტები, რატომ არის file manager მყისიერი, ახალი პროგრამის დაყენება კი შეუძლებელი, და რატომ არასოდეს ასწორებს ჩაკეცილ გეიმ სერვერს "პანელის გადატვირთვა". ეს პოსტი არის მექანიზმი ზემოდან ქვემოთ, პლუს პატიოსანი სია იმისა, რასაც ეს მოწყობა ვერ აკეთებს.

ორი პროგრამა, ორი ამოცანა#

პანელი არის Laravel აპლიკაცია React front end-ით. ის საკუთარ database-ში ინახავს ანგარიშებს, სერვერებს, უფლებებს, allocation-ებს, განრიგებს და audit ჩანაწერებს. ის ხატავს ყოველ გვერდს, რომელსაც უყურებ. რაც მას არ აქვს, არის შენი სამყაროს ფაილი, შენი ლოგები და შენი პროცესი - პანელმა არ იცის, რა არის შენს სერვერში, მხოლოდ ის იცის, რასაც Wings ეუბნება.

Wings არის პატარა Go daemon, რომელიც ყოველ node-ზე დგას. ის Docker socket-თან ლაპარაკობს, ქმნის და ანადგურებს კონტეინერებს, ახორციელებს ლიმიტებს, console-ის გამოტანას სტრიმავს, SFTP-ს ემსახურება და backup-ებს ქმნის. ის ნაგულისხმევად 8080 პორტზე უსმენს და SFTP-ს 2022-ზე ემსახურება, მისი კონფიგურაცია კი ერთი ფაილია /etc/pterodactyl/config.yml-ზე, რომელიც შეიცავს token-ს, რომლითაც ის პანელთან ავთენტიფიცირდება.

წყვეტილი ხაზი შენი ბრაუზერიდან Wings-მდე ყურადღების ღირსია. როცა console-ს ხსნი, პანელი ბრაუზერს მოკლევადიან token-ს აძლევს და ბრაუზერი შემდეგ websocket-ს პირდაპირ Wings-თან ხსნის. Console-ის გამოტანა პანელის გავლით არ გადის. ამიტომ შეიძლება console მყისიერად ჩანდეს, გვერდის ჩატვირთვა კი ჩვეულებრივად, და ამიტომ ნიშნავს console, რომელიც აღარ ახლდება, ჩვეულებრივ node-ს და არა ვებსაიტს.

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

ერთი სერვერი არის ერთი Docker კონტეინერი#

ყოველი სერვერი იღებს კონტეინერს, რომელიც აგებულია მისი egg-ის მიერ არჩეული image-იდან, და node-ზე დირექტორიას, რომელიც მასში bind-mount-ითაა მიმაგრებული. node-ზე ეს დირექტორია არის /var/lib/pterodactyl/volumes/<uuid>; კონტეინერის შიგნით ის არის /home/container, და ეს არის სამუშაო დირექტორია, სადაც თამაში იწყება. ყველაფერი, რასაც file manager-ში ხედავ, ეს ერთი დირექტორიაა.

რასაც ეს გაძლევს და რასაც გიღირს, ერთი და იგივეა:

• იზოლაცია. სერვერი, რომელიც დისკს ავსებს, CPU-ს ავსებს ან მეხსიერების გამო კვდება, მეზობელს ვერ შეეხება. ცალკე ფაილური სისტემა, ცალკე პროცესების namespace, ცალკე ლიმიტები.
• root-ის გარეშე და მუდმივი სისტემის გარეშე. შენ ხარ არა-root მომხმარებელი კონტეინერში, რომელიც სერვერის ყოველ გაშვებაზე იგდება და image-იდან თავიდან შენდება. ყველაფერი, რასაც package manager-ით დააყენებ, შემდეგ გაშვებაზე გაქრებოდა, რომც შეგეძლოს მისი გაშვება. ფაილები /home/container-ის ქვეშ გადარჩება; სხვა არაფერი.
• image წყვეტს, რა არსებობს. თუ image-ს Java 21 აქვს და შენს modpack-ს Java 8 სჭირდება, image-ს egg-ის ან იმ ცვლადის შეცვლით ცვლი, რომელიც მას ირჩევს, და არა Java-ს დაყენებით.

Image-ები საჯარო registry-ებიდან მოდის - პროექტი აქვეყნებს ნაკრებს ghcr.io/pterodactyl/yolks მისამართზე, runtime-ის მიხედვით ტეგირებულს, ამიტომ Minecraft egg შეიძლება yolks:java_21-ზე მუშაობდეს, Node.js აპლიკაცია კი yolks:nodejs_22-ზე. ჰოსტი image-ს ირჩევს; მომხმარებლის ანგარიშზე ჩვეულებრივ ვერსიას არჩევ dropdown-იდან Startup ჩანართზე და image-ის სახელს არ კრეფ.

Egg-ები: როგორ იცის პანელმა თამაშის დაყენება#

Egg არის JSON ფაილი, რომელიც აღწერს ყველაფერს, რაც ერთი ტიპის სერვერის გასაშვებად არის საჭირო. upstream-ში ისინი nest-ებადაა დაჯგუფებული, რაც უბრალოდ თემატური საქაღალდეა. ერთი egg შეიცავს:

ინსტალაცია გაშვებისგან ცალკე ნაბიჯია. სერვერის შექმნისას Wings დროებით კონტეინერს უშვებს, ცარიელ სერვერის დირექტორიას /mnt/server-ზე ამაგრებს, install script-ს უშვებს - ჩვეულებრივ SteamCMD ან ჩამოტვირთვა და unzip - და შემდეგ ამ კონტეინერს აგდებს. მხოლოდ ამის შემდეგ იწყება ნამდვილი კონტეინერი. სწორედ ამიტომ ზის ახალი სერვერი installing ეკრანზე და ამიტომ არის მისი console ცარიელი ინსტალაციის დასრულებამდე.

Startup command იყენებს ჩანაცვლებებს, რომლებსაც პანელი ავსებს:

java -Xms128M -Xmx{{SERVER_MEMORY}}M -jar {{SERVER_JARFILE}} nogui

{{SERVER_MEMORY}}, {{SERVER_IP}} და {{SERVER_PORT}} გეგმიდან და allocation-იდან მოდის; ორმაგ ფრჩხილებში ყველაფერი სხვა არის ცვლადი, რომელსაც egg აცხადებს, ზუსტად ის, რასაც Startup ჩანართი გაჩვენებს. შეცვალე jar ფაილის სახელი ამ ველში და გაშვების ხაზი იცვლება.

Config parser არის ნაწილი, რომელსაც ხალხი არასოდეს ხედავს და ხშირად ებმევა. Egg-ს შეიძლება ეთქვას, რომ server.properties ყოველ გაშვებაზე გადაწეროს, რომ server-port allocation-ს ემთხვეოდეს. თუ გასაღებს შეცვლი, რომელსაც egg ფლობს, შენი ცვლილება შემდეგ გაშვებაზე გადაიწერება და ჩანს, თითქოს ფაილი თავისით დაბრუნდა. გამოსწორება ისაა, რომ შეცვალო იქ, სადაც პანელი ელოდება - Startup ან Network ჩანართზე - და არა ფაილში.

ჩანართები და რას აკეთებს თითოეული სინამდვილეში#

• Console. websocket Wings-თან, რომელიც პროცესის standard output-ს ატარებს, პლუს ბრძანების ხაზი, რომელიც მის standard input-ში წერს. ეს თამაშის საკუთარი console-ია, გაუფილტრავი, სწორედ ამიტომ არის სასარგებლო შეცდომა ყოველთვის მასში. console-ის კითხვა ეხება, რას უნდა დააკვირდე.
• Files. HTTP ფაილის API Wings-ზე, volume-ით შემოსაზღვრული. ატვირთვები, რედაქტორი, არქივები ადგილზე გახსნილი. დიდი ოპერაციები SFTP-ით ჯობს: SFTP და file manager.
• Databases. პანელი ქმნის database-ს და მომხმარებელს database ჰოსტზე, რომელსაც თავად მართავს, აგენერირებს პაროლს და გაჩვენებს კავშირის დეტალებს. ის არასოდეს მუშაობს შენს კონტეინერში.
• Schedules. cron გამოსახულება, პანელში შენახული, დალაგებული ამოცანებით - console ბრძანება, backup, power ქმედება - თითოეული დაყოვნებით. პანელის საკუთარი scheduler ამუშავებს მათ და Wings-ს ეძახის. cron გამოსახულებები ახსნილი ეხება ხუთ ველს.
• Backups. Wings volume-ს tar-ავს და არქივს ინახავს. აღდგენა volume-ის შიგთავსს ანაცვლებს. backup ფაილებისაა და არა მეხსიერებისა, ამიტომ თამაში, რომელსაც ცოტა ხნის წინ არ შეუნახავს, ძველი სამყაროს backup-ს იძლევა - ჯერ ყოველთვის გააგზავნე save ბრძანება.
• Network. IP და პორტის წყვილები, რომლებიც ამ სერვერზეა გამოყოფილი. ძირითადი არის ის, რასაც თამაში უკავშირდება; დამატებითი - query პორტებისთვის, RCON-ისთვის, web რუკისთვის ან მეორე სერვისისთვის. გეიმ სერვერის პორტები ახსნილი ხსნის, რომელი გჭირდება.
• Startup. egg-ის ცვლადები, ფორმად გამოსახული.
• Users. subuser-ები უფლებების მიხედვით მინიჭებით, რითაც მოდერატორს console-ს აძლევ ბილინგისა და წაშლის ღილაკის გარეშე.

RE:NODE-ის პანელი არის ჩვენი საკუთარი კოდი Pterodactyl-ისა და Wings-ის თავზე და არა სტანდარტული ინსტალაცია, ამიტომ ზოგი აქ განზრახ სხვანაირად იქცევა. Console-ის გამოტანა გაუფილტრავია ისტორიითა და tab-ით შევსებით, და არის ცოცხალი გრაფიკები მეხსიერების, CPU-სა და დისკისთვის, რომლებიც ლიმიტების მიმართ იხატება და არა node-ის მიმართ. SFTP credential-ები არის თითო სერვერზე და არა თითო ანგარიშზე, რაც მნიშვნელოვანია იმ წუთს, როცა ერთ სერვერზე წვდომას ისეთ ადამიანს აძლევ, ვისაც დანარჩენები არ უნდა ჰქონდეს. Database სლოტებს აქვთ "open in phpMyAdmin" ღილაკი, რომელიც ერთჯერადი token-ით შედის და სამოცი წამის შემდეგ ვადა უსრულდება. წვდომის კონტროლი არის როლები, გუნდები და grant-ები და არა ბრტყელი subuser სია, დროით შეზღუდული წვდომითა და თითო სერვერზე activity ლოგით - subuser-ები და მინიმალური პრივილეგიები და ადამიანებისა და უფლებების გზამკვლევი პრაქტიკულ ვერსიას შეიცავს.

ლიმიტები და რა ხდება, როცა მათ აღწევ#

სამი ლიმიტი დგება თითო სერვერზე და მას kernel ახორციელებს Docker-ის მეშვეობით და არა თამაში.

მეხსიერება არის ის, რომელიც მხარდაჭერის ტიკეტებს წარმოშობს. კონტეინერი ლიმიტზე kernel-ის მიერ ჩერდება და არა ნელდება, და თამაშს შენახვის შანსი არ ეძლევა. სტანდარტული Pterodactyl ნაგულისხმევად OOM killer-ს გამორთულს ტოვებს, რაც კონტეინერს swap-ში გადასვლისა და ნელა მუშაობის საშუალებას აძლევს; RE:NODE განზრახ საპირისპიროს აკეთებს, ამიტომ სერვერი ლიმიტზე ჩერდება და სუფთად გადაიტვირთება და არა ითრგუნება. ორივე არჩევანი დასაცავია და ისინი სხვადასხვანაირად ფუჭდებიან: ჩვენი გიჯდება იმას, რაც შეუნახავი იყო, მათი - ყველას ერთ საათს იმ სერვერზე, რომელიც ტექნიკურად პასუხობს. ყოველ შემთხვევაში, გამოსწორება იგივეა - შეამცირე save-ის ინტერვალი ან იყიდე მეხსიერება, რომელიც თამაშს რეალურად უნდა. Node-ის მეხსიერების ლიმიტები ახსნილი შეიცავს ამის Java-ს მხარეს, სადაც სიურპრიზების უმეტესობაა.

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

კონტეინერის ლიმიტების თავზე არის crash watcher: ის ყოველ ორ წუთში ამოწმებს სერვერს, რომლის uptime უკან წავიდა ან რომელიც თავისით გამოირთო. გადატვირთვები, რომლებიც შენ მოითხოვე, არ ითვლება. ერთ საათში სამი მოულოდნელი გადატვირთვა სერვერის გვერდზე გაფრთხილებას აყენებს და ტიკეტს ხსნის; ექვსი აჩერებს მას, რადგან სერვერი, რომელიც გაშვებისას crash-loop-ში ზის, node-ის CPU-ს არავისთვის წვავს. რატომ იტვირთება შენი გეიმ სერვერი განუწყვეტლივ არის დიაგნოზის გზამკვლევი.

რას ვერ აკეთებს პანელი განზრახ#

ეს პატიოსანი სიაა და ის მიზეზია, რის გამოც ზოგმა პანელი საერთოდ არ უნდა გამოიყენოს.

• root-ისა და shell-ის გარეშე. console არის თამაშის stdin და არა bash. apt-ს, htop-ს, tcpdump-ს ან სკრიპტს, რომელსაც daemon-ად ყოფნა სჭირდება, ვერ გაუშვებ.
• ერთი სერვერი, ერთი თამაში. კონტეინერი egg-ის startup command-ს უშვებს. მის გვერდით მეორე პროცესის გაშვება არ არის ის, რასაც დიზაინი უჭერს მხარს; მეორე თამაში მეორე სერვერია.
• სისტემური სერვისების გარეშე. არავითარი systemd, არავითარი cron კონტეინერის შიგნით, არავითარი საკუთარი firewall წესები. პირველ ორს პანელის Schedules ჩანართი ანაცვლებს; მესამე ჰოსტისაა.
• თვითნებური პროგრამის გარეშე. თუ შენს mod-ს native ბიბლიოთეკა სჭირდება, რომელიც image-ში არ არის, პასუხია სხვა image, რაც უმეტეს ჰოსტთან ნიშნავს სხვა egg-ს, ანუ თხოვნას.
• პორტები არის პორტები. ღებულობ allocation-ებს, რომლებსაც შენი გეგმა ასახელებს, და მათი დამატება ან წაშლა შეგიძლია Network ჩანართზე გეგმის ფარგლებში. ვერ დააბამ ვერაფერს, სადმე.

თუ ამათგან ერთზე მეტი დაბრკოლებაა, შენ გჭირდება მანქანა და არა კონტეინერი - VDS-სა და გეიმ პანელს შორის არჩევა პირდაპირი შედარებაა, ხოლო რა არის dedicated გეიმ სერვერი აღწერს მისი გაშვების სამ გზას.

საკუთარი Pterodactyl-ის გაშვება ან ქირაობა იმისგან, ვინც უშვებს#

Pterodactyl უფასოა და შეგიძლია დააყენო. ინსტალაცია თავად ერთი შუადღეა: ვებ სერვერი, PHP, database, queue worker, Wings, Docker, სერტიფიკატი. ოფიციალური დოკუმენტაცია კარგია და აქტუალური.

რასაც ამის შემდეგ იღებ თავზე, ის ნაწილია, რომელსაც არავინ ითვლის. შენ გეკუთვნის OS patch-ები, Docker-ის განახლებები, პანელის განახლებები და მათი მიგრაციები, სერტიფიკატის განახლება, backup-ის საცავი, რომელიც იმავე დისკზე არ არის, firewall და node-ის ხელმისაწვდომობა დილის სამ საათზე. ასევე შენ გეკუთვნის abuse-ის პრობლემა იმ წუთიდან, როცა შენს გარდა ვინმეს ანგარიში აქვს. ერთი ადამიანისთვის, რომელიც სამ სერვერს ერთ ყუთზე უშვებს, ეს მართლაც გონივრული შაბათ-კვირის პროექტია და რამდენიმე გეიმ სერვერი ერთ VDS-ზე მის უფრო მცირე ალტერნატივებს ეხება. საზოგადოებისთვის, რომელიც ელოდება, რომ სერვერი ყოფილიყო ჩართული, როცა შენ შვებულებაში ხარ, ეს მეორე ჰობია.

მიზეზი, რის გამოც ეს მომხმარებლისთვის საინტერესოა, ისაა, რომ ის გეუბნება, რა ჰკითხო ჰოსტს. Backup-ები ტოვებს თუ არა იმ მანქანას, რომელსაც იცავს. რა ხდება მეხსიერების ლიმიტზე. SFTP credential-ები არის თუ არა თითო სერვერზე ან თითო ანგარიშზე. შეგიძლია თუ არა თავად დაამატო პორტი. ეს ყველა პანელის დონის პასუხია, და ჰოსტი, რომელსაც მათი სწრაფად გაცემა არ შეუძლია, ჰოსტია, რომელსაც მათზე არ უფიქრია.

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

Console არაფერს აჩვენებს და სერვერი "გამორთულია". Wings არ პასუხობს. პანელში რასაც არ გააკეთებ, არ დაგეხმარება, და თამაში შეიძლება მაინც მუშაობდეს. ეს სტატუსის გვერდისა და ტიკეტის საქმეა და არა ხელახლა ცდის.

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

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

File manager 4 GB modpack-ს არ ტვირთავს. ბრაუზერის ატვირთვები ამ ზომაზე არასწორი ხელსაწყოა. გამოიყენე SFTP ან ატვირთე zip და გახსენი ადგილზე.

ყველაფერი ნელია, მაგრამ გრაფიკები კარგად გამოიყურება. შეამოწმე, რომელი გრაფიკი. მთლიანი CPU ბირთვებზე შეიძლება 30%-ზე იდგეს, მაშინ როცა თამაშის ერთი ცხელი thread მიჭედებულია, მეხსიერების გრაფიკი კი ჯანსაღი შეიძლება ჩანდეს იმ მომენტამდე, სანამ ნახტომი ლიმიტს გადალახავს.

FAQ#

Pterodactyl უფასოა და ხომ არ ზოგავს ჰოსტი, რომელიც მას იყენებს?

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

შემიძლია SSH წვდომა მივიღო ჩემს გეიმ სერვერზე?

არა. პანელის სერვერი არის კონტეინერი თამაშით და SSH მისი ნაწილი არ არის. იღებ SFTP-ს ფაილებისთვის და console-ს თამაშისთვის. თუ shell გჭირდება, გჭირდება VDS.

რატომ ვერ ვაყენებ plugin-ს, რომელიც პანელმა არ იცის?

შეგიძლია - plugin-ები, mod-ები და კონფიგურაციები უბრალოდ ფაილებია, რომლებსაც file manager-ით ან SFTP-ით ტვირთავ, და დამტკიცებული mod-ების სია არ არსებობს. რისი დაყენებაც არ შეგიძლია, სისტემური პროგრამაა, რადგან კონტეინერი ყოველ გაშვებაზე image-იდან თავიდან შენდება.

რა არის egg, ერთ წინადადებაში?

რეცეპტის ფაილი, რომელიც პანელს ეუბნება, რომელი Docker image გამოიყენოს, როგორ დააყენოს თამაში, როგორ გაუშვას და რომელი პარამეტრები აჩვენოს Startup ჩანართზე.

გეგმის გაუმჯობესება სერვერს თავიდან აშენებს?

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

პანელი აგრძელებს მუშაობას, თუ ჩემი სერვერი ჩავარდა, და პირიქით?

დიახ ორივეზე. ისინი ცალკე პროგრამებია. ჩავარდნილი გეიმ სერვერი პანელს სრულიად გამოსადეგს ტოვებს, რითაც კითხულობ ლოგს, რომელიც ამბობს რატომ; პანელის გათიშვა გაშვებულ სერვერებს გაშვებულს ტოვებს, რადგან Wings ნებართვას არ ითხოვს, რომ კონტეინერი ცოცხალი დატოვოს.