با سلام و درود، با قسمت دوم از آشنایی با فاکتورهای ۱۲ گانه اپلیکیشن در خدمتتان هستم (۱۲-فاکتور اپلیکیشن یا The twelve-factor app ) . در قسمت قبلی با فاکتور های اول تا سوم آشنا شدیم که به شرح زیر بودند:
فاکتور اول: codebase – پایگاه کد
یک codebase در کنترل revision ردیابی می شود و بسیاری از آنها مستقر (deploy) می شوند.
به طور خلاصه، یه کدبیس خواهیم داشت و همان را در چند جا مستقر می کنیم.
فاکتور دوم: Dependencies – وابستگی ها
به صورت صریح . ایزوله، dependency ها مشخص می شوند
فاکتور سوم: config – کانفیگ
کانفیگ در محیط هر استقرار نگه داری شود، ترجیحا از متغیرهای محیط استفاده شود.
برای مطالعه کامل تر روی ۳ فاکتور نخست از فاکتورهای دوازده گانه اپلیکیشن، پیشنهاد می کنم قسمت اول ( آشنایی با ۱۲-فاکتور اپلیکیشن (The twelve-factor app) فاکتور های اول تا سوم ) از این مطلب را حتما نگاه بندازید.
در ادامه به فاکتورهای چهارم الی ششم می پردازیم.
فاکتور چهارم: Backing services -سرویس های پشتی
خدمات پشتیبان، به عنوان منابع پیوستی تلقی شوند.
یک سرویس پشتیبان (پشتی یا Backing)، هر سرویسی است که برنامه (app) از طریق شبکه از آن به عنوان بخشی از عملکرد عادی خود استفاده می کند. به عنوان مثال، پایگاه های ذخیره داده (مانند MySQL یا CouchDB)، سیستم های پیام دهی و صف دهی (مانند RabbitMQ یا Beanstalkd)، سرویس های SMTP برای خروجی ایمیل (مانند Postfix) و سیستم های کش (مانند Memchached).
سرویس های Backingمانند پایگاه داده به طور سنتی توسط همان مدیران سیستم که app را برای اجرا مستقر می کنند، مدیریت می شوند. علاوه بر این خدماتی که به صورت محلی (locally) مدیریت می شوند، app ممکن است خدمات و سرویس هایی داشته باشد که توسط اشخاص ثالث فراهم و مدیریت می شوند. به عنوان مثال می توان به خدمات SMTP (مانند Postmark)، سرویس های metrics-gathering (مانند New Relic یا Loggly )، خدمات binary asset (مانند Amazon S3) و هر سرویسی که به صورت API به آن به صورت مشتری دسترسی داریم (مانند توییتر، Goole Maps و …).
کد یک برنامه ۱۲ عاملی (twelve-factor app)، هیچ تمایزی بین سرویس های لوکال و شخص ثالث ایجاد نمی کند. هر دو منابع به برنامه توسط URL یا locator/credentials ذخیره شده در config پیوست شده اند. اسقرار یک برنامه ۱۲ فاکتوری باید بتواند بدون هیچ تغییری در کد برنامه، پایگاه داده را از MySQL به پایگاه داده شخص ثالثی مانند Amazon RDS تعویض کند. به همین ترتیب یک سرور SMTP لوکال را می توان با یک سرویس شخص ثالث SMTP (مانند Postmark) بدون تغییر در کد، تعویض کرد. در هر دو حالت مطرح شده، فقط مدیر منبع در کانفیگ نیاز به تغییر دارد.
هر سرویس پشتیبان یک منبع (resource) می باشد. برای مثال، یک MySQL database یک منبع است، دو تا پایگاه داده MySQL (استفاده شده برای sharding در لایه اپلیکیشن) به عنوان دو منبع مجزا واجد شرایط هستند. برنامه دوازده عاملی این پایگاه داده ها را به عنوان منابع پیوستی در نظر می گیرد، که نشان دهنده اتصال ضعیف آنها به استقراری است که به آن متصل شده اند.
منابع (resource) را می توان به دلخواه به استقرارها پیوست داده شوند یا از آنها جدا کرد. برای مثال، اگر پایگاه داده برنامه به دلیل مشکل سخت افزاری دارای عیب است، مدیر برنامه ممکن است پایگاه داده جدیدی را که از یک بکآپ جدید بازیابی شده است را به کار اندازد. پایگاه داده production فعلی را می توان جدا کرد و پایگاه داده جدید را بدون هیچ تغییر در کد، پیوست کرد.
فاکتور پنجم: Build, release, run ، ساخت، انتشار، اجرا
مراحل ساخت و اجرا را کاملا جدا کنید
یک codebase از طریق سه مرحله به یک استقرار-deploy (غیر توسعه‌ای) تبدیل می‌شود:
- مرحله ساخت – build stage : یک تبدیل است که یک codebase را به یک باندل اجرایی (executable bundle) که با build شناخته می شود تبدیل می کند. استفاده از یک ورژن از کد توسط فرآیند استقرار، مرحله build به واکشی (fectch) کردن vendors dependencies و کامپایل کردن binaries و assets ها می پردازد.
- مرحله انتشار – stage build: این مرحله build تولید شده توسط مرحله build را گرفته و آن را با کانفیگ فعلی deploy ترکیب می کند. نسخه بدست آمده شامل buildو config می باشد و آماده اجرای فوری در محیط اجرا می باشد.
- مرحله اجرا – run stage : همچنین runtimeهم شناخته می شود، app را در محیط اجرا،با راه اندازی مجموعه ای از فرآیند های app در برابر نسخه انتخاب شده اجرا می کند.
یک برنامه دوازده عاملی، از جدا سازی دقیق بین مراحل ساخت، انتشار و اجرا استفاده می کند. به عنوان مثال تغییرات در کد در زمان اجرا غیر ممکن است، زیرا هیچ راهی برای انتشار آن تغییرات به مرحله ساخت وجود ندارد.
ابزارهای استقرار معمولا ابزارهای مدیریت انتشار را پیشنهاد می کنند، که مهمترین آن قابلیت بازگشت به نسخه قبلی است. به عنوان مثال ابزار استقرار Capistrano نسخه ها را در زیر شاخه ای به نام انتشارات- releases دخیره می کند، جایی که نسخه فعلی یک symlinkبه دایرکتوری نسخه فعلی است. دستور rollback آن، کار بازگشت به نسخه قبلی منتشر شده را آسان و سریع کرده است.
هر نسخه انتشار باید یک شناسه انتشار داشته باشد، مانند برچسب تاریخ و زمان انتشار (مانند 2011-04-06-20:32:17) یا یک عدد افزایشی (مانند V105). نسخه ها را پس از ساخت نمی توان تغییر داد. هر تغییر باید منجر به ایجاد یک انتشار جدید شود.
هر زمانی که کد جدیدید مستقر شود، build ها توسط دولوپر ها آعاز می شوند. در مقابل، زمان اجرا (Runtime execution) می تواند به صورت خودکار اتفاق بیافتد، در مواردی مانند ریبوت شدن سرور یا یک زمانی که یک فرآیند خراب منجر به ریست توسط مدیر فرآیند شود. بنابراین، مرحله اجرا باید تا حد امکان در قسمت های متحرک کمتری نگه داشته شود، زیرا مشکلاتی که مانع از اجرای app می شوند، می توانند در نیمه شب که هیچ توسعه دهنده ای در دسترس رخ دهند و سیستم را خراب کنند. مرحله ساخت می تواند پیچیده تر باشد، زیرا ارورها همیشه در پیش زمینه توسعه دهنده که استقرار را هدایت می کند، می باشند.
Best CI/CD Tools
فاکتور ششم: Processes -فرآیندها
app را به عنوان یک یا چند فرآیند بدون حالت (stateless) اجرا کنید.
در ساده ترین حالت، کد یک اسکریپت مستقل است، محیط اجرا یک لپتاپ محلی خود توسعه دهنده است که language runtime روی آن نصب شده است، و فرآیند توسط command line راه اندازی شده است (برای مثال با دستور python my_script.py) . در طرف دیگر، یک استقرار production از یک برنامه پیچیده ممکن است از چندین نوع فرآیند استفاده کند که در بین صفر یا چند فرآیند اجرا نمونه سازه شده است.
فرآیند های ۱۲ عاملی، بدون حالت هستند (stateless) و چیزی به اشتراک نمی گذارند. هر داده ای که نیاز به ماندگاری دارد باید در یکی سرویس پشتیبان statefullمانند پایگاه داده ذخیره شود.
فضای مموری یا filesystem یک فرآیند می تواند به عنوان یه کش مختصر و تک تراکنشی استفاده شود. برای مثال، دانلود کردن یک فایل بزرگ، عملیات روی آن و ذخیره سازی نتایج عملیات در پایگاه داده. یک نرم افزار twelve-factor هرگز فرض نمی کند که چیزی که روی مموری یا دیسک کش شده است، در request آتی در دسترس خواهد بود – با اجرای چندین فرآیند از هر نوع، احتمال اینکه request آتی توسط یک فرآیند متفاوت ارائه شود، زیاد است.
حتی زمانی که فقط یک فرآیند را اجرا می کنید، یک راه اندازی مجدد (فراخوانی شده با استقرار جدید، تغییر کانفیگ، یا محیط اجرا فرآیند را به مکان فیزیکی دیگری منتقل می کند)، معمولا تمامی وضعیت های لوکال را از بین می برند.
Asset packager هایی مانند django-assetpackager از فایل سیستم به عنوان کش برای کامپایل هردن assets ها استفاده می کند. یک اپلیکیشن twelve-factor ترجیح می دهد این کامپایل را در مرحله build انجام دهد.Asset packager هایی مانند Jammit و Redis را می توان جهت پکیج کردن assets های در طول فرآیند buildکانفیگ کرد.
برخی از سیستم ها وب متکی بر “sticky sessions” هستند، یعنی، کش کردن داده های کاربر در مموری فرآیند app و انتظار میرود requestها آتی از بازدیدکننده یکسان به فرآیند مشابه مسیریابی شود.Sticky session ها نقض کننده twelve-factor می باشند و هرگز نباید از آنها استفاده کرد یا به آنها اعتماد کرد. وضعیت داده session کاندیدای خوبی برای ذخیره سازی داده ای است که دارای انقضای زمانی است مانند memcached یا reids.
خب تا اینجا ۶ فاکتور نخست از فاکتورهای ۱۲ گانه app را با هم مرور کردیم. فاکتور های بعدی ان شاالله بزودی نوشته خواهند شد:)