Laravel-ის დეპლოი პროდაქშენზე: env, ქეშები, queue და cron

Laravel-ის დეპლოი ექვსი საქმეა ფიქსირებული თანმიმდევრობით: კოდი სერვერზე მიგაქვს, აყენებ production დამოკიდებულებებს, მის გვერდით დებ რეალურ .env-ს აპლიკაციის გასაღებით, storage-სა და bootstrap/cache-ს ჩასაწერს ხდი, აგებ ქეშებს და ატარებ მიგრაციებს. ყველაფერი, რაც მერე ცუდად მიდის, ამ ექვსიდან ერთ-ერთის გამოტოვების, არასწორ რიგში გაკეთების ან იმ მანქანაზე გაკეთების ვარიაციაა, რომლის მისამართებიც განსხვავდება მოძრაობის მომსახურე მანქანის მისამართებისგან. ეს გიდი მთელი თანმიმდევრობაა, პარამეტრები, რომლებიც განსაზღვრავს, საიტი სწრაფია თუ უბრალოდ მუშაობს, და შეცდომები, რომლებიც სხვა შემთხვევაში ერთ საღამოს წაგართმევს.

ის ვარაუდობს Linux სერვერს nginx-ითა და PHP-FPM-ით, რაც ყველაზე გავრცელებული shared და პანელური ჰოსტინგია. artisan-ის ბრძანებები ყველა ჰოსტზე ერთნაირია, იმ ჰოსტზეც, სადაც მხოლოდ SFTP გაქვს.

კოდამდე: PHP, გაფართოებები და document root#

Laravel 10-ს სჭირდება PHP 8.1 ან უფრო ახალი. Laravel 11-სა და 12-ს - PHP 8.2 ან უფრო ახალი. თუ ახლა ირჩევ, აიღე ყველაზე ახალი PHP, რომელსაც შენი დამოკიდებულებები უჭერს მხარს, რადგან 7.4-დან 8.x-ზე გადასვლა PHP აპლიკაციისთვის ყველაზე დიდი უფასო აჩქარებაა, ხოლო 8.x-ში OPcache უკეთ ინახავს კომპილირებულ კოდს მეხსიერებაში.

გაფართოებები, რომლებსაც Laravel აუცილებლად მიიჩნევს: ctype, curl, dom, fileinfo, filter, hash, mbstring, openssl, pcre, pdo, session, tokenizer და xml. თითქმის ყველა რეალურ აპლიკაციას ასევე სჭირდება intl თარიღებისა და რიცხვების ფორმატირებისთვის, zip არქივებთან სამუშაოდ და gd ან imagick, თუ სურათებს ეხება. სანამ რამეს ატვირთავ, შეამოწმე, რა გაქვს:

$ php -v$ php -m$ php -i | grep -E "opcache.enable|memory_limit|upload_max_filesize"

document root ის პარამეტრია, რომელზეც ყველა ებმება, ვინც CMS-იდან მოდის. ის უნდა უთითებდეს შენი პროექტის შიგნით არსებულ public/ საქაღალდეზე და არა პროექტის ძირზე. ყველაფერი public/-ის ზემოთ - შენი .env, vendor, storage, app - განკუთვნილია იმისთვის, რომ HTTP-ით მიუწვდომელი იყოს. თუ root არასწორია, ორი სიმპტომიდან ერთს მიიღებ: შენი საწყისი კოდის საქაღალდის სიას ან გვერდს, რომელიც იტვირთება, მაგრამ ყველა მარშრუტზე 404-ს აბრუნებს, /-ის გარდა. ორივე ცხადია, როგორც კი იცი, რას უყურო.

თუ შენი ჰოსტი root-ს აფიქსირებს და არ გიცვლის, ორი გზა გაქვს: public/-ის შიგთავსი განათავსე გასაცემ საქაღალდეში და index.php-ში require მიუთითე რეალურ გზებზე ერთი დონით ზემოთ, ან აირჩიე ჰოსტი, სადაც root-ს თავად აკონტროლებ. პირველი მუშაობს და უშნოა; ბევრი production საიტი სწორედ ასე მუშაობს.

.env ფაილი და აპლიკაციის გასაღები#

.env შენს კოდთან ერთად არ იდეპლოება. ის ერთხელ იქმნება სერვერზე და არასოდეს კომიტდება. მინიმუმი production-ისთვის:

APP_NAME="Example"APP_ENV=productionAPP_KEY=base64:...APP_DEBUG=falseAPP_URL=https://example.comLOG_CHANNEL=stackLOG_LEVEL=warningDB_CONNECTION=pgsqlDB_HOST=db.example.netDB_PORT=5432DB_DATABASE=appDB_USERNAME=appDB_PASSWORD=...SESSION_DRIVER=databaseCACHE_STORE=databaseQUEUE_CONNECTION=database

APP_DEBUG=false არჩევითი არ არის. როცა ჩართულია, ნებისმიერი დაუჭერელი exception აჩვენებს გვერდს, რომელშიც შენი ფაილების გზები, შენი query და შენი გარემოს დიდი ნაწილია. დააყენე და დარწმუნდი: განზრახ გამოიწვიე 500 და შეამოწმე, რომ უბრალო შეცდომის გვერდს იღებ.

APP_KEY არის 32-ბაიტიანი გასაღები, რომელიც გამოიყენება ყველა დაშიფრული cookie-სა და ყველა Crypt:: გამოძახებისთვის. დააგენერირე ერთხელ სერვერზე:

$ php artisan key:generate --force

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

Laravel-ს მოჰყვება ბაზის დრაივერები სახელებით mysql, mariadb, pgsql, sqlite და sqlsrv. გამოიყენე ის, რომელიც შენს რეალურ ბაზას ემთხვევა, და host, port, სახელი, მომხმარებელი და პაროლი აიღე იქიდან, სადაც შენმა ჰოსტმა შექმნა, და არ გამოიცნო. RE:NODE-ზე ვებ გეგმები მოიცავს ბაზის სლოტებს, რომლებიც პანელიდან იქმნება, host-ით, მომხმარებლითა და პაროლით, რომლებიც შენთვის გენერირდება, და ღილაკს "Open in phpMyAdmin", რომელიც შედის 60 წამით მოქმედი token-ით. ცალკე ბაზის ხაზი არის PostgreSQL ან MongoDB, რომელსაც საკუთარ host-სა და port-ზე უკავშირდები.

queue, cache და session დრაივერები გადაწყვეტილებას იმსახურებს და არა ნაგულისხმევს. სამივესთვის database სწორი საწყისი წერტილია ერთ პატარა სერვერზე: არაფერი დამატებითი არ სჭირდება, restart-ს უძლებს და ადვილი შესამოწმებელია. file სესიები მუშაობს, მაგრამ storage/framework/sessions-ში ათასობით ფაილს ტოვებს, ხოლო გაზიარებული ქეში გაზიარებული აღარ არის, როგორც კი ორ პროცესს გაუშვებ. გაითვალისწინე, რომ Laravel 11-მა cache-ის გასაღები CACHE_DRIVER-დან CACHE_STORE-ად გადაარქვა; 10-სა და უფრო ძველზე ის ისევ CACHE_DRIVER-ია, და არასწორის დაყენება ჩუმად ნაგულისხმევზე გტოვებს.

უფლებები, storage და public symlink#

ორი საქაღალდე უნდა იყოს ჩასაწერი იმ მომხმარებლისთვის, რომლითაც PHP-FPM მუშაობს, და მხოლოდ ეს ორი: storage და bootstrap/cache. დანარჩენი ყველაფერი შეიძლება მხოლოდ წასაკითხი იყოს.

$ chmod -R ug+rwX storage bootstrap/cache$ chown -R www-data:www-data storage bootstrap/cache

მომხმარებლის სახელი ჰოსტის მიხედვით იცვლება. container-ზე ის ხშირად საერთოდ არ არის www-data, ხოლო shared ჰოსტინგზე შენი SFTP მომხმარებელი და PHP-ის მომხმარებელი ჩვეულებრივ ერთია, რაც ამ ნაბიჯს უსარგებლოს ხდის. 777 პასუხია, რომელსაც ფორუმებზე პოულობენ, და ის არასწორია: ის ყველა ატვირთულ ფაილს მანქანაზე ნებისმიერისთვის შესრულებადს ხდის.

აპლიკაციის მიერ ატვირთული ფაილები ნაგულისხმევად storage/app/public-ში ხვდება, რომელიც document root-ის შიგნით არ არის. მათ გამოაშკარავებს symlink:

$ php artisan storage:link

ეს ქმნის public/storage-ს, რომელიც storage/app/public-ზე მიუთითებს. ეს ნამდვილი symlink-ია, ამიტომ ის ვერ გადარჩება დეპლოის, რომელიც ახალ public/ საქაღალდეს SFTP-ით ტვირთავს, ზოგი არქივატორი კი მის შექმნაზე უარს ამბობს. თუ ატვირთული სურათები დეპლოის შემდეგ 404-ს აბრუნებს, მაგრამ ფაილები დისკზეა, ეს არის მიზეზი. ბრძანება ხელახლა გაუშვი ან ბმული ხელით შექმენი.

თუ შენი ჰოსტი symlink-ებს საერთოდ არ იძლევა, დააყენე FILESYSTEM_DISK=public და config/filesystems.php-ში disk-ის root შეცვალე public/-ის შიგნით არსებულ საქაღალდეზე. ეს ელეგანტური არ არის, მაგრამ გატეხილ მედია ბიბლიოთეკას სჯობს.

Composer, asset-ები და ქეშები, რომლებიც სისწრაფეს იძლევა#

დააყენე დამოკიდებულებები production-ის გზით:

$ composer install --no-dev --optimize-autoloader --no-interaction

--no-dev გამოტოვებს ყველაფერს, რაც require-dev-შია. თუ საიტი ტყდება "Class not found"-ით, რომელიც debug ან ტესტირების პაკეტს ასახელებს, ეს პაკეტი production კოდში გამოიყენება და require-ში უნდა იყოს და არა require-dev-ში. --optimize-autoloader აგებს class map-ს, რათა PHP-მ თითოეულ autoload-ზე ფაილურ სისტემაში ძებნა შეწყვიტოს, რაც დიდ აპლიკაციაზე შენი პასუხის დროის გაზომვად ნაწილს გიგებს.

front-end asset-ები Vite-ით იგება და შედეგი public/build-ში ხვდება. 1 GB გეგმაზე დიდ პროექტზე npm run build მეხსიერების ლიმიტამდე მისვლისა და container-ის გაჩერების სავარაუდო გზაა, ამიტომ ლოკალურად ან CI-ში აგება და public/build-ის ატვირთვა უფრო სწრაფიცაა და უსაფრთხოც. თუ ასე იქცევი, სერვერს Node საერთოდ არ სჭირდება.

შემდეგ ქეშები. თითოეული ფაილების წაკითხვისა და პარსინგის გროვას ერთ ჩასართავ PHP მასივად აქცევს:

$ php artisan optimize

ბოლო ვერსიებში php artisan optimize config, event, route და view ქეშებს ერთად ატარებს; უფრო ძველში ნაკლებს აკეთებდა. გაუშვი php artisan optimize --help შენს ვერსიაზე და ვარაუდს ნუ დაეყრდნობი. საპირისპირო, როცა თავიდან აგება გჭირდება, არის php artisan optimize:clear.

შედეგი, რომელსაც ადამიანები გვერდს ვერ უვლიან: როცა config დაქეშილია, `env()` ყველგან null-ს აბრუნებს, `config/` ფაილების შიგნით გარდა. დაქეშილი მასივი აგებულია config ფაილებიდან, env() უკვე გადაწყვეტილი. თუ შენი აპლიკაცია კონტროლერში env('STRIPE_KEY')-ს იძახებს, ლოკალურად მუშაობს და production-ზე null-ს აბრუნებს. გამოსავალია მნიშვნელობა config ფაილში დაამატო და ამის ნაცვლად config('services.stripe.key') გამოიძახო. ეს "ჩემთან მუშაობს"-ის ორი მთავარი მიზეზიდან ერთ-ერთია.

Route-ის ქეშირება ხმამაღლა ვარდება, თუ რომელიმე მარშრუტი კონტროლერის ნაცვლად closure-ს იყენებს. შეცდომა ფაილს ასახელებს. closure გადაიტანე კონტროლერში ან გამოტოვე route:cache და ფასი გადაიხადე.

მიგრაციები საიტის გატეხვის გარეშე#

production-ზე მიგრაციებმა კითხვა არ უნდა დასვან:

$ php artisan migrate --force

--force-ის გარეშე artisan დადასტურებას ითხოვს და არაინტერაქტიულ deploy სკრიპტში ან იკიდება, ან წყდება. --force მხოლოდ "ნუ იკითხავ"-ს ნიშნავს; ის არაფერს არ ტოვებს.

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

1. Maintenance mode, პატარა საიტებისთვის, სადაც წუთიანი გათიშვა მისაღებია. php artisan down --secret=some-long-string ყველასთვის 503 გვერდს აყენებს, მაგრამ შენ გატარებს მისამართზე https://example.com/some-long-string. დეპლოი, მიგრაცია და მერე php artisan up.
2. უკუთავსებადი მიგრაციები, დანარჩენისთვის. დაამატე სვეტი და დააგდე კოდი, რომელიც მის null-ობას იტანს, შეავსე, მერე დააგდე კოდი, რომელიც მას მოითხოვს, და ძველი სვეტი შემდეგ რელიზში წაშალე. ეს ერთის ნაცვლად სამი დეპლოია და არავის შეცდომა არ უჩანს. მიგრაციები გათიშვის გარეშე ამ მიდგომას სათანადოდ გადის.

ყოველი მიგრაციის წინ, რომელიც რაიმეს შლის ან გადაარქმევს, გააკეთე ბაზის backup. php artisan migrate:rollback მხოლოდ მაშინ მუშაობს, თუ მიგრაციას მოქმედი down() მეთოდი აქვს, და გასაკვირად ბევრს არ აქვს. RE:NODE-ზე Backups ჩანართი backup-ს მოთხოვნით ან განრიგით იღებს და ღილაკით აღადგენს, backup-ები კი ინახება იმ მანქანის გარეთ, რომელსაც იცავს - ერთადერთი სახეობა, რომელიც გვეხმარება, როცა პრობლემა თავად მანქანაა. ბაზის backup-ები და აღდგენა დანარჩენს აღწერს.

Queue-ები და scheduler#

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

$ php artisan queue:work --queue=high,default --tries=3 --max-time=3600 --sleep=3

queue:work გრძელვადიანი PHP პროცესია, ამიტომ შენს კოდს მეხსიერებაში ინახავს: დეპლოის შემდეგ ის ძველ კოდს აგრძელებს, სანამ სხვას არ უთხრავ. php artisan queue:restart ყველა worker-ს ატყობინებს, რომ მიმდინარე დავალება დაასრულონ და გამოვიდნენ, შენი პროცესების მენეჯერი კი მათ ახალი კოდით ისევ უშვებს. ეს ხაზი ჩასვი შენს deploy სკრიპტში და მასზე აღარასოდეს იფიქრებ.

--max-time=3600 worker-ს საათის შემდეგ ყოველ შემთხვევაში გამოჰყავს, რაც ყველაზე იაფი დაცვაა პაკეტში მეხსიერების ნელი გაჟონვისგან, რომელსაც ვერ აკონტროლებ. --tries=3 აჩერებს სამუდამოდ მარცხდებადი დავალების გამეორებას; ჩავარდნილი დავალებები failed_jobs ცხრილში ხვდება და php artisan queue:retry all მათ უკან აბრუნებს. queue:listen მხოლოდ დეველოპმენტში გამოიყენე: ის ყოველი დავალებისთვის framework-ს თავიდან ჩატვირთავს, რაც მოსახერხებელია და რამდენჯერმე უფრო ნელი.

scheduler მეორე პროცესია. Laravel-ის scheduler ერთი cron ჩანაწერია, რომელიც ყოველ წუთს გადის და თავად წყვეტს, რა დროა:

* * * * * cd /var/www/example && php artisan schedule:run >> /dev/null 2>&1

container-ზე, სადაც crontab არ არის, php artisan schedule:work იგივეს აკეთებს, როგორც წინა პლანზე გაშვებული პროცესი, რომელსაც მუშა მდგომარეობაში ინახავ. პანელურ ჰოსტინგზე ეს ჩვეულებრივ უკეთ ერგება, რადგან იქ ცოცხალი სწორედ თავად სერვერის პროცესია. ერთი და იგივე დავალება ორი მანქანიდან ნუ დაგეგმავ: Laravel-ს სწორედ ამისთვის აქვს withoutOverlapping() და onOneServer(), ხოლო მეორეს გაზიარებული cache store სჭირდება.

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

HTTPS, proxy-ები და URL-ების გენერაცია#

პროდაქშენში თითქმის ყველა Laravel აპლიკაცია რაღაცის უკან დგას, რაც TLS-ს წყვეტს: reverse proxy, load balancer, CDN. ეს მანქანა ვიზიტორს HTTPS-ით ელაპარაკება, შენს აპლიკაციას კი უბრალო HTTP-ით, რაც ორ წინასწარ მოსალოდნელ შეცდომას იწვევს.

პირველი არის შერეული კონტენტი. შენი აპი HTTP მოთხოვნას ხედავს, ამიტომ url(), asset() და route() http:// ბმულებს აგენერირებს და ბრაუზერი მათ HTTPS გვერდზე ბლოკავს. მეორე ისაა, რომ ყველა ვიზიტორი თითქოს proxy-ის მისამართიდან მოდის, რაც ჩუმად ტეხავს rate limiting-ს, ლოგირებას და ყველაფერს გეოგრაფიულს.

ორივე მოგვარდება proxy-ის ნდობით, რათა Laravel-მა X-Forwarded-Proto და X-Forwarded-For წაიკითხოს. Laravel 11-სა და 12-ზე ეს bootstrap/app.php-შია:

->withMiddleware(function (Middleware $middleware) {    $middleware->trustProxies(at: '*');})

Laravel 10-ზე და უფრო ძველზე ეს არის $proxies = '*'; ფაილში app/Http/Middleware/TrustProxies.php. *-ის ნდობა სწორია, როცა შენს აპლიკაციამდე ერთადერთი გზა proxy-ზე გადის, და არასწორია, როცა შენი origin port ინტერნეტიდან მისაწვდომია, რადგან მაშინ ნებისმიერს შეუძლია header-ის გაყალბება. APP_URL=https://example.com URL-ების გენერაციას ფარავს კონსოლის ბრძანებებში და queue-ს დავალებებში, რომლებსაც სქემის წასაკითხი მოთხოვნა არ აქვთ.

RE:NODE-ის app და web გეგმები მოიცავს proxy სლოტს: A ჩანაწერი მიუთითე ნაჩვენებ მისამართზე და სერტიფიკატი შენთვის გაიცემა და განახლდება 21-დღიან ფანჯარაში, ხოლო კლიენტის რეალური მისამართი X-Forwarded-For-ში მოდის. რას აკეთებს reverse proxy მოთხოვნის გზას განმარტავს, ხოლო HTTPS და Let's Encrypt ახსნილი აღწერს, რატომ ვარდება გაცემა, როცა DNS მზად არ არის.

განმეორებადი დეპლოი#

თანმიმდევრობა ერთხელ ჩაწერე და ყოველთვის ერთი და იგივე გაუშვი. ხელით დეპლოი იცვლება და სწორედ ეს ცვლილება ტყდება შუაღამისას.

$ php artisan down --secret="$(cat /var/www/deploy-secret)"$ git pull --ff-only origin main$ composer install --no-dev --optimize-autoloader --no-interaction$ php artisan migrate --force$ php artisan optimize$ php artisan queue:restart$ php artisan up

სადაც shell არ გაქვს, იგივე ნაბიჯები SFTP-ითა და იმ კონსოლით სრულდება, რომელსაც შენი ჰოსტი გაძლევს, იმავე რიგით. ერთი გაფრთხილება: ქეშები ააგე იმ მანქანაზე, რომელიც მათ ემსახურება. bootstrap/cache/packages.php და დაკომპილებული view-ები აბსოლუტურ გზებს შეიცავს, ამიტომ შენს ლეპტოპზე გენერირებული და ატვირთული ქეშები შეიძლება სერვერზე არარსებულ საქაღალდეებზე მიუთითებდეს.

შეინახე ბოლო მუშა რელიზი. ყველაზე სწრაფი უკან დაბრუნება წინა საქაღალდე პლუს migrate:rollback-ია, რომელიც რეალურად გამოგიცდია, მეორე ყველაზე სწრაფი კი ხუთი წუთის წინ გაკეთებული backup-იდან აღდგენაა. Zero-downtime დეპლოი პატარა სერვერზე აღწერს symlink-ებიან რელიზების მოდელს, როცა გინდა, რომ თავად დეპლოი უხილავი იყოს.

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

ცარიელი გვერდი ან შიშველი 500 დეტალების გარეშე. ეს APP_DEBUG=false-ია, რომელიც თავის საქმეს აკეთებს. დეტალები storage/logs/laravel.log-შია. თუ ეს ფაილი ცარიელია, PHP-ს მასში ჩაწერა ვერ შეძლო: შეამოწმე ზემოთ მოცემული უფლებები და PHP-FPM-ის error ლოგი.

"No application encryption key has been specified". APP_KEY არ არის ან config ქეში მის გაჩენამდე აიგო. გაუშვი php artisan key:generate --force, მერე ისევ php artisan config:cache.

ყველაფერი 404-ს აბრუნებს მთავარი გვერდის გარდა. document root არ არის public/ ან nginx-ს location ბლოკში არ აქვს ხაზი try_files $uri $uri/ /index.php?$query_string;.

419 Page Expired ყველა ფორმაზე. session cookie უკან არ ბრუნდება. ჩვეულებრივი მიზეზები: SESSION_DOMAIN არასწორ host-ზეა დაყენებული, SESSION_SECURE_COOKIE=true, სანამ აპლიკაცია ფიქრობს, რომ HTTP-ზეა, ან სხვა გარემოდან მოსული დაქეშილი config.

პარამეტრის ცვლილება არაფერს ცვლის. config ქეში მოძველებულია. php artisan optimize:clear, შემდეგ ხელახლა აგება. ეს .env-ის რედაქტირებასაც ეხება: config დაქეშილი რომ არის, .env მოთხოვნის დროს საერთოდ არ იკითხება.

ატვირთული სურათები 404-ს აბრუნებს, მაგრამ დისკზეა. public/storage symlink გაქრა. ხელახლა გაუშვი php artisan storage:link.

queue დეპლოის შემდეგ არაფერს ამუშავებს. worker მოკვდა და არავინ გადაუტვირთავს, ან ისევ ძველ კოდს იჭერს. შეამოწმე, პროცესი ცოცხალია თუ არა, მერე php artisan queue:restart.

საიტი დატვირთვისას ნელდება და მერე restart-ს გადის. მეხსიერების ლიმიტამდე ხარ მისული. RE:NODE-ზე container ლიმიტზე ჩერდება და სუფთად გადაიტვირთება და არ რჩება swap-ზე, რაც უფრო სწრაფად გამოჯანმრთელდება, თუმცა ნიშნავს, რომ მიმდინარე მოთხოვნები იკარგება. სანამ framework-ს დაადანაშაულებ, დათვალე PHP-FPM worker-ები გამრავლებული მათ რეალურ მეხსიერების მოხმარებაზე და წაიკითხე ვებ აპლიკაციის ზომა გაშვების დღისთვის.

FAQ#

მჭირდება თუ არა Composer სერვერზე დაყენებული?

აუცილებლად არა. შეგიძლია composer install --no-dev --optimize-autoloader ლოკალურად ან CI-ში გაუშვა და vendor საქაღალდე ატვირთო, სანამ PHP-ის ვერსია, რომლის წინააღმდეგაც ააგე, სერვერზე არსებულს ემთხვევა. სერვერზე გაშვება უფრო მარტივია და ამ შეუსაბამობას გვერდს უვლის.

რატომ აბრუნებს env() null-ს production-ზე?

იმიტომ, რომ config დაქეშილია. php artisan config:cache ერთხელ წყვეტს ყველა env() გამოძახებას config/-ის შიგნით და შედეგს წერს, ხოლო ამ ფაილების გარეთ env() გარემოს კითხულობს, რომელიც აღარ არის შევსებული. მნიშვნელობა გადაიტანე config ფაილში და config()-ით წაიკითხე.

რამდენი მეხსიერება სჭირდება Laravel საიტს?

პატარა აპლიკაცია 1 GB-ში კომფორტულადაა, PHP-FPM worker-ებისა და იმავე მანქანაზე არსებული ბაზის ჩათვლით. მეხსიერება დაამატე, როცა პარალელურობას ამატებ და არა ფუნქციებს: ყოველი PHP-FPM worker შენი აპლიკაციის საკუთარ ასლს ინახავს, ამიტომ ოთხი worker 80 MB-ით 320 MB-ია, სანამ რამე სხვა ჩაითვლება.

შემიძლია scheduler-ის გაშვება cron-ის გარეშე?

დიახ. php artisan schedule:work წინა პლანზე მუშაობს და ყოველ წუთს ჩართავს ამოცანებს, რომელთა დროც დადგა, რაც პრაქტიკული პასუხია ჰოსტინგზე, სადაც crontab-ის რედაქტირება არ შეგიძლია. ის უნდა ინახებოდეს გაშვებული, ისევე როგორც ნებისმიერი სხვა გრძელვადიანი პროცესი.

უნდა იზიარებდეს თუ არა queue worker და ვებ სერვერი ერთ გეგმას?

პატარა საიტისთვის - დიახ, უქმად მყოფი worker თითქმის არაფერი ჯდება. გაყავი, როცა დავალება იმდენად მძიმეა, რომ ვებ მოთხოვნებს CPU-ს ართმევს, რადგან queue-ს ნახტომი და ტრაფიკის ნახტომი ერთად რომ მოდის, ასე ვარდება ერთ-container-იანი კონფიგურაცია.

რა ვქნა .env-თან, როცა ჰოსტს ვცვლი?

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