PM2 თუ ჰოსტინგ პანელი: რისთვის არის process manager

PM2 პასუხობს კითხვას, რომელზეც ჰოსტინგ პანელს ჩვეულებრივ უკვე უპასუხია: რა გადატვირთავს ჩემს აპლიკაციას, როცა ის გავა, და სად მიდის მისი ლოგები. თუ ორივეს გაუშვებ, მიიღებ ორ supervisor-ს ერთმანეთზე დაწყობილს, და გარეთა - რომელსაც მეხსიერების გრაფიკი, restart-ების ისტორია და alerting აქვს - თვალს აკარგებს პროცესზე, რომელსაც უნდა უთვალთვალებდეს. PM2-ის ქვეშ crash-loop-ში მყოფი აპლიკაცია კონტეინერის გარედან ისე გამოიყურება, როგორც აპლიკაცია, რომელიც ცხრა დღეა მუშაობს.

ეს არის მოკლე პასუხი: კონტეინერზე დაფუძნებულ პანელზე გაუშვი პროცესი პირდაპირ და პლატფორმას მიანდე მისი supervision. უბრალო virtual სერვერზე, სადაც საკუთარი supervision არ არის, process manager ზუსტად სწორია - თუმცა systemd უკვე დაყენებულია და იგივე საქმის უმეტეს ნაწილს აკეთებს. პოსტის დანარჩენი ნაწილი დეტალებია: რას იძლევა თითოეული ფენა, სად ეჯახებიან ისინი და როგორ გადახვიდე PM2-დან იმის დაკარგვის გარეშე, რასაც ის მართლა აკეთებდა შენთვის.

რას აკეთებს PM2 სინამდვილეში#

PM2 არის daemon პლუს CLI. pm2 start შენს script-ს გადასცემს ფონურ daemon-ს, რომელიც მას ქმნის, უთვალთვალებს, გადატვირთავს, როცა ის გამოდის, და მის გამოტანას ფაილებში წერს. შემდეგ CLI გადის, რაც კონტეინერში პირველი რამაა, რაც მნიშვნელოვანია.

$ pm2 start dist/server.js --name api -i 2$ pm2 ls$ pm2 logs api --lines 100$ pm2 restart api$ pm2 save && pm2 startup

მისი შესაძლებლობების სია შიშველ მანქანაზე ნამდვილად გამოსადეგია:

• Restart გასვლისას, min_uptime-ით, max_restarts-ითა და არჩევითი ექსპონენციალური backoff-ით, რომ პროცესი, რომელიც მაშინვე კვდება, მჭიდრო ციკლში არ გადაიტვირთოს.
• Cluster mode, რომელიც Node-ის cluster მოდულს იყენებს რამდენიმე worker პროცესის გასაშვებად, რომლებიც ერთ მოსმენად socket-ს იზიარებენ.
• `pm2 reload`, რომელიც cluster mode-ში worker-ებს სათითაოდ ტვირთავს, ამიტომ ყოველთვის არის worker, რომელიც კავშირებს იღებს.
• ლოგების დაჭერა ~/.pm2/logs/<name>-out.log-სა და -error.log-ში, rotation-ით, თუ pm2-logrotate მოდულს დააყენებ.
• გაშვება boot-ზე, pm2 startup-ით, რომელიც აგენერირებს და აყენებს systemd unit-ს, რომელიც pm2 resurrect-ს უშვებს იმის დასაბრუნებლად, რაც pm2 save-მა ჩაიწერა.
• `max_memory_restart`, რომელიც ტვირთავს worker-ს, რომლის resident მეხსიერებაც ზღვარს გადალახავს.
• Ecosystem ფაილი, რომ ყოველივე ზემოთქმული repository-შია და არა ვინმეს shell-ის ისტორიაში.

module.exports = {  apps: [    {      name: "api",      script: "dist/server.js",      instances: 2,      exec_mode: "cluster",      max_memory_restart: "300M",      env: { NODE_ENV: "production" },    },  ],};

არც ერთი ეს ცუდი პროგრამა არ არის. კითხვა მხოლოდ ისაა, აკეთებს თუ არა ქვემოთ რამე უკვე იმავე საქმეს.

რას აკეთებს პანელი უკვე#

პანელზე დაფუძნებული ჰოსტი შენს აპლიკაციას საკუთარ კონტეინერში უშვებს, და თავად კონტეინერიც supervised-ია. RE:NODE-ზე ეს ნიშნავს:

• Start, stop, restart და kill კონსოლიდან, და კონტეინერი გადაიტვირთება, როცა პროცესი გადის.
• მეხსიერების ლიმიტი, რომელსაც kernel ასრულებს. ლიმიტზე კონტეინერი ჩერდება და swap-ის უფლების ნაცვლად სუფთად იტვირთება, რაც upstream Pterodactyl-ის ქცევის საპირისპიროა და ბევრად უფრო ადვილი გასააზრებელი: არასოდეს გექნება სერვერი, რომელიც ტექნიკურად ცოცხალია და ფუნქციურად გაყინული.
• მკაცრი CPU წილი. გეგმის რიცხვი ერთი ბირთვის პროცენტია, ამიტომ 250 არის 2.5 vCPU, და ეს ჭერია და არა სამიზნე. პროცესი 100%-ზე ნელია და არა გატეხილი, და ამის გამო არასოდეს ჩერდება.
• Crash-ის აღმოჩენა. Watcher ყოველ ორ წუთში ამოწმებს სერვერს, რომელიც გამოირთო ან რომლის uptime უკან წავიდა. შენ მოთხოვნილი restart-ები არ ითვლება. საათში სამი მოულოდნელი restart სერვერის გვერდზე გაფრთხილებას აჩენს და ავტომატურად ხსნის ticket-ს; ექვსი სერვერს აჩერებს, რომ crash-loop მთელი შაბათ-კვირა არ იმუშაოს.
• ცოცხალი კონსოლის გამოტანა, ფილტრის გარეშე, ბრძანების ხაზით, პლუს მეხსიერების, CPU-სა და დისკის გრაფიკები გეგმის ლიმიტების წინააღმდეგ.
• Schedules cron გამოსახულებით, რომელიც უშვებს დალაგებულ ამოცანებს დაყოვნებებით: კონსოლის ბრძანება, backup, power action.
• Git deploy-ები GitHub-იდან, ორი გადამრთველით - pull ყოველ start-ზე და redeploy push-ზე, რომელიც ტვირთავს მხოლოდ სერვერს, რომელიც უკვე ჩართული იყო - და თითო deploy-ზე ერთი ჩანაწერით.

წაიკითხე ეს სია PM2-ის სიის გვერდით და გადაფარვა ორივეს უმეტესი ნაწილია.

გადაფარვა, ხაზ-ხაზ#

ორ სტრიქონზე ღირს შეჩერება. PM2 ერთადერთი სვეტია zero-downtime reload-ით, და ეს რეალური რამაა, რასაც ის გვთავაზობს. და პანელი ერთადერთი სვეტია, რომელიც ვინმეს ეუბნება, რომ აპლიკაცია crash-loop-შია, რაც სწორედ ის არის, რაც დილის ოთხ საათზე მნიშვნელოვანია.

რატომ მალავს supervisor supervisor-ის შიგნით პრობლემებს#

გაჰყევი crash-ს ამ დიაგრამაზე ზემოთ. შენი აპლიკაცია unhandled promise rejection-ზე აგდებს შეცდომას და გადის. PM2 ამჩნევს და ისევ უშვებს. კონტეინერი არასოდეს გასულა, ამიტომ პლატფორმის თვალსაზრისით არაფერი მომხდარა: uptime შეუწყვეტელია, restart არ ჩაწერილა, crash watcher ნულს ითვლის და ticket, რომელიც გაგაფრთხილებდა, არ იხსნება. შენი მეხსიერების გრაფიკი ბრტყელი ხაზია, რომელიც ათეულობით მოკლე ცხოვრების პროცესისგან შედგება.

ეს მთელი არგუმენტია, დანარჩენი კი შედეგებია:

• Exit code იჩქმალება. პროცესი, რომელიც 1-ით გადის, რადგან საჭირო environment ცვლადი აკლია, გარედან არ განირჩევა იმისგან, რომელიც კარგად მუშაობს.
• მეხსიერების აღრიცხვა ბუნდოვანი ხდება. კონტეინერის ლიმიტი daemon-ზე და ყველა worker-ზე ერთად ვრცელდება. დააყენე max_memory_restart 512M-ზე 1 GB გეგმაზე ორი worker-ით და kernel მთელ კონტეინერს PM2-ის საკუთარ ზღვრამდე ადრე გააჩერებს - ერთი პოლიტიკა, რომელიც დააკონფიგურირე, ერთი, რომელიც რეალურად ირთვება, და ის, რომელიც ირთვება, შენი არ არის.
• სიგნალებს დამატებითი ნახტომი აქვთ. პანელის stop კონტეინერის მთავარ პროცესს უგზავნის სიგნალს. თუ ის shell-ია, ან PM2 CLI-ის გამოძახება, რომელიც უკვე დაბრუნდა, შენმა აპლიკაციამ სიგნალი შეიძლება საერთოდ ვერ მიიღოს და grace პერიოდის შემდეგ მოკვდეს სუფთა გამორთვის ნაცვლად. Graceful shutdown და health check-ები განმარტავს, რატომ გიჯდება ეს მიმდინარე request-ები.
• ლოგები უხერხულ ადგილას გადადის. PM2 ფაილებში წერს მისი home დირექტორიის ქვეშ და არა standard output-ში, ამიტომ ცოცხალი კონსოლი daemon-ის საკუთარ ლაპარაკს აჩვენებს და არა შენი აპლიკაციისას. ბოლოს ლოგებს SFTP-ით კითხულობ, რაც deploy-ზე დასაკვირვებლად უცნაური გზაა.
• Daemon მეხსიერებას ხარჯავს. ათობით მეგაბაიტს, რაც 8 GB-ზე არაფერია და 1 GB-ზე შესამჩნევია.

თუ კონტეინერში მაინც PM2-ს უშვებ, გამოიყენე pm2-runtime#

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

$ pm2-runtime start ecosystem.config.js --env production

pm2-runtime CLI-ის კონტეინერისთვის მორგებული ვერსიაა. ის foreground-ში რჩება, აპლიკაციის ლოგებს standard output-ში გადასცემს, რომ კონსოლმა აჩვენოს, და გადის, როცა აპლიკაციები გადიან, რაც პლატფორმას ჩავარდნების დანახვის საშუალებას აძლევს. კონტეინერში ჩვეულებრივი pm2 start-ის გამოყენება კლასიკური შეცდომაა: CLI აპლიკაციას daemon-ს გადასცემს და ბრუნდება, მთავარი პროცესი გადის და კონტეინერი ჩერდება, აპლიკაცია კი თითქოს მუშაობს.

ორი პარამეტრი შეამოწმე, სანამ იქ ხარ. PM2 ნაგულისხმევად შენს აპლიკაციას SIGINT-ს უგზავნის და არა SIGTERM-ს, ამიტომ აპლიკაცია, რომლის shutdown handler მხოლოდ SIGTERM-ს უსმენს, მას არასოდეს გაუშვებს - დააყენე kill_signal ან დაამუშავე ორივე. და kill_timeout არის დრო, რამდენსაც PM2 ელოდება, სანამ SIGKILL-ს გამოგზავნის; ის უნდა იყოს შენი ყველაზე გრძელი მიმდინარე request-ის ხანგრძლივობაზე მეტი და არა ნაკლები.

Cluster mode: როდის ეხმარება მეტი პროცესი და როდის არა#

Cluster mode PM2-ის ყველაზე ძლიერი თვისებაა და ყველაზე ხშირად არასწორად გამოყენებული. Node შენს JavaScript-ს ერთ thread-ზე უშვებს, ამიტომ მეორე პროცესს მეორე ბირთვის გამოყენება შეუძლია. კითხვა ისაა, იყიდე თუ არა მეორე ბირთვი.

instances: "max" ითხოვს ერთ worker-ს ყოველ ლოგიკურ CPU-ზე, რომელსაც მანქანა აცხადებს, რაც გაზიარებულ node-ზე ჰოსტის ბირთვების რაოდენობაა და არა შენი წილი. კონტეინერზე, რომელიც ნახევარ ბირთვამდეა შეზღუდული, ეს შეიძლება ნიშნავდეს ათეულ worker-ს, რომლებიც ერთსა და იმავე შეზღუდულ ნაჭერს ინაწილებენ და თითოეული შენი dependency ხის საკუთარ ასლს მეხსიერებაში ინახავს. შედეგია ნაკლები გამტარუნარიანობა და გაცილებით მეტი მეხსიერება, რაც ზუსტად "დავამატეთ worker-ები და უფრო ნელი გახდა" ტიპის ანგარიშის ფორმაა.

cluster mode-ის კიდევ ორი შედეგი, რომელიც უნდა იცოდე მის ჩართვამდე:

• Sticky session-ები. ყველაფერი, რაც პროცესში მდგომარეობას ინახავს - WebSocket კავშირი, რომელიც Map-შია აღრიცხული, მეხსიერებაში მყოფი session store, Socket.IO-ს ნაგულისხმევი transport-ის განახლება - ირღვევა, როცა თანმიმდევრული request-ები სხვადასხვა worker-ზე ეშვება. მარშრუტიზაციის მხარისთვის იხილე websocket-ები reverse proxy-ს უკან.
• ყველაფერი, რაც ერთხელ უნდა გაეშვას. Cron job, რიგის consumer ან migration შენს აპლიკაციაში ახლა ერთხელ გაეშვება worker-ზე. ასე იგზავნება ღამის წერილი ოთხჯერ.

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

მის გარეშე: start ბრძანება და ლოგები#

პანელზე PM2-ის ჩანაცვლება უმეტესად წაშლაა. Start ბრძანება შენს პროცესს foreground-ში, კონტეინერში, მთავარ პროცესად უშვებს:

$ npm ci --omit=dev && node dist/server.js

გამოიყენე npm ci და არა npm install, რომ lockfile წყვეტდეს, რა დაყენდება - npm ci vs npm install განსხვავებასა და იმას განმარტავს, რატომ აქვს მას სერვერზე უფრო დიდი მნიშვნელობა, ვიდრე ლეპტოპზე. ლოგირება standard output-სა და standard error-ში მიდის, საიდანაც კონსოლი კითხულობს; როტირებადი ლოგ ფაილი არ არის და გასასუფთავებელი არაფერია, როცა დისკი ივსება. კონსოლის კითხვა მოიცავს, რას აკეთებს პანელი ამ ნაკადთან.

იმ შესაძლებლობებისთვის, რომლებსაც კარგავ, ჩანაცვლებებია:

1. Restart crash-ზე - კონტეინერი აკეთებს. დარწმუნდი, რომ პროცესი ფატალურ შეცდომაზე მართლა გადის და არ ჩაკიდებულა, თორემ მას ვერავინ გადატვირთავს.
2. Restart გრაფიკით - power action Schedules ჩანართზე cron გამოსახულებით, რაც ასევე ნიშნავს, რომ restart განზრახულად ჩაიწერება და crash watcher მას არ დაითვლის.
3. მეხსიერების ლიმიტი - გეგმის ლიმიტი, რომელსაც kernel ასრულებს. თუ გინდა, რომ თავად Node უფრო ადრე და უფრო პროგნოზირებადად ჩავარდეს, დააყენე --max-old-space-size კონტეინერის ლიმიტზე დაბლა.
4. რამდენიმე პროცესი - მეორე სერვერი, რაც უფრო სუფთაა, ან & start ბრძანებაში, რაც უფრო იაფია და ფონზე გაშვებულ პროცესზე supervision-ს არ გაძლევს. Background job-ები პატარა სერვერზე ამ ორს ერთმანეთს ადარებს.
5. Zero-downtime reload - მართალი რომ ვთქვა, ამას კარგავ. ერთკონტეინერიან deploy-ს რამდენიმე წამის ხვრელი აქვს, სანამ პროცესი იტვირთება, და სხვაგვარად ჩვენება ისაა, როგორც ხალხი ისევ ორ supervisor-თან მოდის. Zero-downtime deploy-ები პატარა სერვერზე გასაგებად ამბობს, რა არის შესაძლებელი და რა არა ერთ მანქანაზე.

თავად deploy GitHub-იდან მოდის: pull start-ზე ან redeploy push-ზე, თითო deploy ჩაწერილია, რომ განასხვავო ის, რომელმაც გაიარა, იმისგან, რომელიც ჩავარდა. Node აპლიკაციის deploy GitHub-იდან ამ მოწყობის ხუთწუთიანი ვერსიაა.

სადაც process manager მაინც სწორია#

VDS-ზე ან dedicated მანქანაზე არაფერი არაფერს არ უთვალთვალებს, სანამ თავად არ გააკეთებ. იქ რამე გჭირდება, და ორი კანდიდატია PM2 და systemd.

systemd უკვე დაყენებულია, boot-ზე ეშვება დამხმარის გარეშე, ლოგებს journal-ში იჭერს და წარუმატებლობისას გადატვირთავს backoff-ით, რომელსაც თავად აყენებ:

[Service]User=appWorkingDirectory=/srv/apiExecStart=/usr/bin/node dist/server.jsRestart=alwaysRestartSec=5Environment=NODE_ENV=production[Install]WantedBy=multi-user.target

journalctl -u api -f ცვლის pm2 logs-ს, და systemctl restart api ცვლის pm2 restart-ს. დამატებითი daemon არ არის, pm2 save არ არის, რომ დაგავიწყდეს, და იგივე მექანიზმი მანქანაზე ყველაფერს უთვალთვალებს. Systemd სერვისები შენი აპლიკაციებისთვის unit ფაილებს სათანადოდ მოიცავს.

PM2 VDS-ზე ადგილს იმსახურებს, როცა გინდა cluster mode მოძრავი reload-ებით, როცა რამდენიმე პატარა Node აპლიკაციას უშვებ და ყველასთვის ერთი CLI გირჩევნია, ან როცა pm2 monit ნამდვილად ის არის, როგორც შენი გუნდი მუშაობს. ეს რეალური მიზეზებია. "ეს ეწერა tutorial-ში" - არა.

PM2-დან გადასვლა ათ წუთში#

1. წაიკითხე ecosystem.config.js და ჩამოწერე ყველაფერი, რაც რეალური კონფიგურაციაა: environment ცვლადები, script-ის გზა, instance-ების რაოდენობა, max_memory_restart.
2. გადაიტანე environment ცვლადები პანელის Startup ჩანართზე, ან შენს environment ფაილში, თუ VDS-ზე ხარ.
3. დააყენე start ბრძანება script-ზე პირდაპირ, foreground-ში: node dist/server.js და არა pm2 start.
4. დარწმუნდი, რომ აპლიკაცია standard output-ში წერს. თუ ის ფაილში ლოგირებისთვის იყო დაყენებული იმიტომ, რომ PM2 stdout-ს მაინც იჭერდა, დააბრუნე.
5. დაამატე SIGTERM handler, რომელიც სერვერს ხურავს და მიმდინარე request-ებს ასრულებს, და შეამოწმე, რომ პანელის stop სუფთაა.
6. თუ cron_restart გამოიყენებოდა, ხელახლა შექმენი როგორც დაგეგმილი power action.
7. წაშალე PM2 package.json-იდან და შეამოწმე, რომ სხვა არაფერი იძახებს მას shell-იდან.
8. გააკეთე deploy, შემდეგ განზრახ ჩამოაგდე აპლიკაცია და უყურე, რა ხდება - კონტეინერი უნდა გადაიტვირთოს და restart ხილული უნდა იყოს. თუ არ არის, რაღაც ისევ exit-ს ყლაპავს.

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

FAQ#

მუშაობს PM2 ჰოსტინგ პანელზე საერთოდ?

დიახ, თუ მას pm2-runtime-ით უშვებ, რომ foreground-ში დარჩეს და ლოგები standard output-ში გადასცეს. ის მუშაობს; უბრალოდ იმეორებს supervision-ს, რომელიც კონტეინერს უკვე აქვს, და პლატფორმის crash-ის აღმოჩენას crash-ებს უმალავს. ჩვეულებრივი pm2 start start ბრძანებად არ მუშაობს, რადგან CLI ბრუნდება და კონტეინერი ჩერდება.

მჭირდება cluster mode?

მხოლოდ თუ ერთ ბირთვზე მეტი CPU წილი გაქვს და შენი აპლიკაცია JavaScript-ში CPU-ზეა შეკრული. უმეტესი პატარა Node სერვისი ბაზას ან upstream API-ს ელოდება, სადაც მეორე პროცესი მეხსიერებას ამატებს და გამტარუნარიანობას არა. Worker-ების დამატებამდე CPU გრაფიკი შეამოწმე.

რა ცვლის pm2 logs-ს?

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

PM2 ცუდი ინსტრუმენტია?

არა. ეს კარგად აგებული process manager-ია, რომელიც ხსნის პრობლემას, რომელიც არამართულ მანქანებზე არსებობს. შეცდომა PM2 არ არის, შეცდომაა ორი supervisor-ის გაშვება და იმის მოლოდინი, რომ გარეთა მიხვდება, რას აკეთებს შიდა.

მაძლევს პანელი zero-downtime deploy-ებს?

არა, და არც სხვა რამ, რომელიც შენი აპლიკაციის ერთ ასლს ერთ სერვერზე უშვებს. Restart რამდენიმე წამის ხვრელია. ნამდვილი zero-downtime ორ instance-სა და მათ წინ რაღაცას საჭიროებს, რაც ერთი აპლიკაციის გეგმაზე უფრო დიდი არქიტექტურაა.

რაც შეეხება forever-ს, nodemon-ს ან supervisor-ს?

nodemon დეველოპმენტის ინსტრუმენტია, რომელიც ფაილების ცვლილებაზე ტვირთავს და production-ის start ბრძანებაში არასოდეს უნდა იყოს. forever ძირითადად მოძველდა. ზემოთ მოცემული მსჯელობა ყველა მათგანზე ვრცელდება: თუ პლატფორმა შენს კონტეინერს ტვირთავს, მეორე გადამტვირთავი არაფერს ამატებს, გარდა ადგილისა, სადაც ჩავარდნები იმალება.