زیر پوست داکر چه خبر است

اینم یه تجربه پراکنده دیگه! این پست قرار بود جای دیگه‌ای منتشر بشه اما خب نشد. پس اینجا منتشرش میکنم. این متن رفرنس‌های زیادی کم داره که انشالا بعدا اضافه‌شون میکنم

در این پست قرار است که به زیرساخت‌هایی که داکر مبتنی بر آن ساخته شده است اشاره شود. هدف نهایی نشان‌دادن این موضوع است که داکر امکانات خود را به چه صورت ارائه می‌کند.

مقدمه

قاعدتا هم‌اکنون که در حال خواندن این متن هستید می‌دانید که داکر چیست و احتمالا می‌دانید که چگونه کار می‌کند. داکر خود مبدع موضوع جدیدی نبوده است و بر دوش تکنولوژی‌هایی توسعه یافته ایستاده است. استفاده از هریک از این تکنولوژی‌ها به تنهایی دردسر زیادی داشته و داکر با تجمع و آسان کردن استفاده از آنها توانسته است به اقبال عمومی دست یابد. در این پست بصورت خلاصه به بررسی این تکنولوژی‌ها پرداخته می‌شود.

کرنل لینوکس

بخش عمده‌ای از امکاناتی که داکر فراهم می‌کند، با استفاده از سازوکارهایی که در کرنل وجود دارند پیاده‌سازی شده‌اند. با در کنار هم قرار گرفتن این تکنولوژی‌ها داکر توانسته است که به ارائه خدمات بپردازد. لیست این تکنولوژی‌ها عبارتند از:

  • فضای نام(namespace)ها در لینوکس: فضا‌های نام این امکان را بوجود می‌آورند که بتوانند بخشی از منابع سیستم را بصورت ایزوله به پروسه‌هایی که درون آنها قرار دارند ارائه دهند. این منابع تنها توسط پروسه‌های درون آن قابل روئیت است. فضاهای نامی در داکر مورد استفاده قرار گرفته‌اند عبارتند از
    • فضای‌نام PID: که باعث می‌شود پروسه تنها پروسه‌های درون خود را ببینند
    • فضای‌نام NET: که باعث می‌شود بتوان کارت‌شبکه، پشته شبکه و سایر موارد را بصورت ایزوله ارائه کرد.
    • فضای‌نام IPC: که روندهای ارتباطی بین پروسه‌های مختلف را ایزوله می‌کند.
    • فضای‌نام MNT: که نحوه اتصال(mount) واسط‌های ذخیره سازی را ایزوله می‌کند.
    • فضای‌نام UTS: که نام کامپیوتر(hostname) و دامنه(NIS) را ایزوله می‌کند.
  • گروه‌های کنترلی یا cgroups: کرنل لینوکس این امکان را فراهم می‌اورد که پروسه‌ها در یک ساختار سلسله مراتبی قرار گفته و دسترسی آن به منابع سیستم محدود شود و مورد پایش قرار گیرد. این باعث می‌شود بتوان به عنوان مثال میزان استفاده از سی پی یو یا رم را کنترل کرد.

فایل سیستم

تکنولوژی دیگری که در داکر مورد استفاده قرار گرفته است، استفاده از یک سیستم فایل خاص به ویژگی copy on write است. سیستم فایلهای با این ویژگی را می‌توان بصورت لایه لایه ذخیره کرد و هنگام انتقال در صورت وجود داشتن نسخه قبلی تنها تفاوت‌ها را ارسال نمود. همچنین این امکان به ما این اجازه را میدهد که بتوانیم تغییرات را نسخه متفاوت همانند یک سیستم مدیریت نسخه پیگیری نماییم. سیستم فایلی که داکر از آن استفاده union file system است که ویژگی‌های زیر را دارد:
– بصورت لایه‌ایست
– هر لایه بایستی commit شود
– هر لایه بصورت فقط خواندنی ذخیره می‌شود.
– تنها فایلهای تغییر یافته در آن لایه ذخیره می‌شوند.

اجرا یک کانتینر

برای اجرای کانتیر و مشخص کردن تمام مشخصات آن بایستی این مشخصات را به فرمتی توصیف کرد. در داکر این فرمت container format نام داشته و داکر سعی در استاندارد کردن آن را دارد.

همه ایده‌های من: CMS as Service

اینم یه تجربه پراکنده دیگه

اگه پست‌های قبلی این سری رو خونده باشید می‌دونید که من ایده‌هام رو مینویسم که حداقل کاری در موردشون انجام دادم. البته از این پست یه اتفاق جدید هم افتاده و اون اینه که تصمیم گرفتم وبلاگم رو در صفحات اجتماعیم بصورت اتوماتیک به اشتراک بگذارم ببینم چی میشه. پس اول از همه چه از خوانندگان قدیم هستید چه از دوستانی که از شبکه‌های اجتماعی اومدید، خوش اومدید

برم سراغ ایده. چیزاهایی در دنیا وجود داره که در کشور ما به دلایل مختلفی اجرایی نمیشه و کسی هم روش کار نمیکنه. یکی از اون‌ها سرویس‌های زیرساختی هست که بصورت اتوماتیک ارائه بشه. تنها سیستم‌های زیرساختی اتوماتیکی که وجود داره سیستم‌های خرید هاست هست که اون هم به همت whmcs و cpanel هست که دیگرانی زحمت کشیدن و اون رو اتوماتیک کردن. پس جای خالی فراهم کنندگان IaaS و PaaS حس میشه. از طرف دیگه همیشه علاقه به وجود آوردن سایت سازهای اتوماتیک در بین مهندسین کامپیوتر وجود داشته و داره. یعنی اونها از قبل با زدن سرویس وبلاگ و اخیرا با زدن سایت سازهای متفاوت(مثل لینکسایت ساز کاموا، لینکتکنولوژی ۷۸، لینکسایت سازی کانی وب) سعی کردن خدمات از نوع SaaS ارائه بدن. این خدمات معمولا خدمات خوبی بودن اما کاربر حرفه‌ای که میخواد کار جدی بکنه رو جذب نمی‌کرده. همچنین معمولا سایت‌داران حرفه‌ای میرفتن سراغ خریدن vps و سرور و مدیریت کردن زیرساخت خودشون. اما من برخی از دوستانم رو میشناسم که توی مدیریت زیرساختشون همیشه مشکل دارن و بهشون حمله میشه و کلی اتفاق بد دیگه براشون میفته. پس اگه کسی باشه که بتونه سایت داران حرفه‌ای خدمتی ارائه بده و بهشون آزادی عمل بده که بتونن هر کاری میخوان انجام بدن و توی حجم بازدید بالا دوام بیارن و کمر خم نکنن اونها رو خوشحال میکنه.

پس اگه من بخوام تیتر وار بگم که چه کاری میخوام انجام بدم و به چه دلیلی این کار خوبه اینهاست:

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

بزم سراغ کاری که میخوام انجام بدم:

  • ابزار اصلی مورد استفاده: با توجه به آنچه که در شرکت‌های مشابه در دنیا انجام شده، استفاده از مجازی سازهای سبک یا همان مجازی سازی در سطح سیستم عام یا همان container ها رمز موفقیت این تجربه‌هاست. برای آشنایی بیشتر با این تکنولوژی‌ها به اینجا و اینجا مراجعه کنید. لیست این تکنولوژی‌ها که مستندات و منابع کافی در مورد آنها در اختیار است به شرح زیر است
  • هدف نهایی
    • اینکه کاربران بصورت اتوماتیک بتوانند سایت بسازند
    • نسخه‌های سایت آنها در git یا سیستم مشابه مدیریت نسخه‌های ذخیره شود
    • هر سایت دو سایت کمکی برای وضعیت stage و dev داشته باشد که از نظر ساختار شبیه سایت نهایی باشد
    • هر سایت بتواند در صورت نیاز افزایش کارایی پیدا کرده (با اجرا شدن کانتینرهای دیگر)
    • هزینه سرویس بصورت ساعتی محاسبه شود
    • به فایل‌های سایت(عکسهای آپلود شده و سایر مستندات) دسترسی معمول مثل ftp وجود داشته باشد
    • سایت بصورت on demand فعال و غیر فعال شوند تا در هزینه‌ها صرفه جویی شود.
  • مراحل اجرا
    • فاز اول(انجام شده):
      • استفاده از docker به عنوان تکنولوژی
      • استفاده از fig به عنوان سیستمی که سایت‌ها و کانتینرها را سر هم میکند
      • ایجاد یک image خاص منظوره برای cms ها استفاده شده. علی الحساب برای drupal و WordPress
      • استفاده از git برای نگهداری نسخه‌های مختلف سورس سایت‌ها
    •  فاز دوم:
      • ایجاد یک سیستم توزیع بار برای امکان افزایش کارایی
      • ایجاد یک سیستم برای share کردن فایلهای سایت بین کانتینرهای مختلف
      • رفع اشکال سیستم
    • فاز بینهایت
      • پیاده سازی service discovery در سیستم توزیع بار
      • پیاده سازی کانتینرهای on demand
      • پیاده سازی پرتال مشتریان برای انجام این عملیات بصورت اتوماتیک
  • چالش‌های کار
    • انتخاب تکنولوژی کانتینرها
    • سخت بودن service discovery و on demand بودن سیستمها
    • سخت بودن بازاریابی و جلب اعتماد سایت‌داران بزرگ
    • نیاز به سرمایه قابل توجه انسانی و مالی

نمیدونم چیزی از قلم افتاده یا نه ولی فعلا همین!

smartos اولین برخورد!

اینم یه تجربه پراکنده دیگه!

سر کار اخیرا نیاز شد که یه سیستم با قابلیت virtualization نصب کنیم. خوشبختانه همکارمون که مسئول این کار بود از من در این مورد مشورت گرفت. توی کارهای خیلی جدی شرکت معمولا از vmware ESXi استفاده میشه اما اینجا من و این دوستمون علاقه‌مند شدیم که از یه تکنولوژی دیگه استفاده کنیم. هر دومون با kvm و linux آشنایی داشتیم پس مطمئن بودیم که میتونیم در بدترین حالت با استفاده از لینوکس مشکل رو حل کنیم. پس من پیشنهاد دادم بریم سراغ smartos. یه شرکت به نام joyent از این سیستم عامل پشتیبانی میکنه که اسپانسر nodejs و چیزهای دیگه هم هست. همونطور که قبلا هم گفته بودم این سیستم عامل یه مدته «چشم من رو گرفته» دلایلش هم ایناست

  1. ریشه اش به سولاریس برمیگرده که سیستم عامل بسیار خوبیه!
  2. از zfs پشتیبانی میکنه که اون هم سیستم فایل محشریه!
  3. از kvm به عنوان مجازی ساز سخت افزار استفاده میکنه
  4. از zone های سولاریس به عنوان مجازی سازی سبک(مراجعه کنید به این و این) پشتیبانی میکنه

کاری که ما میخواستیم انجام بدیم این بود که میخواستیم علی الحساب یه ماشین مجازی pfsense توش نصب کنیم و یه کارهایی باهاش انجام بدیم در حین این کار نکات جالب و قابل توجهی برخوردیم که میخوام اینجا مستندشون کنم

نکات جالب در برخورد من با این سیستم عامل اینهاست

  1. کل سیستم نیاز به نصب نداره! و فقط کافیه که روی هارد بتونه سیستم فایل zfs رو تشخیص بده. پس بروز رسانی در حد خاموش و روشن کردن سیستم هزینه داره. از اون سمت با استفاده از pxe میشه سیستم رو بوت کرد که یعنی کل هاردهای سرور جهت ذخیره سازی اطلاعات بکار میره
  2. از json برای توصیف ماشین‌های مجازی و zone هاش استفاده میکنه. که این قضیه برنامه نویسی کردن برای اون رو به شدت ساده میکنه

نکات قابل توجهی که من در حین کار بهش برخوردم اینا بود

  1. کارت شبکه mainboard یکم مشکل داشت و smartos هم درست ازش استفاده نمیکرد
  2. مدت زمان لازم برای reboot شدن ماشین مجازی pfsense زیاد بود(حدود ۵ دقیقه)
  3. نمیشد از توی pfsense سیستم رو reboot کرد
  4. نصب واسط گرافیکی برای راحت‌تر کار کردن لینوکس و یونیکس نابلدها با سیستم به نظر پر دردسر میرسید!

علی الحساب همین تا باز هم بیشتر باهاش کار کنم و نتایج رو بهتون بگم!