برنامه ۱۲ عاملی (۴)- عامل سوم: پیکربندی
عامل ۳: پیکربندی
پیکربندی (config) را در محیط استقرار (environment) ذخیره کنید

پیکربندی هر برنامه احتمالاً برای استقرارهای مختلف (محیط عملیاتی یا production، محیط داخلی یا stage، محیط‌ توسعه‌دهندگان و غیره) یکسان نیست. این تفاوت می‌تواند به دلایل متفاوتی از جمله موارد زیر باشد:
– منابع دسترسی به پایگاه داده، حافظه‌های ذخیره‌سازی سریع (Memcached) و سایر خدمات پشتیبان (backing services) سرویس‌دهنده‌
– اعتبارنامه (Credentials) برای خدمات خارجی مانند Amazon S3 یا Twitter
– مقادیری مانند نام مستعار میزبان (canonical hostname یا cname) برای هر استقرار

گاهی اوقات پیکربندی به صورت مقادیر ثابتی (constants) در خود کد نوشته می‌شود. چنین کاری نقض اصول برنامه‌های دوازده عاملی است که در آن، جداسازی کامل و دقیق پیکربندی از کد الزامی است. پیکربندی نسخه‌های مختلف استقرار (عملیاتی، داخلی، توسعه‌دهندگان) با هم تفاوت جدی دارند در حالی که کد این نسخه‌ها معمولا یکسان است. یک آزمایش ساده برای کسب اطمینان از جداسازی درست پیکربندی از کد برنامه این است که بررسی کنید آیا بدون در اختیار دادن اعتبارنامه‌ها (credentials) می‌توان کد برنامه را در همان لحظه به یک کد متن‌باز تبدیل کرد و در اختیار همه قرار داد.

دقت کنید که تعریف ما از “پیکربندی” شامل پیکربندی داخلی برنامه [مثلا پیکربندی ارتباط بین ماژول‌ها و مولفه‌های برنامه] نمی‌شود. این نوع پیکربندی در استقرار‌ها متفاوت نیست در نتیجه بهتر است در خود کد نگهداری و مدیریت شود.

رویکرد دیگر مدیریت پیکربندی، استفاده از فایل‌های پیکربندی (config files) است که در مخزن کد (repo) قرار نمی‌گیرند. چنین رویکردی در مقایسه با نوشتن پیکربندی در کد به کمک تعریف مقادیر ثابت، پیشرفت بزرگی محسوب می‌شود، هر چند این روش نیز ایراداتی دارد. احتمال اشتباه و قراردادن فایل پیکربندی در مخزن کد بسیار بالا است. احتمال پراکنده شدن فایل‌های پیکربندی در جاهای مختلف و با قالب‌های (format) متفاوت زیاد است. چنین اتفاقی مدیریت فایل‌های پیکربندی‌ و یکسان‌سازی آنها را دشوار می‌کند. معمولا قالب‌(formats) هر یک از این فایل‌های پیکربندی مختص زبان یا چارچوب متفاوتی است که مدیریت آنها را دشوارتر می‌کند.

هر برنامه دوازده عاملی پیکربندی را در متغیرهای محیط (environment variables) ذخیره می‌کند (به صورت اختصار env vars یا env نامیده می‌شوند). متغیرهای محیطی (env vars) را بدون آن که نیازی به تغییر کد باشد، به راحتی می‌توان برای هر استقرار تغییر داد. در مقایسه با فایل‌های پیکربندی، احتمال قرار گرفتن اشتباهی آنها در مخزن کد نیز کمتر است. و برخلاف فایل‌های پیکربندی خاص‌منظوره یا مکانیزم‌های پیکربندی خاص هر زبان‌ برنامه‌نویسی، این متغیرها مستقل از استاندارد زبان و سیستم عامل تعریف می‌شوند.

گروه‌بندی یکی دیگر از موضوعات مدیریت پیکربندی (config) است. گاهی‌ افراد متغیرهای پیکربندی را در قالب گروه‌هایی دسته‌بندی می‌کنند که نام آنها ترکیبی است از انواع استقرار (development, test, ,production) و کلمه‌ی environments . چنین روشی مقیاس‌پذیر نیست زیرا با اضافه شدن انواعی جدیدی از استقرار مانند staging یا qa به نام‌های جدیدی برای محیط‌ها نیاز خواهیم داشت. حتی احتمالا با رشد پروژه و ورود توسعه‌دهندگان جدید، هر فردی محیط‌ دلخواه و مورد نیازش را به فهرست محیط‌های قبلی اضافه خواهد کرد (مانند smith-qa یا smith-development). چنین اتفاقی باعث رشد نمایی و انفجار تعداد پیکربندی‌ها (config) می‌شود و عملا مدیریت استقرار را پراشتباه و فلج می‌نماید.

در هر برنامه دوازده عاملی، هر متغیر محیطی (environment variables یا env vars) مانند یک واحد کنترل‌کننده کوچک است که هیچ ارتباط یا وابستگی به بقیه متغیرهای محیطی ندارد. هرگز نباید تعدادی از آنها را تحت عنوان یک محیط جدید (environment) با هم دسته‌بندی کنید. بلکه باید تک‌تک آنها را هر نسخه از استقرار مقدار دهی و مدیریت کنید. با رشد طبیعی برنامه و افزایش نسخه‌های استقراریافته‌ی آن، این مدل نیز می‌تواند پا به پای آن رشد کند و به بالندگی برسد.

پانوشت:
استقلال یا orthogonal بودن دو متغیر محیطی (env var) به چه معناست؟
orthogonal به این معناست که دو متغیر محیطی می‌توانند مستقل از همدیگر تغییر کنند و تغییر یکی لزوما منجر به تغییر دیگری نمی‌شود. در نتیجه هنگام انتخاب متغیرهای محیطی باید بدون در نظر گرفتن محیط‌های استقرار (مانند development, test, and production)، یک سری از متغیرها را شناسایی و به عنوان متغیر محیطی تعریف کرد

https://www.bibalan.com/?p=3904
https://t.me/bibalan_com