https://virgool.io/feed/@masoud92 مدیر عامل و هم‌بنیانگذار شرکت طراحی بدون مرز، مدیرفنی مثقال، مدیر فنی کیف‌پول سازمانی سازمان‌من + کارشناسی‌ارشد هوش‌مصنوعی fa 2026-06-16 11:47:37 https://files.virgool.io/upload/users/1421/avatar/ff88GR.png?height=120&width=120 https://virgool.io/@masoud92 https://virgool.io/@masoud92/%D9%BE%DB%8C%DA%A9%D8%B1%D9%87%D8%A8%D9%86%D8%AF%DB%8C-%D9%85%D8%AD%DB%8C%D8%B7-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%88%D8%A8-%D8%B1%D9%88%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85%D9%87%D8%A7%DB%8C-%D8%B4%D8%AE%D8%B5%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-ymuwpftt6cjb 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 کردنش صحبت می‌کنیم. مسعود آقایی مسعود آقایی Fri, 17 Apr 2020 01:20:39 +0430 https://virgool.io/InfoSec/redis-on-centos-by-masoud-fn8y8neohwfk #بایگانی_دانش:‌ این سری نوشته‌ها برای آرشیو تجربیات شخصی از کار با تکنولوژی‌های مختلف و سهولت برای استفاده مجدد از اون‌ها تهیه می‌شه و فقط از اون‌جایی که ممکنه برخی از این تجربیات به درد دیگران هم بخوره به‌صورت آنلاین ذخیره شده.اول پیش نیاز های Redis رو نصب می کنید#update and upgrade the Linux$ yum -y update$ yum -y upgrade#Install gcc & tcl, needed for compilation$ yum install -y gcc*$ yum install -y tclبعد از اون نسخه stable منتشر شده از Redis رو دانلود و نصب می کنید$ wget http://download.redis.io/redis-stable.tar.gz$ tar xzf redis-stable.tar.gz$ cd redis-stable$ makeاگه دستور make با شکست روبرو شد و پیغام شکست مربوط به jemalloc بود مراحل زیر رو اضافه می کنید :$ cd deps$ make hiredis jemalloc linenoise lua geohash-int$ cd ../در نهایت :$ make test$ make installبعد از انجام این مراحل Redis با موفقیت نصب شده.حالا برای اینکه Redis رو به عنوان یه سرویس به Centos معرفی کنید از دستورات زیر استفاده کنید.$ cd utils$ chmod +x install_server.sh$ ./install_server.sh$ sudo chkconfig --level 2345 redis_6379 onحالا می شه با استفاده از سرویس Redis رو مدیریت کرد$ service redis_6379 status$ service redis_6379 startبرای بررسی اینکه همه چی به خوبی داره کار می کنه می تونید با استفاده از redis-cli از سرور ping بگیرید$ redis-cli$ 127.0.0.1:6379> pingPONGامنیت در Redisبه طور پیش فرض Redis بدون هیچ اعتبارسنجی در اختیار همه قرار می گیره و در واقع هیچ لایه ی امنیتی در برابر حملات وجود نداره بنابراین باید یه فکری برای این مشکل کردتنظیم firewall برای port هایی که Redis با اون ها کار می کنه. این کار می تونه به وسیله CSF یا هر تنظیمات دیگه ای روی firewall انجام بشه.به صورت پیش فرض استفاده از Redis تنها به سرور محلی bind شده و فقط از طریق localhost قابل دسترسیه اما اگه نیاز به replication دارید می تونید از طریق دستور زیر اجاز بدید ip های دیگه ای هم به این سرور bind بشن و از Redis استفاده کنند$ sudo nano /etc/redis/6379.confدر تنظیمات bind 127.0.0.1 رو پیدا کنید و اگه comment شده از حالت کامنت خارجش کنید و اگه نیست اضافه ش کنیدتنظیم گذرواژه برای Redis یکی از مهمترین کارهاست که به سادگی هم قابل انجامه$ sudo nano /etc/redis/6379.confدر تنظیمات requirepass foobared رو پیدا کنید از حالت کامنت خارجش کنید و به جای foobared گذرواژه مناسب رو قرار بدید.بعد به وسیله سرویس Redis رو restart کنید تا تنظیمات اعمال بشه.$ service redis_6379 restart$ redis-cli$ 127.0.0.1:6379> ping(error) NOAUTH Authentication required.بعد از اعمال تنظیمات حالا دیگه Redis به شما ping نمی ده و ازتون اعتبارسنجی می خواد.127.0.0.1:6379> AUTH myVeryVerySecurePassword127.0.0.1:6379> PINGPONGبرای بالا بردن بیشتر امنیت خوندن این مقاله رو توصیه می کنم. مسعود آقایی مسعود آقایی Thu, 19 Oct 2017 17:00:00 +0330