پیکربندی متغیرهای محیطی

فهرست مطالب:

• خلاصه
  • مسئله
  • تصمیم
  • وضعیت
• جزئیات
  • مفروضات
  • قیود
  • مواضع
  • استدلال
  • پیامدها
• مرتبط
  • تصمیمات مرتبط
  • الزامات مرتبط
  • مصنوعات مرتبط
  • اصول مرتبط
• توضیحات

خلاصه

مسئله

می‌خواهیم برنامه‌های ما فراتر از مصنوعات/فایل‌های دودویی/کد منبع پیکربندی‌پذیر باشند، به‌گونه‌ای که یک ساخت بسته به محیط استقرار خود رفتار متفاوتی داشته باشد.

• برای این کار می‌خواهیم از پیکربندی متغیرهای محیطی استفاده کنیم.

• می‌خواهیم پیکربندی را با استفاده از فایل‌هایی مدیریت کنیم که بتوانیم آن‌ها را تحت کنترل نسخه قرار دهیم.

• می‌خواهیم کمی راحتی تجربهٔ توسعه‌دهنده فراهم کنیم، مانند دانستن اینکه چه چیزی قابل پیکربندی است و مقادیر پیش‌فرض مرتبط کدام‌اند.

تصمیم

فایل‌های .env همراه با فایل پیش‌فرض مرتبط و فایل طرح‌واره انتخاب شد.

وضعیت

تصمیم گرفته شد. برای بررسی قابلیت‌های جدید هنگام پیدایش‌شان آماده‌ایم.

جزئیات

مفروضات

جداسازی کد برنامه و کد محیط را ترجیح می‌دهیم. فرض می‌کنیم برنامه باید در محیط‌های مختلف، مانند محیط توسعه، محیط آزمون، محیط نمایش، محیط تولید و غیره، متفاوت کار کند.

شیوهٔ صنعتی «12 factor app» و حتی بیشتر شیوهٔ مرتبط «15 factor app» را ترجیح می‌دهیم.

بسیاری از پروژه‌های قبلی ما از قرارداد یک فایل .env یا پوشهٔ مشابه .env استفاده کرده‌اند. شیوهٔ معمول این است که این‌ها را از کنترل نسخه دور نگه می‌دارند و در عوض از روش دیگری برای استقرار، نسخه‌گذاری و مدیریت آن‌ها استفاده می‌کنند.

قیود

می‌خواهیم رازها را از سیستم کنترل نسخه (VCS) مدیریت کد منبع (SCM) خود دور نگه داریم.

می‌خواهیم سازگاری با چارچوب‌ها و کتابخانه‌های نرم‌افزاری محبوب را هدف بگیریم. برای مثال، Node ماژولی به نام "dotenv" برای خواندن پیکربندی متغیرهای محیطی دارد.

مواضع

چند رویکرد را بررسی کردیم:

• ذخیرهٔ پیکربندی در برنامه، مثلاً در یک فایل config.js.

• ذخیرهٔ پیکربندی در محیط، مثلاً در یک فایل .env.

• دریافت پیکربندی از یک مکان شناخته‌شده، مانند سرور مجوز.

استدلال

رویکرد فایل .env را انتخاب کردیم زیرا:

• محبوب است، از جمله در میان کارشناسان.

• از الگوی فایل‌های .env پیروی می‌کند که تیم‌های ما بارها در پروژه‌های بسیار با موفقیت از آن استفاده کرده‌اند.

• ساده است. به‌ویژه، فعلاً با مصالحه‌های چشمگیری که می‌بینیم مشکلی نداریم، مانند نبود قابلیت‌های ممیزی در مقایسه با رویکرد سرور مجوز.

پیامدها

باید راهی بیابیم تا پیکربندی متغیرهای محیطی عمومی را از مدیریت هر راز جدا کنیم.

مرتبط

تصمیمات مرتبط

انتظار داریم همهٔ برنامه‌های ما از این رویکرد استفاده کنند.

برنامه‌ریزی می‌کنیم هر برنامه‌ای را که از رویکرد کم‌توانمندتر، مانند کدنویسی سخت در یک فایل دودویی یا در کد منبع، استفاده می‌کند ارتقا دهیم.

هر برنامه‌ای را که از رویکرد توانمندتر، مانند سرور مجوزدهی، استفاده می‌کند همان‌گونه که هست نگه می‌داریم.

الزامات مرتبط

قابلیت‌های devops برای فایل‌ها، از جمله hookها، آزمون‌ها و یکپارچه‌سازی پیوسته، اضافه خواهیم کرد.

باید همهٔ هم‌تیمی‌های توسعه‌دهنده را دربارهٔ این تصمیم آموزش دهیم.

مصنوعات مرتبط

هر محیطی که در آن مستقر می‌کنیم فایل .env و فایل‌های مرتبط خود را لازم خواهد داشت.

اصول مرتبط

به‌آسانی برگشت‌پذیر.

توضیحات

نمونه فایل .env:

NAME=Alice Anderson
EMAIL=alice@example.com

نمونه فایل .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

نمونه فایل .env.schema فقط با کلیدها:

NAME
EMAIL