پیکره‌بندی محیط توسعه وب روی سیستم‌های شخصی - قسمت اول

local development vs virtual machine vs containerاگه توسعه‌دهنده وب هستید و وب‌اپلیکیشن‌هاتون دارن بزرگ می‌شن! یکی از مشکلاتی که حتمن باهاش درگیر شدید یا کم‌کم درگیر خواهید شد مشکل کانفیگ و نگهداری فضای توسعه‌ (برای مثال لپ‌تاپ‌تون) هست.مثلن اگه یه وب‌اپلیکیشنی دارید که با python و فریم‌ورک Django توسعه‌داده شده و پایگاه‌داده‌ش Postgre هست و از Redis برای cache بعضی از داده‌های پر مصرف استفاده می‌کنید و از ELK برای ایندکس مجدد و سرچ دقیق‌تر و مانیتور کردن لاگ‌ها استفاده می‌کنید و برای توسعه و تست کدهاتون همه‌ی اینا رو کنار هم نیاز دارید درگیر این مشکل هستید. یا اگه توی رودمپ پروژه‌تون یه همچین چیزی می‌بینید به‌زودی باهاش درگیر می‌شید.برای کانفیگ و مدیریت محیط توسعه‌ای مثل این سه تا گزینه اصلی داریم که در ادامه این مقاله برتری و ضعف‌های هر گزینه رو با هم بررسی می‌کنیم و آخر دست با هم مقایسه و جمع‌بندی می‌کنیم.این مقاله-ویدئو قسمت اول از یه سری چند قسمتیه و توی قسمت‌های بعد هر کدوم از این موارد رو تک به تک بررسی می‌کنیم و برای پیاده‌سازیش راهکار می‌دیم و عملی هم با هم بررسی‌شون می‌کنیم. این مقاله و مقالات بعد به همراه ویدئو ارائه می‌شن که در آخر مقاله لینک شده و توضیح مفصل‌تر مواردیه که مکتوب شده.توی این قسمت که قسمت اول از این سری هست سه تا گزینه اصلی که برای کانفیگ و مدیریت محیط توسعه‌ داریم رو بررسی و برتری و ضعف‌های هر گزینه رو با هم مرور می‌کنیم و آخر دست هم جمع‌بندی و نتیجه‌گیری می‌کنیم.سرور محلی (local server)اولین و دم‌دستی‌ترین گزینه احتمالن نصب کردن همه‌ی این ابزارها روی دسکتاپه و تبدیل کردن دسکتاپ به یه سرور محلی. دردسر نسبتا کمی داره و غیر از نصب ابزارها چیز دیگه‌ای هم نیاز نیست بدونیم.خوبی‌هاساده‌گی نصب و راه‌اندازیعدم نیاز به دانش اضافه‌تر از نصب نرم‌افزارهاسرعت بالا در زمان راه اندازی و تستبدی‌ها شلوغی و احتمالن کندی کامپیوتر به‌خاطر انبوه سرویس‌هانیاز به طی تمامی مراحل نصب و راه‌اندازی برای همه اعضای تیمتفاوت بین سیستم‌عامل محلی و سیستم‌عامل سرور که ممکنه باعث بشه بعضی چیزهایی که روی سیستم محلی شما به‌خوبی کار می‌کنه روی سرور مشکل داشته باشه یا بالعکسدردسر زیاد نصب و تست بعضی تکنولوژی‌ها روی دسکتاپ (مثلن HTTPS!)تداخل پروژه‌های مختلف وقتی چندین محصول رو هم‌زمان با یه دستگاه توسعه می‌دید یا نگهداری می‌کنیدماشین مجازی (Virtual Machine)گزینه دوم استفاده از ماشین مجازیه. این‌که برای پروژه‌مون با هر وسیله‌ی مجازی‌ساز متناسب با سیستم‌عامل‌مون یه ماشین مجازی راه‌اندازی کنیم و همه موارد مورد نیاز رو روی اون کانفیگ کنیم و از دسکتاپ‌مون (ماشین میزبان) به عنوان یه کلاینت برای ماشین میهمان استفاده کنیم. با توجه به سیستم‌عامل ابزار‌هایی مثل VMWare و VirtualBox و Parallel و غیره می‌تونن گزینه‌های مناسبی باشند برای این کار. خوبی‌هامی‌تونیم یه محیط خیلی شبیه به سرور پروداکشن رو شبیه‌سازی کنیمهمه اعضای تیم می‌تونن بدون دغدغه کانفیگ چند باره ازش استفاده کنند (البته به شرطی که این کار انجام بشه و درست هم انجام بشه!)تداخل بین پروژه‌ها وجود نداره و شما می‌تونید هر زمان ماشین هر پروژه رو جداگونه راه‌اندازی و استفاده کنیدبدی‌هاسرعت خیلی کم‌تر نسبت به سرور محلیمصرف بیش‌تر منابع سخت‌افزارینیاز به کانفیگ بیش‌تر (توی ویدئو توضیحات بیش‌تری دادم)کانتینر (container)گزینه آخر (در واقع گزینه آخر در این مقاله، که آخرین گزینه موجود نیست و روش‌های دیگه‌ای هم می‌تونه باشه که مورد بحث ما نیست)، استفاده از container هست. تفاوت ماهیتی که بین container و virtual machine وجود داره رو توی ویدئو کامل توضیح دادم که خیلی کمک می‌کنه به درک این بحث.یکی از معروف‌ترین و معمول‌ترین راه‌ها برای پیاده‌سازیش استفاده از Docker و تبدیل کردن سرویس‌ها و بخش‌های مختلف اپلیکیشن به container‌های مبتنی‌بر Docker هست.خوبی‌هامی‌تونیم سرویس‌ها رو مستقیما روی سیستم لوکال نصب نکنیم و فقط image شون رو بگیریم (یا بسازیم) و راه‌اندازی کنیمایزوله‌تر از سرور‌های لوکال هستند و سریع‌تر از ماشین‌های مجازیبه اشتراک گذاشتنش بین اعضای تیم و راه‌اندازیش برای افراد راحتهبدی‌هامدیریت و مخصوصن ساخت‌شون دانش اضافه‌تری نیاز دارهدر سطح اپلیکیشن مجازی می‌شن و بازم به سیستم‌عامل میزبان وابسته هستند (این مورد رو مفصل توی ویدئو توضیح دادم) وقتی تعداد containerها بالاتر می‌ره مدیریت‌شون و ارتباط‌شون سخت‌تر می‌شه و از یه جایی دیگه نمی‌شه دستی مدیریتش کرد و تازه باید رفت سراغ ابزارهای container orchestration که خودش دنیایی از دانش و دردسر جدید رو می‌طلبهجمع‌بندیاین جمع‌بندی بیش‌تر بر اساس نظرات و تجربیات شخصیه و ممکنه نظرات و تجربیات متفاوت یا حتی متضادی با این موارد وجود داشته باشه که می‌تونه وابسته به شرایط توسعه درست باشه و خوشحال می‌شم باهام در میون بذارید نظرات‌تون رو در این رابطه. ولی اون چیزی که من تجربه و تحلیل کردم رو در سه پاراگراف زیر این‌طوری جمع‌بندی می‌کنم.اگه یه اپلیکیشن جمع و جور دارید که با یه virtual environment پایتون یا یه xampp می‌شه راه‌اندازی و مدیریتش کرد و هزار جور ابزار برای نیازهای مختلف نیاز نداره همچنان سرور محلی بهترین گزینه‌س. مخصوصن اگه تیم خیلی بزرگی هم روش کار نمی‌کنه.اگه یه monolith بزرگ یا در حال بزرگ‌شدن دارید که برای توسعه و تستش کلی ابزار باید با هم دیگه کار کنند و تیم توسعه‌دهنده‌‌تون هم نسبتا بزرگ یا رو به رشده، استفاده از ماشین‌های مجازی می‌تونه راه حل خیلی بهتری باشه. که البته دردسرهای کانفیگ و نگهداری و هماهنگیش بین اعضای تیم اجتناب‌ناپذیره، که در ادامه این وید‌ئو-مقاله‌ها بهش بیش‌تر می‌پردازیم و براش راه‌حل‌های تئوری و آموزش عملی ارائه می‌کنیم.اگه تیم توسعه‌تون دانش کار با container و ابزارهای هماهنگ‌سازیش (توی محیط توسعه) رو داره یا می‌تونه فرا بگیره و ترجیحن توی محیط production هم دارید از container استفاده می‌کنید و زمان گذاشتن روی ساخت و مدیریت اون‌ها براتون ارزش داره و مهم‌تر از اون معماری دارید که استفاده از container ها برای گزینه‌ی خوبیه (مثل SOA یا Microservice)، احتمالن استفاده از container براتون بهترین گزینه‌س.ویدئو https://www.aparat.com/v/b71pw قسمت بعدیتوی قسمت بعدی این سری مقاله-ویدئو می‌ریم سراغ virtual machine ها و روش‌های مجازی‌سازی کلاسیک با استفاده از Hypervisor ها و Vagrant رو باهم مقایسه می‌کنیم. راجع به Vagrant مفصل حرف می‌زنیم و یه ماشین مجازی باهاش راه‌اندازی می‌کنیم و یه مقداری هم راجع به provision کردنش صحبت می‌کنیم.