https://virgool.io/feed/@sedhossein Software Engineer @Snapp! fa 2026-06-18 06:26:08 https://files.virgool.io/upload/users/24205/avatar/5324qW.png?height=120&width=120 https://virgool.io/@sedhossein https://virgool.io/treeboon/%DA%A9%D8%A7%D9%87%D8%B4-%D9%87%D8%B2%DB%8C%D9%86%D9%87-%D9%86%DA%AF%D9%87%D8%AF%D8%A7%D8%B1%DB%8C-%D8%AA%D8%B1%DB%8C%D8%A8%D9%88%D9%86-%D8%A8%D9%87-%D8%B3%D8%A7%D9%84%DB%8C-%DA%A9%D9%85%D8%AA%D8%B1-%D8%A7%D8%B2-%DB%B2%DB%B0%DB%B0-%D9%87%D8%B2%D8%A7%D8%B1-%D8%AA%D9%88%D9%85%D9%86-klv8nvbo9uyl تو این نوشته قصد انتقال یک تجربه شخصی به همراه سبک و سنگین کردن بُعد بیزینسی و تکنیکال دارم. در بخش اول (خیلی خلاصه) چالش های بیزینسی به همراه هزینه ها رو بررسی میکنیم و تو بخش دوم (مفصل) درباره نحوه انجام دادن تصمیمات فنی به همراه جزعیاتش گپ میزنیم. پس اگر براتون مهم نیست که چرا این تصمیم رو گرفتم میتونید به بخش دوم برید. اگر حوصله نداری! خلاصه بگم برای اینکه بتونیم زمان بیشتری (بدون جذب سرمایه) سرویس تریبون رو بالا نگهداریم تصمیم به کاهش هزینه نگهداری تریبون کردیم و نهایتا مهاجرت از سرور مجازی خارجی به هاست اشتراکی داخلی ماحصل کار ما بود. با چالش هایی مثل فیلتر و تحریم در اینترنت داخلی، کاهش سطح دسترسی در شخصی سازی محیط نگهداری در هاست اشتراکی، مشکلات استقرار، کاهش سرعت سرویس و ... سر و کله زدیم که در آخر تونستیم تمامی امکانات سرویس رو با کمی تغییر و یا انتخاب جایگزین حفظ کنیم.مقدمههیچ وقت یک آدم صرفا فنی بودن برام جذاب نبوده و همیشه تلاش کردم که بتونم به دنیای واقعی نزدیک تر باشم؛ به طوری که از مفاهیم و تئوری در جای درست نیازمندی های صنعت رو به در حالتی بهینه حل کنم. بعد از این که یک سال از راه اندازی تریبون گذشت و ذوق و زمان ما برای نگهداری از او کمتر شد تصمیم گرفتیم که هزینه های نگهداریش رو تا حد ممکن کاهش بدیم تا بتونیم زمان بیشتری زنده نگه داریمش :)) جزعیات و نتیجه چالش‌ها و تصمیم هایی که گرفتیم رو توی این دو بخش مینویسم تا هم برای ما ثبت خاطره بشه و هم شاید در آینده شما مسئول نگهداری یک کسب کار نوپا باشید و یا قصد راه اندازی آنرا داشته باشید که شرایط شبیه به ما رو تجربه کنید.قبل شروع بگم که ...تریبون توسط یه تیم دو نفره سرپا هست و یک کار نوپاست که برای کسب تجربه‌های جدید و آموزش شخصیمون ازش نگهداری میکنیم. تصمیمات و معماری و ابزارهایی که داخلش استفاده شده را با توجه به زمان و هزینه و خیلی معیارهای غیرفنی متفاوت انتخاب شده‌اند. معیارهای فنی تنها جنبه تصمیم‌گیری ها نبوده، برای همین یک سری جاها میبینید از یک سری ابزارها استفاده های عجیب برای حل کردن مشکلمون کردیم! (مثلا تلگرام به عنوان alerting system) بخش اول - کجا بودیم؟ کجا هستیم؟ به کجا خواهیم رفت؟- کجا بودیم؟ از ابتدای شروع کار تریبون، برامون اهداف آموزشی و کسب تجربه بیشتر تو مباحث مالی و بیزینسی اهمیت داشت و برای همین توی زمینه‌ای که فکر میکردیم نیاز و تقاضا هست شروع به ساختن ایده کردیم و تریبون رو تشکیل دادیم.- کجا هستیم؟ بعد از گذشت دقیقا یک سال از راه اندازی تریبون، بنابر دلایل زیادی که از مهمترین آنها سواد کم بیزینسی و تنبلی بودند، نتونستیم به بچمون(تریبون) برسیم و کامل در همه جنبه های مختلف پرورشش بدیم. درحالی که سرویس ما آمادگی پاسخ دهی به تعداد زیادی درخواست و کاربر همزمان رو داره، ما تبلیغات رو براش شروع نکردیم و خب این یعنی برای لود و کاربرانی آماده هستیم که قرار نیست به این زودی مهمان ما باشند! درواقع بیشتر از حد نیاز آماده هستیم!- به کجا خواهیم رفت؟ اگر خیلی خلاصه بگم: ‌کاهش هزینه‌ها برای افزایش توان سرپا نگه‌داشتن تریبون. چون درآمد تریبون خیلی ناچیز هست و تبلیغاتی درحال انجام نیست، پس یعنی فقط هزینه نگهداری سرویس رو داریم. البته هزینه مالی منظورم هست و از نیروی انسانی و انرژی که خودمون میزاریم صرف نظر کردم. پس هرچقدر هزینه رو کمتر کنیم بیشتر میتونیم سرویس رو بالا نگهداریم.خب حالا که یه دید نسبی از شرایط داریم نوبت این هست که هزینه های تریبون رو لیست کنیم و سعی کنیم ببینیم تو کدوم قسمت میتونیم صرفه جویی کنیم و کمترش کنیم:۱. سرور مجازی خارجی: هسته اصلی سرویس به همراه دیتابیس (در ادامه علت انتخاب سرور خارجی رو میگم)۲. هاست اشتراکی داخلی: برای وبلاگ و اخبار تریبون یک اپلیکیشن وردپرسی داشتیم که جداگونه بالا آورده شده بود.۳. پنل ارسال پیامک: سرویس اجتناب ناپذیری که برای اعتبار سنجی ثبت‌نام ها و فراموشی رمز عبور و اطلاع رسانی ها و ... ازش باید استفاده بشه.۴. تبلیغات:‌ درحال حاضر هزینه خاصی برای بخش نمیکردیم!خب!! حالا باید ببینیم کدوم بخش هارو تا چقدر میتونیم بهینه کنیم. خلاصه بگم فقط مورد سرور مجازی خارجی هست که هزینه‌‌اش دلاری بود و خب بزرگترین ترین بخش هزینه‌ها بود. با خودم فکر کردم اگر بتونم سرویس رو داخل همون هاست اشتراکی بالا بیارم چقدر زیاد میتونم هزینه هارو به صفر نزدیک کنم؛ بعلاوه اینکه سالیان زیادی هست که یک هاست اشتراکی برای کارای دم‌دستی داشتم و اگر بتونم روی همون بالا بیارم سرویس رو خیلی عالی میشه. با این اوصاف هزینه ها تقریبا نزدیک به صفر میرسه!بخش دوم - چطور بدون هیچ اختلالی از سرور مجازی به هاست اشتراکی مهاجرت کنیم؟برای هم‌خط شدن باهم بزارید معماری و جزعیات فعلی سرویس تریبون رو با هم مرور کنیم.ساختار کلی سرویس تریبون به شکل زیر بود که تشکیل شده از یک Shared-Host در ایران و یک VPS در هلند که با دو سرویس خارجی دیگر که کاوه‌نگار و تلگرام هستن در ارتباط هست:مهمترین علتی که تریبون رو اولین بار بردیم روی سرور خارجی بحث فیلتر و تحریم بود.این قضیه تو سهولت کانفیگ و نگهداری سرور و همینطور ارتباط با تلگرام تاثیر مستقیم داشت. از طرفی برای بک‌آپ گیری هم از Cloud Storage رایگان استفاده میکردیم که جایگزین ایرانی نداریم! (قبلا پستی در مورد ‍اینکه چگونه یه بک‌آپ کم هزینه داشته بسازیم هم نوشتم و میتونید از اینجا بخونید). خب مشکل مهاجرت روی هاست اشتراکی داخلی ازینجا شروع میشه که دیگه نه Redis رو داریم نه تلگرام رو. از Redis به عنوان یه حافظه موقتی استفاده میکردیم که تو فرآیندهای caching و sessions و ... استفاده شده بود که خب داخل هاست اشتراکی نداریمش. از تلگرام هم برای خبر دادن اتفاقات و ارور ها و ... استفاده کرده بودیم که همیشه تمامی اتفاقات رو به خوبی زیر نظر داشته باشیم بدون نیاز به چک کردن پنل مدیریت. حالا مشکل اینه که به خاطر محدودیت سطح دسترسی تو Shared-Host دیگه Redis نداریم. همینطور از اینترنت داخل تلگرام فیلتر هست؛ پس تلگرام هم پَر! لیست مشکلات مهجرت به هاست اشتراکی شامل میشد از:فیلتر بودن تلگرام و از کار افتادن Notificationهای تریبون: استفاده از SMS به عنوان نوتیفیکیشن‌ها، هم پرهزینه میشه و هم چون باید برای تمامی اعضای تیم ارسال میشد، خب داد میزد که کار تکراری و بیخودی هست! از طرفی حجم SMS زیاد هم برای خودمون اذیت کننده میشد. پس باید براش چاره‌ دیگه‌ای پیدا میکردیم.نداشتن Redis: که ما هیچ لایه کشی رو برنداشتیم فقط از فایل بجای Redis استفاده کردیم! درواقع کیفیت و سرعت رو فدای بهینه سازی مالی کردیم :) استفاده از Storage Facade تو لاراول این کار رو خیلی آسون کرده بود و کافی بود فقط یک کانفیگ رو از `redis` به `file` تغییر بدیم. سازگاری اپلیکیشن لاراولی با هاست اشتراکی که داخل این مقاله مفصل درباره چالش های انتقال یک اپلیکیشن لاراولی روی هاست اشتراکی نوشتم براتون.حافظه مورد نیاز برای عکس ها: برخی خدمات دهنده‌های هاست اشتراکی سرویس هایی دارند که تا ۱۵۰ گیگابایت فضای اضافه برای سرویس رو میدن که بخاطر نوپا بودن تریبون این مقادیر خیلی قابل قبول بود.کاهش سرعت: با اینکه تمام سعی رو کردیم تا هیچ لایه از Cache از بین نره اما اتفاقی اجتناب ناپذیر بود! ما سرعت رو فدای هزینه کردیم چون درحال حاضر برای این حجم از درخواست هامون منابع و سرعت Shared-Host قابل قبول بود و به نسبت خوب‌تر از چیزی بود که فکرش رو میکردیم!بک‌آپ: خوشبختانه خود هاست اشتراکی ها گاهی تضمین بک‌آپ گیری منظم رو میدن و این میتونه لااقل در مواقع ضروری Disaster Plan ما باشه. اگر چه اعتمادی به خدمات دهنده‌‌ها نیست و یک نسخه بک‌آپ به‌روز هم خودمون باید داشته باشیم! :)) ‌که اونم فکرهایی براش کردم اما فعلا برامون صرفه نداره و بک‌آپ هفتگی جداگونه ایمنی نسبتا خوبی رو میده بهمون.خب توی ساختار جدید به همچین چیزی رسیدیم:اگر به عکس خوب نگاه کرده باشید متوجه حذف تلگرام شدید که بجاش یک بخش جدیدی اضافه شده که احتمالا منظور ایمیل رو میرسونه! نیازهای خبررسانی سریع یا Notification اتفاقات داخل سیستم رو با ایمیل انجام میدیم و که در این مرحله جواب‌گوی نیاز ما هست.فوقع ما وقع!بعد از استقرار یک نسخه از سرویس تریبون در Shared-Host و اطمینان از اینکه همه چیز درست کار میکنه یا نه، سرویس رو شبونه به هاست اشتراکی انتقال دادیم و VPS هلند رو خاموش کردم و تمام! ‌این شکلی بود که موفق شدیم هزینه نگهداری تریبون رو از ماهی بیشتر از ۲۰۰ هزار تومن به سالی کمتر از ۲۰۰ هزار تومن برسونیم! سخن پایانیبا اینکه از همون شروع کار خیلی روی بهینه بودن و کم هزینه بودن تریبون وقت گزاشتیم، اما درنهایت کار متوجه شدیم که ارزیابی کافی و درست نداشتیم! به نظرم بحث‌های فنی سرویس در یک کسب و کار آنلاین نباید فاصله زیادی با نیاز و وسعت بیزینس داشته باشه و باید هم‌پا و منطقی با هم جلو بروند. در مورد ترریبون فکر میکنم حالت الانش میتونست حالت ایده‌آل اولیه باشه و شاید بهتر بود در زمان توسعه اولیه همون انرژی بهینه‌سازی‌های فنی رو روی توسعه بیزینس میزاشتیم. البته که همیشه اشتباه مطمعن‌ترین راه برای یادگیری هست :)ممنونم از وقتی که گذاشتی و تا انتهای متن رو خوندی. اگر پیشنهاد و یا انتقادی داشته باشی از شنیدنش خوشحال میشم. عالی باشید 3> Sedhossein Sedhossein Thu, 10 Jun 2021 14:08:19 +0430 https://virgool.io/@sedhossein/%D8%A7%D8%B3%D8%AA%D9%82%D8%B1%D8%A7%D8%B1-%D9%84%D8%A7%D8%B1%D8%A7%D9%88%D9%84-laravel-%D8%AF%D8%B1-%D9%87%D8%A7%D8%B3%D8%AA-%D8%A7%D8%B4%D8%AA%D8%B1%D8%A7%DA%A9%DB%8C-shared-host-zjkvzvjkc1fp سلام. تو این نوشته قصد دارم برای کسی که دنبال جواب سریع هستش اول از همه مراحل حل مشکل رو بگم و اگر علاقه مند بودی در بعدش به یک سری نکات و خوبی(!) و بدی های این کار بپردازیم. هاست های اشتراکی به علت هزینه کم، رایج بودن و همچنین سهولت نگهداری و بک‌آپ‌گیری توسط خود سرویس‌دهنده‌ها محبوبیت زیادی دارند و شاید بتواند انتخاب مناسبی با توجه به نیاز افراد باشد. از اونجایی که میدونیم قسمت مهمی از این محبوبیت‌ها ساپورت کردن PHP هستش پس اگر اپلیکیشن لاراولی داریم و قصد داریم که تو هاست اشتراکی بالا بیاریمش، این نوشته شاید کمکتون کنه. اگرچه خود من به دلایل زیادی اینکار رو برای محصولات پرکاربرد و جدی توصیه نمیکنم و دراین نوشته نمیخوام زیاد بهش بپردازم و فقط یک سری مشکلاتی که از نظر خودم اذیت کننده هستن رو نام میبرم. اما اگر دوست داشتی در مورد مشکلات اینکار بیشتر بدونی بلاگ های زیادی از جمله این لینک به مواردیش اشاره کرده.قبل از شروع به گفتن مراحل کار این نکته رو گوشه ذهنتون داشته باشید که:هرجایی که مینویسم public_html منظورم دایرکتوری هست که اصطلاحا serve شده و درخواست‌ها به اون آدرس روت میشه. که این اسم در ادمین پنل های مختلف(Cpanel, DrirectAdmin, Plesk) متفاوت میتونه باشه. و همچنین اینکه اگر ssl داشته باشید شاید استراتژی های متفاوتی برای مدیریت درخواست های با ssl و بدون اون داشته باشید که معمولا در DirectAdmin یه دایرکتوری به اسم private_html میسازن که یا محتوای متفاوت از public_html داره یا یک symlink به آن خواهد بود. در با صرف نظر کردن این نکات همه جا از public_html استفاده میکنم ولی شما حواستون باشه.مراحل: ساختار پروژه رو به شکل زیر درست کنید. دایرکتوری public رو یک لایه بیرون تر از بقیه دایرکتوری ها بزارید:├ application/ ├── core/ │   ├── app/ │   ├── bootstrap/ │   ├── config/ │   ├── database/ │   ├── resources/ │   ├── routes/ │   ├── storage/ │   └──tests/ └── public/پروژه رو zip کنید و بفرستید روی هاست و روی هاست unzip کنید(با هر روشی که راحتید. FTP, AdminPanel ....).دامپ دیتابیس(ساخت دیتابیس و مایگریشن) رو آماده کنید و روی دیتابیس هاست هم import کنید.حتما حتما حتما دایرکتوری core پروژه رو بیرون public_html (ترجیحا کنارش) بزارید.فایل ENV. رو با مقادیر پروداکشن به‌روز کنید و حتما خارج public_html بزاریدش(نکته‌ی قبل شروع مراحل فراموش نشه!). همچنین برای لود کردن محتوای ENV. از یک مسیر جدید(بیرون core تو ساختاری که بالا گفتیم) میتونید از فانکشن app->useEnvironmentPath("/path")$ استفاده کنید.محتواهای دایرکتوری public پروژه که آپلود کردید رو ببر توی مسیر serve هاست یا همون public_html.رو فایل public_html/index.php آدرس لود کردن فایل های رو درست کنید(ممکن هست تو روژن های متفاوت لاراول تفاوت های ریزی باشه. شما باید تمامی مسیرها رو در ضورت تغییر در ساختارتون به‌روز کنید) و همچنین تکه کدی که مسیر public پروژه رو مشخص کرده هم باید اضافه کنید(تست شده با لاراول ۸).if (file_exists(__DIR__.'/../core/storage/framework/maintenance.php')) { require __DIR__.'/../core/storage/framework/maintenance.php'; } require __DIR__ . '/../core/vendor/autoload.php'; $app = require_once __DIR__ . '/../core/bootstrap/app.php'; // #### NEW PART #### // set the public path to this directory $app->bind('path.public', function() { return __DIR__; });اگر به هر نحوی دسترسی shell ویا اجرای job هارو دارید تغییرات اصلاح آدرس پروژه رو مثل بالا برای فایل‌های core/server.php و core/artisan نیز انجام بدیداگر مثل من شما هم در پروژه نیاز به آپلود فایل داشتید و دسترسی ساختن symlink نداشتید از کلک من میتونید استفاده کنید! داخل فایل core/config/filesystems.php تکه کد زیر رو اضافه کنید:'disks' => [ // .... 'public_uploads' => [ 'driver' => 'local', 'root' => public_path('storage'), 'visibility' => 'public', 'url' => public_path('storage'), ], ],و بعدش هرجایی که میخواستید فایلی رو آپلود کنید میتونید اینطوری هندل کنید:Storage::disk('public_uploads')->put($filePath, $image);حتما حتما تو کانفیگ وب سرورتون حواستون باشه دسترسی به دایرکتوری های مهمتون و فایل های ENV. رو گرفته باشید تا پسورد و اطلاعاتتون لو نره.مشکلات: نسخه بندی(ورژن) و استقرار(دیپلوی)یکی از مهمترین نکته‌های هر محصول نرم‌افزاری(مخصوصا در محیط وب) استقرار، نگهداری و نسخه سازی(versioning) آن است. در هاست اشتراکی فرایندهای اتوماتیک و تمیز برای استقرار نسخه‌های جدید نرم‌افزار وجود نداره و خیلی از قسمت‌های این فرایندها رو باید دستی انجام داد. شما میتونید یا از محیط‌های گرافیکی سرویس دهنده ها(Plesk, Cpanel, DirectAdmin) فایل هاتون رو آپلود/آپدیت کنید. یا با FTP از ابزارهایی مثل FileZilla استفاده کنید و تغییرات رو اعمال کنید. همچنین برای import/export از دیتابیس هم از phpmyadmin که مهمولا همه هاست اشتراکی‌ها نصب دارند میتونید استفاده کنید.ساختار پروژهاز اونجایی که ساختار پیشفرض لاراول برای کارکردن تو هاست اشتراکی آماده نیست باید تغییراتی رو هم داخل کد و ساختارش درست ایجاد کنیم. محدودیت‌های هاست اشتراکی! محدودیت استفاده از امکانات لاراول!به علت محدودیت‌های سطح دسترسی تو هاست اشتراکی از برای داشتن قابلیت‌های زیر قراره که اذیت بشیم:- توسعه و استقرار مستمر- استفاده از ابزارهای caching مثل redis, memcached- استفاده از migrationها- فقدان extensionهای خاص و محدودیت نصب آن درصورت نیازمندی یک پیکیج- نبود artisan console و tinker- نبود supervisor درنتیجه نداشتن job/queue - و ....امنیتمراقبت باشید که وقتی دارید اپلیکیشن رو آماده پروداکشن می‌کنید فایل‌هایی که نمیخوایید و نباید معلوم باشن معلوم نباشن! یعنی چی؟ یعنی اگر عکس، فایل ENV. ، یا ... دارید که نباید دیده بشه، هم توی وب حواستون به کانفیگ های وب‌سرور تون باشه که نزارید این فایل ها اصطلاحا serve بشه، هم داخل فایل `public_html/*` فایل‌های مهم رو نزارید! چون معمولا این مورد فراموش میشه.سخن پایانیدر آخر هم امیدوارم شما هم مثل من اگر و اگر مجبور بودید فقط این کارهارو کنید و به کارتون بیاد این نوشته :)))) اگر پیشنهاد و انتقادی و تجربه‌ایی داشتی که فکر میکنی به بهتر شدن این متن کمک میکنه حتما نظر بده.خوش باشی Sedhossein Sedhossein Thu, 10 Jun 2021 13:58:50 +0430 https://virgool.io/treeboon/%D8%B3%DB%8C%D8%B1-%D8%AA%D8%A7-%D9%BE%DB%8C%D8%A7%D8%B2-%D8%B1%D8%A7%D9%87%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-%DB%8C%DA%A9-automated-backup-%D8%A7%D8%B1%D8%B2%D9%88%D9%86-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D8%B3%D8%A8%D9%88%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7%DB%8C-%D9%86%DA%86%D9%86%D8%AF%D8%A7%D9%86-%D8%A8%D8%B2%D8%B1%DA%AF-ilrfizclv98g یک سرویس بدون backup, یک سرویس مرده است!نکاتی‌ قبل خواندن:سطح این نوشته متوسط هستش. برای افرادی میتونه مفید باشه که مسئولیت نگهداری و توسعه سرویس‌های کوچیکی رو دارن و هنوز سرویسشون بار و لود زیادی نداره. (تقریبا خیلی از سرویس‌ها)میتونه برای کسایی که ایده‌ای از backup گرفتن سرویس‌ها/سرورهاشون ندارن هم جذاب باشه. یا افرادی که میخوان کمی با چالش‌های server-side بیشتر دست و پنجه نرم کنند.برای افرادی که خودشون اینکاره هستن شاید قسمت معرفی اشتراک رایگان cloud storage مگا براشون جدید باشه (شایدم نه) مگرنه بقیه موارد رو بلدن خودشون.مفاهیم و ابزارهایی که بهشون نیاز داریم عبارتند از: Linux knowledge, Bash و دیگر هیچ :))اگر از هاست‌های اشتراکی استفاده میکنید، اکثر خدمات‌دهنده‌ها سیستم backupگیری دارند و احتمالا دسترسی لازم برای این کارها رو ندارید. پس احتمالا این نوشته میتونه برای شما جنبه آموزشی داشته باشه و وقتی به کارتون بیاد که رو vps و سرور اختصاصی خودتون مهاجرت کرده باشید.هکسره رو برای خوانایی بیشتر بعضا رعایت نکردم و نوشتن به سبک گفتاری رو ترجیح دادم. اگر OCD ادبیاتی دارید از این متن پرهیز کنید :)))شاید کمی طولانی شده باشه. نمیخواستم از محتواها کم کنم و خب جداکردن نوشته و تبدیلش به دوتا متن هم زیاد جذاب نبود و یکنواختیش رو از دست میداد. پس پیشاپیش از صبر و توجه شما بسی سپاسمندم(قلب)مقدمه ( تو این قسمت بیشتر درباره خودم و خلاصه داستان چگونگی ایجاد نیازم صحبت میکنم. اگر علت نوشتنم برات مهم نیست، میتونی خیلی راحت رد کنی این قسمت رو! )از اواسط فروردین ۹۹ که ایده تریبون(treeboon.ir) به ذهنمون زد، کرونا، تعطیلی‌ها و کم‌شدن رفت‌و‌آمد هامون رو غنیمت دونستیم و خیلی سریع شروع به ساختن اولین نسخه ایده‌مون کردیم. من همیشه به انتقال تجربه حس خوبی داشتم و تلاشم بر این هست که تو مراحل رشد تریبون راه حل‌هایی که انتخاب کردیم و قسمت‌هایی از مسیری که طی میکنیم رو با شما به اشتراک بزارم. در نتیجه این راه‌حل ها قسمت‌هایی از مسیر یک کسب‌و‌کار نوپا و در حال حاضر کوچیک هستش و اشتباه داشتن، بهینه نبودن یا بهترین نبودن میتونه توش مکرر دیده شه. اما به نقل قول از دوست خوبم شهاب جا داره که بگم:یک مهندس نرم‌افزار معمولی، کارش رو شاید با شناخت کم از ابزار و مفاهیم معمولی هم انجام میده. یک مهندس نرم‌افزار خوب، ابزارها و مفاهیم رو به خوبی میشناسه و همه‌جا از اون‌ها استفاده میکنه و قواعد بازی رو به خوبی رعایت میکنه؛ و اما یک مهندس نرم‌افزار هنرمند، با شناخت کامل ابزارها و مفاهیم، باتوجه به محیط و شرایط قواعد رو هنرمندانه میشکونه و با آگاهی از نتایج تصمیم دیگه‌ای رو انتخاب میکنه! مهندس هنرمند >>>>>>>>>>> مهندس خوب تو موقعیت های متفاوت با دونستن راه درست‌تر، راه دیگه‌ای رو انتخاب کردم و سعی کردم کنار دید تکنیکال دید محصولی (product based) هم داشته باشم. صفر# نیاز اصلی: چه موقعی به backup نیاز داریم اصلا؟اگر تا به حال تجربه‌های تلخی مثل زیر رو داشتی که هیچ! میدونی خودت:)) rm -rf /wrong/path/* کاملا اتفاقی، پاک‌شدن همه اطلاعاتتون و جواب سربالا شنیدن از پشتیبانی و انکار این اتفاق، یا در بهترین حالت ابراز تاسف پشتیبانی از اتفاقی که رخ داده و فرستادن کد تخفیف برای دلجویی! هک شدن و نفوز هکر به کل(یا قسمتی) از سیستم شما و باج خواستن در ازای پاک نکردن اطلاعات(در بهترین حالت!)اما اگر ندیدی و تجربه‌اش نکردی توصیه میکنم به فکر راه حل باشی و قبول کنی حس‌های زیاد قشنگی نیستن :)) پس برای نگهداری نسخه‌ای به‌روز از سرویس‌هاتون حتما نیاز به یک برنامه پشتیبانی منظم و خودکار دارید، یا همون automated backup.یک# از چه چیزهایی رو چند وقت یکبار backup بگیریم تا خیالمون راحت باشه؟خیلی سوال کلی هست و جوابش هم کاملا بستگی به شرایط و نیازهای سرویس شما داره! برای جواب دادن به این سوال نوع(ساختار) اطلاعات شما، حساسیت اونها، میزان تغییرات و افزایش اطلاعات و ... و کلی معیار دیگر موثر میتونن باشن.ما داخل تریبون(treeboon.ir) اطلاعات آگهی‌ها(تریبون‌های تبلیغاتی) و عکس هاشون رو داریم. پس یعنی عکس(فایل)، سورس کد و دیتابیس انواع اطلاعاتی هست که ما نیاز به backup گرفتن از اونها هستیم. اما یک نکته رو نباید فراموش کنیم که یک backup خوب همه چی رو شامل میشه! هرچیزی که داخل سرورهاتون دارید(کانفیگ‌ها و‌ جاب‌ها و ...). اما خب با توجه به نوپا بودن تریبون تصمیم گرفتیم پیچیدگی کار رو زیاد نکنیم و درواقع یک Disaster Recovery Plan داشته باشیم فعلا.و خب درباره چند وقت یکبار backup گرفتن هم خودتون و منابعی که در دسترس دارید بهترین جواب رو میدونن! میتونید از روزی یکبار تست کنید تا عدد بهینه‌تر برای سرویستون رو پیدا کنید.دو# خب چه‌جوری شروع کنیم؟ با نام و یاد خدا: موسیقی مورد علاقه خودتون رو اول پلی کنید :)) بد نیست اگر تاحالا از Bash استفاده نکردید کمی باهاش آشنا شید و بعدش شروع کنید.(در حدی که الان نیاز دارید، داخل این لینک هست)بعدش یک دایرکتوری ایجاد کنید و برای هر اسکریپتی که میخوایید بنویسید یک فایل ".sh" بسازید. خب از backup دیتابیس شروع کنیم که به نوعی همه درگیرش هستند. مدل backup گرفتن از هر دیتابیسی متفاوته و برای هرکدوم کلی اسکریپت آماده و خوب هست مثل: postgresql, mongodb, mysql که برای نیاز ما همشون جواب میدن و راحت هستن! خب یک مثال خیلی ساده از mysql با هم یه نگاه بندازیم:(کد داخل گیتهابم هست)داخل متغیرها مشخصات خودتون مثل آدرس backup و ساختار نام فایل backup رو مشخص میکنید و به‌جای YOUR_USER هم اسم یوزری که قصد دارید این اسکریپت رو اجرا کنه بنویسید(برای اینکه به مشکل دسترسی نخورید). اون nice کاری که میکنه اینه که اولویت انجام این کار(اون خط از اسکریپت) رو برای CPU کمتر میکنه و درواقع nice اش میکنه!(برای مشکل کمبود CPU این راه فرار رو برای مدتی انتخاب کردم! اگر دوست داشتید بیشتر دربارش بدونید از این لینک میتونید استفاده کنید). به همین سادگی شما یک کپی از دیتابیس دارید(برای سرویس های بزرگ راه حل‌های دیگری هستن که تو این نوشته مجالش نیست)! خب برای داشتن نسخه‌های مختلف کدها هم از گیتلب استفاده میکنم. حالا یک سری سرور اختصاصی دارند، نداشتید هم مهم نیست و خود سایت گیتلب هم کارتون رو تا حد زیادی راه میندازه. میمونه backup گرفتن از فایل ها(فیلم: عکس: pdf ویا ...). این قسمت خیلی بستگی به وقت، سلیقه و حوصله‌ای که دارید وابسته است. من در حد نیاز و وقت خودم به شکلی که زیر اشاره میکنم انجامش دادم. شما میتونید اگر نیازهای بیشتری دارید توسعه بدیدش و جزعیات بیشتری براش درنظر بگیرید.خب بازهم خیلی ساده است! با کامند زیرsudo apt-get install zipمیتونید پیکیج zip رو نصب کنید و با تغییر مقدار متغیرها مسیر دلخواهتون رو مشخص کنید و فایل هاتون رو داخل همون مسیری که مشخص کردید به شکل zip شده کپی بگیرید.خب چرا میگیم کپی؟ چون همه اینکارا رو کردیم که در مواقع بحرانی و خاص ما نسخه به‌روز از سرویسمون رو داشته باشیم، این شکلی اگر سرور اپلیکیشن ما بترکه، کپی‌های ما هم باهاش میترکن! اگر هم نترکه کار بهتر این هست که نگهداری سرورهای سرویس اپلیکیشن و سرورهای پشتیبانی رو جدا کنیم همیشه! سه# خب برای backup داشتن از این کپی‌ها چه کنیم؟ کجا ببریم و چگونه اینکار رو انجام بدیم؟راه خوبش اینه که یک یا چندین سرور پشتیبانی داشته باشید و داستان های خودش! اما من قصدم اون راه‌های خیلی اصولی نیست چون هزینه‌اش شاید زیاد شه برای شروع کار. و خب با اینکه راه‌های فنی درست‌تر برای تریبون(treeboon.ir) میدونستیم، تصمیم گرفتیم به سراغ storageهای رایگان بریم. تعدادشون زیاد هست اما خب هرکدوم دردسرهای خودشون رو دارن! یکی معروفترین‌ها هم google-drive عزیز هستن. اما خب برای اشتراک رایگانش ۱۵گیگ میده و من دنبال بیشتر ازینا بودم. یه خفن‌تر پیدا کردم از نوع ۵۰گیگ :)) مگا خدمات Cloud Storage هست که ۵۰ گیگ تو اشتراک رایگانش میده و چی ازین بهتر! به‌روزرسانی: درحال حاضر مگا برای اشتراک رایگان ۱۵ گیگ میده و اون دوران خوش تمام شد :))خب ایده اینه که backupهاتون رو یجوری باید بفرستید رو سرورهای پشتیبانی‌تون و اونجا نگهداریشون کنی. راه‌های مختلفی هست که هرکدوم خوبی بدی های خودشون رو دارن. rsync, ftp, mount و ... از راه‌هایی هستن که میتونید استفاده کنید. mount کردن گوگل‌درایو و سرویس های شبیه بهش کلی ابزار و پکیج آماده هم داره. حالا این مگا عزیز پکیج آماده برای هم cmd و هم gui آماده کرده که خیلی راحت میتونید رو لینک بزنید و نصبش کنید. mac, windows و linux رو پشتیبانی میکنه. برای نصب روی سرور خب به نسخه cmd نیاز داریم. بعدش کافیه آخر اسکریپت‌هاتون این خط رو اضافه کنی تا فایل‌های کپی که ساختید رو به جای دیگه‌ای منتقل کنی و backup واقعی بسازی برای خودت:(برای دیدن بقیه امکانات مگا میتونید تو سایتش برید و ببینید)این اسکریپت با کاربر YOUR_USER و اهمیت ۱۵ برای CPU(هرچی این عدد بیشتر باشه اولویت انجام کار برای CPU کمتر میشه و اون کار niceness بیشتری داره)الان خیلی تمیز میتونید اسکریپت‌هایی بنویسید برای فشرده‌سازی فایل‌هاتون و نگهداری از آنها را به عهده فضاهای دیگر بدید و به اونجا منتقلشون کنید. چهار# خب قسمت automate پس چی میشه؟ این اسکریپت‌هارو دستی اجرا کنیم هربار؟فکر کن یک درصد این کار رو بکنیم! :))اگر با مفهوم cron و job آشنا هستید که خیلی هم عالی. اگر نه به این لینک سر بزنید و بعدش بیایید با هم به کمک ‍‍crontab یک کامندی بنویسیم و بهش یگیم که اسکریپت‌های ما هرچند وقت یکباره، نیاز به اجرا دارند. از این سایت برای اجرا و تست زمان بندی cronهاتون می‌توانید استفاده کنید و بعدش آدرس اسکریپتی که باید انجام بشه رو میدیم بهش:0 5 * * * /bin/bash -c &quot/backup/scripts/run.sh&quot >> /backup/scripts/logger.log 2>&1خب ما اینجا گفتیم ساعت ۵ صبح هرروز(با توجه به timezone سرورتون) بره و اسکریپت run.sh رو اجرا کنه و لاگ‌های اجرای اسکریپت رو بریزه داخل فایل logger.log. و ایزی ایزی تامام تامام!شما ازین به بعد به صورت خودکار backupهاتون رو به ساده‌ترین شکل و با کمترین هزینه ممکن دارید.پنج# نکاتی که میتونه کار رو حرفه‌ای تر و قشنگ‌تر کنههیچ وقت backupهاتون رو replace با قبلی نکنید و هر دفعه فایلی جدید بسازید و قبلی‌هارو تا چندین نسخه نگهداری کنید. (تا اگر مشکلی روی فایل هاتون پیش اومد و در نتیجه backupهاتون هم خراب بود، backupهای قبلی رو از دست نداده باشید)نسخه های خیلی قدیمی رو هم اسکریپتی بنویسید خودکار پاک کنید تا حافظه سرورتون پر نشه.با توجه به مدل backupگیری که انتخاب میکنید، روش تمیز کردن کپی‌های قدیمی میتونه متفاوت باشه اما من یک نمونه ازش رو داخل صفحه گیتهابم گذاشتم. نکات پایانیکدهایی که من نوشتم رو میتونید از صفحه گیتهابم داشته باشید و پیشنهادی داشتید PR, MR بزارید.در طراحی این روش نکات غیرتکنیکال هم در نظر گرفته شده، مثل زمان و هزینه و ... . درنتیجه بهترین راه ممکن نیست، اما راه آسون و کم‌هزینه و خوبی برای تریبون(treeboon.ir) بود. و کلی نکته رعایت نشده هست که شاید خودم ندونمش. ممنون میشم بهم یادآوری کنیدش(قلب)در ریزه‌کاری‌ها امکان داره که کد و روش من با نیاز شما متفاوت باشه ویا فراموش کرده باشیم جزعیات خیلی‌ریز رو بنویسم. به مشکلی خوردید بپرسید و اگر مشکلی هم دیدید، داخل نظرات بگید تا بقیه دوستان هم بدونند و اشتباه نکنند. من هم حتما با اصلاحات جدی متن رو اصلاح میکنم.ممنون میشم اگر هر انتقاد و پیشنهادی بود برام بنویسید(برام بسیار ارزشمند هست نظراتتون). اگر فکر میکنید این متن رو دوست داشتید ویا به درد دوستانتون میخوره به اشتراکش بزارید.سعی میکنم تا جایی که برسم، همراه رشد تریبون(treeboon.ir) مطالبی که شاید مشکل دیگران هم باشه رو انتشار بدم. پس منتظر باشید تا تریبون رو بیشتر ببینید ازین به بعد ;)مرسی که تا آخر متن همراهی کردی. امیدوارم به اطلاعاتی که داشتی اضافه شده باشه و لذت برده باشی.به ‌امید دیدار. https://treeboon.ir/ Sedhossein Sedhossein Thu, 04 Jun 2020 19:37:37 +0430