- چهارشنبه 9 آبان 1397 ساعت 18:53
- 5.6.29
- در حال تکمیل
- منقضی شده
مقدمه
تمامی فایلهای مربوط به پیکربندی فریمورک لاراول، در دایرکتوری config قرار دارند. همه آپشنها مستندسازی شدهاند، در صورت تمایل و برای آشنایی بیشتر با آپشنهای در دسترس، به این فایلهایی نگاهی بیندازید.
پیکربندی محیط
در اغلب مواقع، بسته به محیطی که اپلیکشن در آن اجرا میشود، داشتن مقادیر پیکربندی بسیار سودمند است. برای مثال، شاید بخواهید در محیط لوکال، از درایور کش متفاوتی نسبت به محیط پروداکشن سرور خود استفاده کنید.
برای اینکه اینکار را به راحتی انجام دهید، لاراول از لایبرری PHP با نام DotEnv استفاده میکند که توسعهدهنده آن Vance Lucas است. هنگامی که یک نسخه جدید از لاراول را نصب میکنید، دایرکتوری root اپلیکیشن شما، حاوی یک فایل با نام خواهد .env.example
بود. اگر لاراول را به وسیله کامپوزر نصب کنید، این فایل به صورت خودکار به .env
تغییر نام خواهد داد، در غیر این صورت، نام این فایل را باید به صورت دستی تغییر دهید.
فایل .env
نباید به سورسکنترلِ اپلیکیشن شما کامیت شود، زیرا هر دولوپر یا سروری که از اپلیکیشن شما استفاده میکند، ممکن است به یک پیکربندی محیط متفاوتی نیاز داشته باشد، علاوه بر این، در صورتی که یک مزاحم به ریپازیتوری سورسکنترل شما دسترسی بیاید، وجود این فایل میتواند موجب ریسک امنیتی باشد، زیرا هر اطلاعات دارای اعتبار و حساسی در معرض افشاء خواهند بود.
اگر دولوپری هستید که در یک تیم مشغول هستید، ممکن است تمایل داشته باشید تا کماکان فایل .env.example
را در اپلیکیشن خود قرار دهید. با قرار دادن مقادیر پلیسهولدر در فایل پیکربندی نمونه، سایر توسعهدهندههای تیم میتوانند به وضوح بفهمند که کدام متغییرهای محیطی، برای اجرای اپلیکیشن شما مورد نیاز هستند. همچنین میتوانید یک فایل .env.testing
بسازید. هنگام اجرای کامندهای آرتیسان که از آپشن --env=testing
استفاده میکنند و در هنگام اجرای تستهای PHPUnit، مقادیر این فایل به جای مقادیر فایل .env
استفاده (بازنویسی) میشود.
توجه
هر متغییری در فایل .env
میتواند توسط متغییرهای محیطی خارجی، مانند متغییرهای محیطی سطح سیستم (server-level) یا سطح سرور (system-level) بازنویسی شود.
انواع متغییرهای محیطی
تمام متغییرهای موجود در فایلهای .env
شما، مانند استرینگها پارس میشوند، بنابراین برخی مقادیر رزرو شده ایجاد شدهاند تا به شما این امکان را بدهند تا رنج وسیعتری از نوعها را از فانکشن env()
برگردانید:
.env مقدار |
env() مقدار |
---|---|
true |
(bool) true |
(true) |
(bool) true |
false |
(bool) false |
(false) |
(bool) false |
empty |
(string) '' |
(empty) |
(string) '' |
null |
(null) null |
(null) |
(null) null |
اگر نیاز است که متغییری محیطی تعریف کنید که حاوی اسپیس است، اینکار را با قرار دادن مقدار در دابل کوتیشن میتوانید انجام دهید.
بازیابی پیکربندی محیطی
هنگامی که اپلیکیشن شما یک ریکوئست دریافت میکند، تمامی متغییرهای لیست شده در این فایل، در آرایه سوپرگلوبال $_ENV
لود خواهند شد. گرچه، برای دریافت مقادیر از این متغییرها در فایلهای پیکربندی خود، میتوانید از هلپر env
استفاده کنید. در واقع، اگر مروری بر فایلهای پیکربندی لاراول داشته باشید، ملاحظه خواهید کرد که آپشنهای مختلفی درحال استفاده از این هلپر هستند.
دومین مقداری که به این فانکشن پاس داده میشود، مقدار پیشفرض است. این مقدار در صورتی استفاده میشود که برای کلید داده شده، هیچ متغییر محیطی وجود نداشته باشد.
مشخص کردن محیط کنونی
محیط کنونی اپلیکیشن، به وسیله متغییر APP_ENV
موجود در فایل .env
مشخص میشود. با استفاده از متد environment
از فساد App
،میتوانید به این مقدار دسترسی داشته باشید:
همچنین میتوانید آرگومانهایی را به متد environment
پاس دهید، تا بدین وسیله بررسی کنید که آیا محیط با مقدار داده شده مطابقت دارد یا خیر. اگر محیط با هر کدام از مقادیر داده شده مطابقت داشته باشد، مقدار بازگشتی متد true
خواهد بود:
توجه
تشخیص محیط جاری اپلیکیشن، ممکن است توسط یک متغییر محیطی APP_ENV
سطح سرور بازنویسی شود. هنگامی که نیاز به اشتراکگذاری یک اپلیکیشن برای پیکربندیهای محیطی مختلف دارید، این بازنویسی بسیار مفید است، بنابراین میتوانید میزبانی مشخص را برای مطابقت دادن یک محیط مشخص در پیکربندیهای سرور خود تنظیم کنید.
دسترسی به مقادیر پیکربندی
با استفاده از هلپرفانکشن گلوبال config
، به راحتی میتوانید از هر جایی در اپلیکیشن خود، به مقادیر پیکربندیهای خود دسترسی داشته باشید. مقادیر پیکربندی میتوانند به وسیله سینتکس "نقطه"، در دسترس باشند، که شامل نام فایل و آپشنی است که میخواهید به آن دسترسی داشته باشید. همچنین مقدار پیشفرضی را نیز میتوانید مشخص کنید که اگر آپشن پیکربندی وجود نداشته باشد، آن مقدار استفاده میشود.
برای سِت کردن مقادیر پیکربندی در زمان اجرا، یک آرایه به هلپر config
پاس دهید:
کش کردن پیکربندی
برای افزایش دادن سرعت اپلیکیشن خود، باید تمام فایلهای پیکربندی خود را با استفاده از کامند آرتیسان config:cache
، در یک فایل کش کنید. این کامند، تمام آپشنهای پیکربندی اپلیکیشن شما را ترکیب کرده و در یک فایل قرار میدهد که توسط فریمورک سریعتر لود خواهد شد.
معمولا باید کامند php artisan config:cache
را به عنوان بخشی از روال دپلوی محصول خود اجرا کنید. این کامند در حین توسعه لوکال نباید اجرا شود، زیرا در طول توسعه اپلیکیشن خود، آپشنهای پیکربندی بارها نیاز به تغییر دارند.
توجه
اگر در طول پروسه دپلوی، کامند config:cache
را اجرا کنید، باید اطمینان حاصل کنید که فقط فانکشن env
را از داخل فایلهای پیکربندی خود فراخوانی میکنید. هنگامی که پیکربندی کش شد، فایل .env
لود نخواهد شد و تمام فراخوانیها به وسیله فانکشن env
مقدار null
را باز خواهد گرداند.
حالت تعمیر و نگهداری
هنگامی که اپلیکیشن شما در حالت تعمیر و نگهداری باشد، برای تمام ریکوئستهایی که به اپلیکشن شما ارسال میشوند، یک ویو سفارشی نمایش داده خواهد شد. این کار هنگامی که اپلیکیشن در حال آپدیت است یا هنگامی که در حال اجرای تعمیر و نگهداری هستید، غیرفعالسازی اپلیکیشن را ساده میسازد. بررسی حالت تعمیر و نگهداری در استک میدلور پیشفرض اپلیکیشن شما گنجانده شده است. اگر اپلیکیشن در حالت تعمیر و نگهداری باشد، یک اکسپشن MaintenanceModeException
با کد 503 رخ خواهد داد.
برای فعالسازی حالت تعمیر و نگهداری، کامند آرتیسان down
را اجراکنید:
آپشنهای message
و retry
را نیز میتوانید برای کامند down
استفاده کنید. مقدار message
میتواند برای نمایش یا لاگ کردن یک پیام سفارشی استفاده شود، در حالی که مقدار retry
به عنوان مقدار هدر اچتیتیپیRetry-After
سِت خواهد شد.
با استفاده از آپشن allow
کامند مذکور، حتی هنگامی که اپلیکیشن در حالت تعمیر و نگهداری است نیز آدرسهای IP یا شبکههای خاص، میتوانند اجازه دسترسی به اپلیکیشن را داشته باشند:
برای غیرفعالسازی حالت تعمیر و نگهداری، از کامند up
استفاده کنید:
توجه
با تعریف تمپلت خودتان در resources/views/errors/503.blade.php
میتوانید تمپلت پیشفرض حالت تعمیر و نگهداری را سفارشی کنید.
حالت تعمیر و نگهداری و صفها
هنگامی که اپلیکیشن شما در حالت تعمیر و نگهداری است، هیچ کیوجابی هندل نخواهد شد. هنگامی که اپلیکیشن از حالت تعمیر و نگهداری خارج شود، هندل کردن جابها به صورت طبیعی ادامه خواهد یافت.
جایگزینهای حالت تعمیر و نگهداری
از آنجایی که حالت تعمیر و نگهداری، اپلیکیشن شما را مجبور مینماید تا چندین ثانیه دانتایم داشته باشد، جایگزینهایی مانند Envoyer را بررسی کنید تا به دانتایم صفر در دپلوی اپلیکیشن لاراولی خود دست یابید.
سایر پستهای داکیومنت
- پیشگفتار
- Release Notes ترجمه در ورژنهای بعدی
- راهنمای آپگرید ترجمه در ورژنهای بعدی
- Contribution Guide ترجمه در ورژنهای بعدی
- شروع
- نصب
- پیکربندی
- ساختار دایرکتوری ترجمه در ورژنهای بعدی
- Laravel Homestead ترجمه در ورژنهای بعدی
- Laravel Valet ترجمه در ورژنهای بعدی
- دپلویمنت ترجمه در ورژنهای بعدی
- مفاهیم معماری
- چرخه کار ریکوئستها
- Service Container ترجمه در ورژنهای بعدی
- سرویس پرووایدرها
- فسادها ترجمه در ورژنهای بعدی
- Contracts ترجمه در ورژنهای بعدی
- اصول اولیه
- مسیریابی
- میدلور
- حفاظت در مقابل حملات CSRF
- کنترلرها
- HTTP Requests ترجمه در ورژنهای بعدی
- HTTP Responses ترجمه در ورژنهای بعدی
- ویوها
- تولید URL
- HTTP Session ترجمه در ورژنهای بعدی
- Validation ترجمه در ورژنهای بعدی
- Error Handling ترجمه در ورژنهای بعدی
- Logging ترجمه در ورژنهای بعدی
- فرانتاند
- تمپلتهای Blade
- محلیسازی
- JavaScript & CSS Scaffolding ترجمه در ورژنهای بعدی
- Compiling Assets (Laravel Mix) ترجمه در ورژنهای بعدی
- امنیت
- Authentication ترجمه در ورژنهای بعدی
- API Authentication (Passport) ترجمه در ورژنهای بعدی
- Authorization ترجمه در ورژنهای بعدی
- Encryption ترجمه در ورژنهای بعدی
- Hashing ترجمه در ورژنهای بعدی
- Resetting Passwords ترجمه در ورژنهای بعدی
- مباحث عمیقتر
- Artisan Console ترجمه در ورژنهای بعدی
- Broadcasting ترجمه در ورژنهای بعدی
- Cache ترجمه در ورژنهای بعدی
- Collections ترجمه در ورژنهای بعدی
- Events ترجمه در ورژنهای بعدی
- File Storage ترجمه در ورژنهای بعدی
- Helpers ترجمه در ورژنهای بعدی
- Mail ترجمه در ورژنهای بعدی
- Notifications ترجمه در ورژنهای بعدی
- Package Development ترجمه در ورژنهای بعدی
- Queues ترجمه در ورژنهای بعدی
- Task Scheduling ترجمه در ورژنهای بعدی
- دیتابیس
- دیتابیس: شروع ترجمه در ورژنهای بعدی
- Database: Query Builder ترجمه در ورژنهای بعدی
- دیتابیس: صفحهبندی
- دیتابیس: مایگریشن
- دیتابیس: سیدینگ
- Redis ترجمه در ورژنهای بعدی
- Eloquent ORM
- Eloquent: Getting Started ترجمه در ورژنهای بعدی
- Eloquent: Relationships ترجمه در ورژنهای بعدی
- Eloquent: Collections ترجمه در ورژنهای بعدی
- Eloquent: Mutators ترجمه در ورژنهای بعدی
- Eloquent: API Resources ترجمه در ورژنهای بعدی
- Eloquent: Serialization ترجمه در ورژنهای بعدی
- Testing
- Testing: Getting Started ترجمه در ورژنهای بعدی
- HTTP Tests ترجمه در ورژنهای بعدی
- Browser Tests (Laravel Dusk) ترجمه در ورژنهای بعدی
- Database Testing ترجمه در ورژنهای بعدی
- Mocking ترجمه در ورژنهای بعدی
- Official Packages
- Laravel Cashier ترجمه در ورژنهای بعدی
- Envoy Task Runner ترجمه در ورژنهای بعدی
- Laravel Horizon ترجمه در ورژنهای بعدی
- API Authentication (Passport) ترجمه در ورژنهای بعدی
- Laravel Scout ترجمه در ورژنهای بعدی
- Laravel Socialite ترجمه در ورژنهای بعدی