نوشته های محسن نیک نژاد

مقیاس‌پذیری: از صفر تا میلیون‌ها کاربر

محسن نیک نژاد — Tue, 17 Feb 2026 12:11:04 +0330

طراحی سیستمی که بتواند میلیون‌ها کاربر را پشتیبانی کند، یک فرآیند تکرارپذیر (Iterative) است. هیچ سیستمی از روز اول برای میلیون‌ها کاربر طراحی نمی‌شود، بلکه به مرور زمان تکامل می‌یابد.پیکربندی تک‌سرور (Single Server Setup)سفر هزار فرسنگی با اولین قدم آغاز می‌شود و ساخت یک سیستم پیچیده نیز از این قاعده مستثنی نیست. برای شروعِ کار به شکلی ساده، تمام اجزای سیستم روی یک سرور واحد اجرا می‌شوند.در این ساختار، همان‌طور که در تصویر بالا (مشابه شکل ۱ مقاله) مشاهده می‌کنید، تمامی بخش‌ها از جمله اپلیکیشن وب (Web App)، پایگاه داده (Database) و حافظه پنهان (Cache) بر روی یک سخت‌افزار قرار دارند.شکل 1- ارسال درخواست تا اخذ پاسخبرای درک بهتر این پیکربندی، بررسی جریان درخواست (Request Flow) و منبع ترافیک (Traffic Source) بسیار مفید هستند. بیایید ابتدا نگاهی به جریان درخواست (مطابق شکل ۲ در مقاله) بیندازیم:شکل 2جریان درخواست (Request Flow)برای درک بهتر این چیدمان، بررسی جریان درخواست و منبع ترافیک مفید است. ابتدا به جریان درخواست نگاهی می‌اندازیم:۱. دسترسی از طریق نام دامنه: کاربران از طریق نام‌های دامنه (Domain Names) مانند api.mysite.com به وب‌سایت‌ها دسترسی پیدا می‌کنند. معمولاً «سامانه نام دامنه» یا همان DNS، یک سرویس پولی است که توسط ارائه‌دهندگان شخص ثالث (3rd parties) ارائه می‌شود و روی سرورهای ما میزبانی نمی‌شود.۲. دریافت آدرس IP: آدرس پروتکل اینترنت (IP) به مرورگر یا اپلیکیشن موبایل بازگردانده می‌شود. در این مثال، آدرس IP به صورت 15.125.23.214 بازگردانده شده است.۳. ارسال درخواست HTTP: به محض دریافت آدرس IP، درخواست‌های پروتکل انتقال ابرمتن (HTTP) مستقیماً به وب‌سرور شما ارسال می‌شوند.۴. پاسخ سرور: وب‌سرور برای نمایش (Rendering)، صفحات HTML یا پاسخ‌های JSON را بازمی‌گرداند.منابع ترافیک (Traffic Source)ترافیک ورودی به وب‌سرور شما از دو منبع اصلی نشأت می‌گیرد: اپلیکیشن وب و اپلیکیشن موبایل.اپلیکیشن وب (Web Application): این اپلیکیشن از ترکیبی از زبان‌های سمت سرور (مانند Java، Python و غیره) برای مدیریت منطق تجاری (Business Logic)، ذخیره‌سازی و... و زبان‌های سمت کاربر (HTML و JavaScript) برای ارائه و نمایش محتوا استفاده می‌کند.اپلیکیشن موبایل (Mobile Application): پروتکل HTTP، پروتکل ارتباطی بین اپلیکیشن موبایل و وب‌سرور است. به دلیل سادگی، JSON (نشانه‌گذاری اشیاء جاوااسکریپت) معمولاً به عنوان قالب پاسخ API برای انتقال داده‌ها استفاده می‌شود.در ادامه، نمونه‌ای از یک پاسخ API در قالب JSON آورده شده است:GET /users/12 – Retrieve user object for id = 12{ "id": 12, "firstName": "Ali", "lastName": "Dossti", "address": "Tehran", "isActivated": true}پایگاه داده (Database)با رشد تعداد کاربران، دیگر یک سرور واحد پاسخگو نیست و ما به چندین سرور نیاز داریم: یکی برای مدیریت ترافیک وب/موبایل و دیگری مختص پایگاه داده (شکل ۳).جداسازی سرورهای ترافیک وب/موبایل (Web Tier یا لایه وب) از سرور پایگاه داده (Data Tier یا لایه داده)، این امکان را فراهم می‌کند که هر کدام را به‌طور مستقل مقیاس‌دهی (Scale) کنیم.چرا این جداسازی حیاتی است؟وقتی لایه وب و لایه داده را از هم جدا می‌کنید، در واقع دارید به سیستم خود "فضای تنفس" می‌دهید:بهینه‌سازی منابع: سرور وب معمولاً به پردازنده (CPU) قوی‌تر برای منطق برنامه نیاز دارد، در حالی که سرور پایگاه داده به حافظه (RAM) و سرعت خواندن/نوشتن (I/O) دیسک بالاتری محتاج است. با این تفکیک، می‌توانید سخت‌افزار هر کدام را دقیقاً بر اساس نیاز انتخاب کنید.استقلال در مقیاس‌دهی: اگر ترافیک وب زیاد شد، می‌توانید تعداد سرورهای وب را افزایش دهید، بدون اینکه نگران تنظیمات دیتابیس باشید (و برعکس).امنیت: می‌توانید دیتابیس را در یک شبکه خصوصی (Private Subnet) قرار دهید که مستقیماً از اینترنت قابل دسترسی نباشد، و فقط سرور وب اجازه صحبت با آن را داشته باشد.نکته: این اولین قدم جدی برای تبدیل شدن از یک "پروژه جانبی" به یک "سیستم حرفه‌ای" است. در واقع شما دارید به سیستم خود یاد می‌دهید که تخصصی عمل کند!شکل 3در ادامه، ترجمه دقیق و علمی بخش‌های مربوط به انتخاب پایگاه داده و مفاهیم مقیاس‌دهی را مطالعه می‌کنید:انتخاب پایگاه داده: کدام یک مناسب‌تر است؟شما می‌توانید بین یک پایگاه داده رابطه‌ای (Relational) سنتی و یک پایگاه داده غیررابطه‌ای (Non-relational) انتخاب کنید. بیایید تفاوت‌های آن‌ها را بررسی کنیم.پایگاه‌های داده رابطه‌ای (Relational Databases)این پایگاه‌های داده با نام‌های RDBMS یا پایگاه داده SQL نیز شناخته می‌شوند. محبوب‌ترین آن‌ها عبارتند از: MySQL، Oracle و PostgreSQL.ساختار: داده‌ها را در قالب جداول (Tables) و سطرها (Rows) نمایش داده و ذخیره می‌کنند.عملیات Join: شما می‌توانید با استفاده از زبان SQL، عملیات پیوند (Join) را روی جداول مختلف انجام دهید تا داده‌های مرتبط را استخراج کنید.پایگاه‌های داده غیررابطه‌ای (NoSQL Databases)این پایگاه‌ها با نام NoSQL شناخته می‌شوند. نمونه‌های محبوب آن‌ها عبارتند از: CouchDB، Neo4j، Cassandra، HBase و Amazon DynamoDB. این دیتابیس‌ها به چهار دسته کلی تقسیم می‌شوند:کلید-مقدار (Key-Value Stores)گراف (Graph Stores)ستون‌محور (Column Stores)سندمحور (Document Stores)نکته: در اکثر پایگاه‌های داده غیررابطه‌ای، عملیات Join پشتیبانی نمی‌شود.چه زمانی از NoSQL استفاده کنیم؟برای اکثر توسعه‌دهندگان، پایگاه‌های داده رابطه‌ای بهترین گزینه هستند، زیرا بیش از ۴۰ سال قدمت دارند و از نظر تاریخی عملکرد خوبی داشته‌اند. با این حال، اگر دیتابیس‌های رابطه‌ای برای نیازهای خاص شما مناسب نیستند، بررسی گزینه‌های دیگر ضروری است. NoSQL ممکن است انتخاب درستی باشد اگر:اپلیکیشن شما به تأخیر بسیار کم (Super-low latency) نیاز دارد.داده‌های شما بدون ساختار (Unstructured) هستند یا هیچ رابطه منطقی بین آن‌ها وجود ندارد.فقط نیاز به سریال‌سازی و حساسیت‌زدایی داده‌ها (JSON, XML, YAML و غیره) دارید.نیاز به ذخیره‌سازی حجم انبوهی از داده‌ها (Massive amount of data) دارید.مقیاس‌دهی عمودی در مقابل مقیاس‌دهی افقیمقیاس‌دهی عمودی (Vertical Scaling)که به آن "Scale Up" نیز گفته می‌شود، فرآیند اضافه کردن قدرت بیشتر (CPU، رم و غیره) به سرورهای فعلی شماست.مزایا: سادگی در پیاده‌سازی (بهترین گزینه برای ترافیک کم).محدودیت‌های جدی:سقف سخت‌افزاری: اضافه کردن نامحدود CPU و حافظه به یک سرور واحد غیرممکن است.فقدان تاب‌آوری (Failover): در این مدل، افزونگی (Redundancy) وجود ندارد. اگر سرور از کار بیفتد، وب‌سایت/اپلیکیشن کاملاً از دسترس خارج می‌شود.مقیاس‌دهی افقی (Horizontal Scaling)که به آن "Scale Out" گفته می‌شود، به شما اجازه می‌دهد با اضافه کردن سرورهای بیشتر به استخر منابع خود، مقیاس سیستم را افزایش دهید. به دلیل محدودیت‌های روش عمودی، مقیاس‌دهی افقی برای اپلیکیشن‌های در مقیاس بزرگ بسیار مطلوب‌تر است.متعادل‌کننده بار (Load Balancer)یک متعادل‌کننده بار، ترافیک ورودی را به‌صورت متوازن میان مجموعه‌ای از سرورهای وب که در یک «گروه متعادل‌سازی» (Load-balanced set) تعریف شده‌اند، توزیع می‌کند. شکل ۴ نحوه عملکرد یک متعادل‌کننده بار را نشان می‌دهد.شکل 4همان‌طور که در شکل ۴ نشان داده شده است، کاربران مستقیماً به IP عمومی (Public IP) متعادل‌کننده بار متصل می‌شوند. با این تنظیمات، سرورهای وب دیگر مستقیماً توسط کلاینت‌ها (کاربران) قابل دسترسی نیستند. برای امنیت بهتر، از IPهای خصوصی (Private IPs) برای ارتباط بین سرورها استفاده می‌شود. IP خصوصی آدرسی است که فقط بین سرورهای موجود در یک شبکه داخلی قابل دسترسی است و از طریق اینترنت نمی‌توان به آن دست یافت. متعادل‌کننده بار از طریق این IPهای خصوصی با سرورهای وب ارتباط برقرار می‌کند.در شکل ۴، پس از اضافه شدن متعادل‌کننده بار و سرور وب دوم، ما با موفقیت مشکل عدم تاب‌آوری (Failover) را حل کرده و در دسترس بودن (Availability) لایه وب را بهبود بخشیدیم. جزئیات در ادامه توضیح داده شده است:اگر سرور ۱ از کار بیفتد (آفلاین شود)، تمام ترافیک به سرور ۲ هدایت می‌شود. این کار از قطع شدن وب‌سایت جلوگیری می‌کند. همچنین، ما یک سرور وب سالم جدید به استخر سرورها اضافه می‌کنیم تا بارِ کاری متعادل شود.اگر ترافیک وب‌سایت به سرعت رشد کند و دو سرور برای مدیریت ترافیک کافی نباشد، متعادل‌کننده بار می‌تواند این مشکل را به زیبایی مدیریت کند. شما فقط کافی است سرورهای بیشتری به استخر سرورهای وب اضافه کنید و متعادل‌کننده بار به‌طور خودکار ارسال درخواست‌ها به آن‌ها را آغاز می‌کند.اکنون لایه وب وضعیت خوبی دارد، اما لایه داده چطور؟ طراحی فعلی دارای یک پایگاه داده است، بنابراین از تاب‌آوری و افزونگی (Redundancy) پشتیبانی نمی‌کند. تکثیر پایگاه داده (Database Replication) یک تکنیک رایج برای حل این مشکلات است. بیایید نگاهی به آن بیندازیم.تکثیر پایگاه داده (Database Replication)به نقل از ویکی‌پدیا: «تکثیر پایگاه داده می‌تواند در بسیاری از سیستم‌های مدیریت پایگاه داده استفاده شود که معمولاً دارای یک رابطه Master/Slave (اصلی/ثانویه) بین نسخه اصلی (Master) و کپی‌ها (Slaves) است.»یک پایگاه داده Master (اصلی) عموماً فقط از عملیات نوشتن (Write) پشتیبانی می‌کند. پایگاه داده Slave (ثانویه) کپی‌های داده را از دیتابیس اصلی دریافت کرده و فقط از عملیات خواندن (Read) پشتیبانی می‌کند. تمام دستورات تغییر دهنده داده مانند Insert، Delete یا Update باید به پایگاه داده Master ارسال شوند. از آنجایی که اکثر اپلیکیشن‌ها به نسبتِ بسیار بالاتری از خواندن نسبت به نوشتن نیاز دارند، تعداد دیتابیس‌های Slave در یک سیستم معمولاً بیشتر از دیتابیس‌های Master است. شکل ۵ یک پایگاه داده اصلی را به همراه چندین پایگاه داده ثانویه نشان می‌دهد.شکل 5مزایای تکثیر پایگاه داده (Database Replication):عملکرد بهتر: در مدل Master-Slave، تمامی عملیات نوشتن و به‌روزرسانی در گره‌های Master انجام می‌شود؛ در حالی که عملیات خواندن میان گره‌های Slave توزیع می‌گردد. این مدل عملکرد را بهبود می‌بخشد، زیرا اجازه می‌دهد پرس‌وجوهای (Queries) بیشتری به‌طور موازی پردازش شوند.قابلیت اطمینان (Reliability): اگر یکی از سرورهای پایگاه داده شما بر اثر بلایای طبیعی مانند طوفان یا زلزله نابود شود، داده‌ها همچنان حفظ می‌شوند. شما نگران از دست رفتن داده‌ها نخواهید بود، زیرا داده‌ها در چندین مکان تکثیر شده‌اند.در دسترس بودن بالا (High Availability): با تکثیر داده‌ها در مکان‌های مختلف، وب‌سایت شما حتی در صورت آفلاین شدن یک پایگاه داده به فعالیت خود ادامه می‌دهد، زیرا می‌توانید به داده‌های ذخیره شده در سرور پایگاه داده دیگر دسترسی داشته باشید.در بخش قبل بحث کردیم که چگونه یک متعادل‌کننده بار (Load Balancer) به بهبود در دسترس بودن سیستم کمک کرد. در اینجا نیز همان سوال را می‌پرسیم: اگر یکی از پایگاه‌های داده آفلاین شود چه اتفاقی می‌افتد؟ طراحی معماری که در شکل ۵ بررسی شد، می‌تواند این وضعیت را مدیریت کند:اگر فقط یک پایگاه داده Slave موجود باشد و آفلاین شود: عملیات خواندن به‌طور موقت به پایگاه داده Master هدایت می‌شود. به محض شناسایی مشکل، یک پایگاه داده Slave جدید جایگزین نسخه قدیمی خواهد شد. در صورتی که چندین پایگاه داده Slave موجود باشد، عملیات خواندن به سایر دیتابیس‌های Slave سالم هدایت شده و یک سرور جدید جایگزین سرور معیوب می‌گردد.اگر پایگاه داده Master آفلاین شود: یکی از پایگاه‌های داده Slave به مقام Master جدید ارتقا می‌یابد (Promote). تمام عملیات‌های پایگاه داده به‌طور موقت روی Master جدید اجرا خواهند شد. بلافاصله یک پایگاه داده Slave جدید برای عملیات تکثیر داده جایگزین نسخه قبلی می‌شود. در سیستم‌های عملیاتی (Production)، ارتقای یک Master جدید پیچیده‌تر است، زیرا ممکن است داده‌های موجود در دیتابیس Slave به‌روز نباشند. داده‌های مفقود شده باید با اجرای اسکریپت‌های بازیابی داده (Data Recovery) به‌روزرسانی شوند. اگرچه روش‌های تکثیر دیگری مانند Multi-masters (چند اصلی) و Circular replication (تکثیر حلقوی) می‌توانند کمک‌کننده باشند، اما این پیکربندی‌ها پیچیده‌تر هستند و بحث درباره آن‌ها خارج از حوصله این دوره است.شکل ۶ طراحی سیستم را پس از اضافه کردن متعادل‌کننده بار و تکثیر پایگاه داده نشان می‌دهد.شکل 6 بیایید نگاهی به طراحی سیستم بیندازیم:۱. کاربر آدرس IP متعادل‌کننده بار (Load Balancer) را از DNS دریافت می‌کند. ۲. کاربر با استفاده از این آدرس IP به متعادل‌کننده بار متصل می‌شود. ۳. درخواست HTTP به یکی از دو سرور (سرور ۱ یا سرور ۲) هدایت می‌شود. ۴. وب‌سرور، داده‌های کاربر را از یک پایگاه داده Slave (ثانویه) می‌خواند. ۵. وب‌سرور تمامی عملیات‌های تغییر دهنده داده (شامل نوشتن، به‌روزرسانی و حذف) را به پایگاه داده Master (اصلی) هدایت می‌کند.اکنون که درک درستی از لایه‌های وب و داده پیدا کرده‌اید، نوبت به بهبود زمان بارگذاری و پاسخ‌دهی (Response Time) رسیده است. این کار را می‌توان با اضافه کردن یک لایه حافظه پنهان (Cache) و انتقال محتوای ایستا (فایل‌های JavaScript، CSS، تصاویر و ویدیوها) به شبکه توزیع محتوا (CDN) انجام داد.حافظه پنهان (Cache)کش یک فضای ذخیره‌سازی موقت است که نتایج پاسخ‌های سنگین (از نظر پردازشی) یا داده‌هایی که مکرراً به آن‌ها دسترسی پیدا می‌شود را در حافظه (Memory) ذخیره می‌کند تا درخواست‌های بعدی با سرعت بیشتری پاسخ داده شوند. همان‌طور که در شکل ۶ نشان داده شده است، هر بار که یک صفحه وب جدید بارگذاری می‌شود، یک یا چند فراخوانی پایگاه داده برای واکشی داده‌ها اجرا می‌گردد. عملکرد اپلیکیشن به شدت تحت تأثیر این فراخوانی‌های مکرر پایگاه داده قرار می‌گیرد؛ حافظه پنهان می‌تواند این مشکل را تعدیل کند.لایه حافظه پنهان (Cache Tier)لایه کش یک لایه ذخیره‌سازی موقت داده است که بسیار سریع‌تر از پایگاه داده عمل می‌کند. مزایای داشتن یک لایه کش مجزا شامل بهبود عملکرد سیستم، توانایی کاهش حجم کاری پایگاه داده و قابلیت مقیاس‌دهی مستقلِ لایه کش است. شکل ۷ یک پیکربندی احتمالی از یک سرور کش را نشان می‌دهد:شکل 7پس از دریافت یک درخواست، وب‌سرور ابتدا بررسی می‌کند که آیا پاسخ مورد نظر در حافظه پنهان (کش) موجود است یا خیر. اگر موجود باشد، داده‌ها را به کلاینت بازمی‌گرداند. در غیر این صورت، از پایگاه داده استعلام می‌گیرد، پاسخ را در کش ذخیره می‌کند و سپس آن را به کلاینت می‌فرستد. این استراتژی حافظه پنهان، Read-through Cache نامیده می‌شود. استراتژی‌های دیگری نیز برای حافظه پنهان وجود دارد که بسته به نوع داده، اندازه و الگوهای دسترسی انتخاب می‌شوند. یک مطالعه پیشین، چگونگی عملکرد استراتژی‌های مختلف حافظه پنهان را توضیح داده است [6].تعامل با سرورهای حافظه پنهان ساده است، زیرا اکثر آن‌ها رابط‌های برنامه‌نویسی (API) برای زبان‌های برنامه‌نویسی رایج ارائه می‌دهند. قطعه‌کد زیر نمونه‌ای از APIهای معمول در Memcached را نشان می‌دهد:SECONDS = 1 cache.set('myKey, 'hi there', 3600 * SECONDS) cache.get('myKey')ملاحظات استفاده از حافظه پنهان (Cache)در ادامه، چندین نکته کلیدی که هنگام استفاده از سیستم حافظه پنهان باید در نظر بگیرید، آورده شده است:تصمیم‌گیری برای زمان استفاده از کش: زمانی از حافظه پنهان استفاده کنید که داده‌ها به‌طور مکرر خوانده می‌شوند اما به ندرت تغییر می‌کنند. از آنجایی که داده‌های کش‌شده در حافظه فرار (Volatile Memory) ذخیره می‌شوند، سرور کش برای ذخیره‌سازی دائمی داده‌ها مناسب نیست. برای مثال، اگر سرور کش ری‌استارت شود، تمام داده‌های موجود در حافظه از دست می‌روند. بنابراین، داده‌های مهم باید در ذخیره‌سازهای پایدار (Persistent Data Stores) ذخیره شوند.سیاست انقضا (Expiration Policy): پیاده‌سازی یک سیاست انقضا تمرین خوبی است. داده‌های کش‌شده پس از انقضا، از حافظه حذف می‌شوند. اگر سیاست انقضا وجود نداشته باشد، داده‌ها برای همیشه در حافظه باقی می‌مانند. توصیه می‌شود زمان انقضا را خیلی کوتاه در نظر نگیرید، زیرا باعث می‌شود سیستم به دفعات زیاد داده‌ها را از پایگاه داده بارگذاری کند. در عین حال، طولانی بودن بیش از حد زمان انقضا نیز باعث می‌شود داده‌ها کهنه و نامعتبر (Stale) شوند.هماهنگی (Consistency): این مورد شامل همگام نگه‌داشتن پایگاه داده و حافظه پنهان است. ناهماهنگی زمانی رخ می‌دهد که عملیات تغییر داده در پایگاه داده و به‌روزرسانی در کش در قالب یک تراکنش واحد (Single Transaction) انجام نشود. حفظ این هماهنگی هنگام مقیاس‌دهی در چندین منطقه جغرافیایی (Regions) چالش‌برانگیز است. برای جزئیات بیشتر، می‌توانید به مقاله منتشر شده توسط فیس‌بوک با عنوان «Scaling Memcache at Facebook» مراجعه کنید.کاهش اثرات شکست (Mitigating failures): وجود تنها یک سرور کش می‌تواند باعث ایجاد «نقطه شکست واحد» (SPOF) شود. طبق تعریف ویکی‌پدیا: «نقطه شکست واحد، بخشی از سیستم است که در صورت از کار افتادن، کل سیستم را از کار می‌اندازد». در نتیجه، برای جلوگیری از SPOF، استفاده از چندین سرور کش در مراکز داده مختلف توصیه می‌شود. رویکرد پیشنهادی دیگر، اختصاص حافظه بیش از حد نیاز (Overprovisioning) با یک درصد مشخص است تا هنگام افزایش مصرف حافظه، یک فضای رزرو (Buffer) وجود داشته باشد.شکل 8سیاست تخلیه حافظه (Eviction Policy)زمانی که ظرفیت حافظه پنهان (کش) پر می‌شود، هر درخواستی برای اضافه کردن آیتم‌های جدید ممکن است باعث حذف آیتم‌های موجود شود؛ این فرآیند تخلیه کش (Cache Eviction) نامیده می‌شود.LRU (Least-Recently-Used): محبوب‌ترین سیاست تخلیه کش است که در آن آیتم‌هایی که در طولانی‌ترین زمان اخیر استفاده نشده‌اند، حذف می‌شوند.LFU (Least Frequently Used): در این روش آیتم‌هایی که کمترین دفعات استفاده را داشته‌اند حذف می‌شوند.FIFO (First In First Out): در این مدل، اولین آیتمی که وارد کش شده است، اولین آیتمی خواهد بود که تخلیه می‌شود.بسته به نوع کاربری و سناریوهای مختلف، می‌توان هر یک از این سیاست‌ها را اتخاذ کرد.شبکه توزیع محتوا (CDN)شبکه توزیع محتوا یا CDN، شبکه‌ای از سرورهای پراکنده از نظر جغرافیایی است که برای تحویل محتوای ایستا (Static) استفاده می‌شود. سرورهای CDN محتواهایی نظیر تصاویر، ویدیوها، فایل‌های CSS، جاوااسکریپت و غیره را در خود ذخیره (Cache) می‌کنند.ذخیره‌سازی محتوای پویا (Dynamic content caching) مفهومی نسبتاً جدید است که از محدوده این دوره خارج است. این قابلیت اجازه می‌دهد صفحات HTML که بر اساس مسیر درخواست (Path)، رشته‌های پرس‌وجو (Query strings)، کوکی‌ها و هدرهای درخواست ساخته می‌شوند نیز کش شوند. برای اطلاعات بیشتر در این زمینه می‌توانید به مقاله شماره [9] در منابع مراجعه کنید. تمرکز این دوره بر چگونگی استفاده از CDN برای ذخیره محتوای ایستا است.در ادامه، نحوه عملکرد CDN در سطح کلان (High-level) آمده است: وقتی کاربری از یک وب‌سایت بازدید می‌کند، سرور CDN که از نظر جغرافیایی به او نزدیک‌تر است، محتوای ایستا را تحویل می‌دهد. به طور منطقی، هرچه کاربر از سرورهای CDN دورتر باشد، وب‌سایت کندتر بارگذاری می‌شود. برای مثال، اگر سرورهای CDN در سان‌فرانسیسکو باشند، کاربران در لس‌آنجلس محتوا را سریع‌تر از کاربران ساکن در اروپا دریافت می‌کنند.شکل ۹ نمونه‌ای عالی است که نشان می‌دهد چگونه CDN زمان بارگذاری را بهبود می‌بخشد.شکل 9شکل ۱۰ گردش کار (Workflow) یک CDN را نشان می‌دهد.شکل 10۱. درخواست کاربر A: کاربر A سعی می‌کند با استفاده از یک URL، فایل image.png را دریافت کند. دامنه این URL توسط تأمین‌کننده CDN ارائه می‌شود. دو آدرس زیر نمونه‌هایی هستند که نشان می‌دهند URL تصاویر در CDNهای آمازون (Cloudfront) و Akamai چگونه به نظر می‌رسند:https://mysite.cloudfront.net/logo.jpghttps://mysite.akamai.com/image-manager/img/logo.jpg۲. عدم وجود در کش (Cache Miss): اگر سرور CDN فایل image.png را در حافظه پنهان خود نداشته باشد، آن را از منبع اصلی (Origin) درخواست می‌کند. این منبع می‌تواند یک وب‌سرور یا یک فضای ذخیره‌سازی آنلاین مانند Amazon S3 باشد.۳. پاسخ منبع اصلی: منبع اصلی فایل image.png را به سرور CDN بازمی‌گرداند. این پاسخ شامل یک هدر اختیاری HTTP به نام Time-to-Live (TTL) است که مشخص می‌کند تصویر تا چه زمانی باید در کش باقی بماند.۴. ذخیره‌سازی و تحویل: CDN تصویر را کش کرده و آن را به کاربر A بازمی‌گرداند. تصویر تا زمانی که TTL منقضی نشده باشد، در CDN باقی می‌ماند.۵. درخواست کاربر B: کاربر B درخواستی برای دریافت همان تصویر ارسال می‌کند.۶. تحویل از کش (Cache Hit): تا زمانی که TTL منقضی نشده باشد، تصویر مستقیماً از حافظه پنهان CDN بازگردانده می‌شود.ملاحظات استفاده از CDNهزینه: CDNها توسط شرکت‌های ثالث اداره می‌شوند و شما بابت انتقال داده‌ها (ورودی و خروجی) هزینه پرداخت می‌کنید. ذخیره دارایی‌هایی که به ندرت استفاده می‌شوند سود قابل توجهی ندارد، بنابراین باید خروج آن‌ها از CDN را در نظر بگیرید.تنظیم انقضای مناسب برای کش: برای محتوای حساس به زمان، تنظیم زمان انقضای کش حیاتی است. این زمان نباید خیلی طولانی یا خیلی کوتاه باشد. اگر خیلی طولانی باشد، محتوا دیگر تازه نخواهد بود؛ و اگر خیلی کوتاه باشد، باعث بارگذاری مکرر محتوا از سرورهای اصلی به CDN می‌شود.جایگزینی در صورت خرابی (CDN Fallback): باید در نظر بگیرید که وب‌سایت یا اپلیکیشن شما چگونه با خرابی احتمالی CDN مقابله می‌کند. اگر قطعی موقتی در CDN رخ دهد، کلاینت‌ها باید بتوانند مشکل را شناسایی کرده و منابع را مستقیماً از سرور اصلی درخواست کنند.ابطال فایل‌ها (Invalidating files): شما می‌توانید یک فایل را قبل از تاریخ انقضا با استفاده از روش‌های زیر از CDN حذف کنید: ۱. ابطال شیء (Object) در CDN با استفاده از APIهایی که فروشندگان CDN ارائه می‌دهند. ۲. استفاده از نسخه‌بندی اشیاء (Object Versioning) برای ارائه نسخه‌ای متفاوت. برای این کار می‌توانید پارامتری مانند شماره نسخه را به URL اضافه کنید (مثلاً image.png?v=2).شکل ۱۱ طراحی سیستم را پس از اضافه شدن CDN و لایه حافظه پنهان (Cache) نشان می‌دهد.شکل 11۱. دارایی‌های ایستا (JS، CSS، تصاویر و غیره) دیگر توسط وب‌سرورها ارائه نمی‌شوند، بلکه برای عملکرد بهتر از CDN فراخوانی می‌شوند. ۲. بار پایگاه داده با استفاده از کش کردن داده‌ها (Caching) کاهش یافته است.لایه وب بدون وضعیت (Stateless Web Tier)اکنون نوبت به بررسی مقیاس‌دهی افقی لایه وب رسیده است. برای این منظور، باید «وضعیت» (State) - برای مثال داده‌های نشست یا همان Session کاربر - را از لایه وب خارج کنیم. یک رویکرد مناسب، ذخیره داده‌های نشست در یک فضای ذخیره‌سازی پایدار مانند پایگاه داده رابطه‌ای یا NoSQL است. با این کار، هر وب‌سرور در کلاستر (خوشه) می‌تواند به داده‌های وضعیت از طریق پایگاه داده دسترسی داشته باشد. این ساختار، لایه وب بدون وضعیت نامیده می‌شود.معماری باوضعیت (Stateful Architecture)یک سرور «باوضعیت» (Stateful) و یک سرور «بدون وضعیت» (Stateless) تفاوت‌های کلیدی با هم دارند. سرور باوضعیت، داده‌های کلاینت (وضعیت) را از یک درخواست تا درخواست بعدی به خاطر می‌سپارد؛ اما سرور بدون وضعیت، هیچ اطلاعاتی از وضعیت را نزد خود نگه نمی‌دارد.شکل ۱۲ نمونه‌ای از یک معماری باوضعیت را نشان می‌دهد.شکل 12در شکل ۱۲، داده‌های نشست (Session) و تصویر پروفایل کاربر A در «سرور ۱» ذخیره شده است. برای احراز هویت کاربر A، تمام درخواست‌های HTTP او باید حتماً به «سرور ۱» هدایت شوند. اگر درخواستی به سرورهای دیگر مانند «سرور ۲» ارسال شود، احراز هویت با شکست مواجه می‌شود، زیرا «سرور ۲» حاوی داده‌های نشست کاربر A نیست. به همین ترتیب، تمام درخواست‌های HTTP کاربر B باید به «سرور ۲» و تمام درخواست‌های کاربر C باید به «سرور ۳» هدایت شوند.مشکل اینجاست که هر درخواست از یک کلاینت مشخص، باید دقیقاً به همان سرور قبلی هدایت شود. این کار در اکثر متعادل‌کننده‌های بار (Load Balancers) از طریق قابلیت Sticky Sessions (نشست‌های چسبنده) قابل انجام است؛ اما این روش بار اضافی (Overhead) به سیستم تحمیل می‌کند. علاوه بر این، با این رویکرد، اضافه یا حذف کردن سرورها بسیار دشوارتر می‌شود و مدیریت خرابی سرورها نیز به چالشی جدی تبدیل می‌گردد.معماری بدون وضعیت (Stateless Architecture)شکل ۱۳ معماری بدون وضعیت را نشان می‌دهد.شکل 13‫Gemini گفتدر این معماری بدون وضعیت (Stateless)، درخواست‌های HTTP کاربران می‌تواند به هر یک از سرورهای وب ارسال شود؛ این سرورها داده‌های وضعیت (State) را از یک ذخیره‌ساز داده‌ی مشترک واکشی می‌کنند. در این حالت، داده‌های وضعیت در یک منبع مشترک ذخیره شده و خارج از سرورهای وب نگه داشته می‌شوند. یک سیستم بدون وضعیت، ساده‌تر، مقاوم‌تر و مقیاس‌پذیرتر است.شکل ۱۴ طراحی به‌روزرسانی‌شده را با یک لایه وب بدون وضعیت نشان می‌دهد.شکل 14در شکل ۱۴، ما داده‌های نشست (Session) را از لایه وب خارج کرده و آن‌ها را در یک ذخیره‌ساز داده پایدار ذخیره می‌کنیم. این ذخیره‌ساز مشترک می‌تواند یک پایگاه داده رابطه‌ای، Memcached/Redis، NoSQL و غیره باشد. در اینجا پایگاه داده NoSQL انتخاب شده است زیرا مقیاس‌دهی آن آسان است. مقیاس‌دهی خودکار (Autoscaling) به معنای اضافه یا حذف کردن خودکار سرورهای وب بر اساس حجم ترافیک است. پس از خارج کردن داده‌های وضعیت از سرورهای وب، مقیاس‌دهی خودکار لایه وب با افزودن یا حذف سرورها بسته به بار ترافیکی، به راحتی قابل دستیابی است.وب‌سایت شما به سرعت رشد کرده و تعداد قابل توجهی کاربر بین‌المللی جذب می‌کند. برای بهبود در دسترس بودن (Availability) و ارائه تجربه کاربری بهتر در مناطق جغرافیایی وسیع‌تر، پشتیبانی از مراکز داده متعدد (Data Centers) حیاتی است.مراکز داده (Data Centers)شکل ۱۵ یک نمونه پیکربندی با دو مرکز داده را نشان می‌دهد. در وضعیت عادی، کاربران از طریق geoDNS (که به آن مسیریابی جغرافیایی یا geo-routed نیز گفته می‌شود) به نزدیک‌ترین مرکز داده هدایت می‌شوند؛ به طوری که برای مثال $x\%$ ترافیک به منطقه شرق آمریکا (US-East) و $(100 - x)\%$ به غرب آمریکا (US-West) ارسال می‌شود. geoDNS یک سرویس DNS است که اجازه می‌دهد نام‌های دامنه بر اساس موقعیت مکانی کاربر، به آدرس‌های IP مشخصی ترجمه شوند.شکل 15در صورت بروز هرگونه قطعی گسترده در مرکز داده، تمام ترافیک را به سمت یک مرکز داده سالم هدایت می‌کنیم. در شکل ۱۶، مرکز داده شماره ۲ (غرب آمریکا - US-West) آفلاین شده است و ۱۰۰٪ ترافیک به سمت مرکز داده شماره ۱ (شرق آمریکا - US-East) مسیریابی می‌شود.شکل 16برای دستیابی به ساختار چند مرکز داده‌ای (Multi-data center)، باید چندین چالش فنی حل شود:هدایت مجدد ترافیک (Traffic redirection): ابزارهای مؤثری برای هدایت ترافیک به مرکز داده صحیح مورد نیاز است. می‌توان از GeoDNS برای هدایت ترافیک به نزدیک‌ترین مرکز داده بر اساس محل استقرار کاربر استفاده کرد.همگام‌سازی داده‌ها (Data synchronization): کاربران مناطق مختلف ممکن است از پایگاه‌های داده یا کش‌های محلی متفاوتی استفاده کنند. در موارد خرابی و انتقال ترافیک (Failover)، ممکن است ترافیک به مرکز داده‌ای هدایت شود که داده‌های مورد نظر در آن موجود نیست. یک استراتژی رایج، تکثیر داده‌ها (Replication) در چندین مرکز داده است. یک مطالعه پیشین نشان می‌دهد که نتفلیکس چگونه تکثیر ناهمگام (Asynchronous) داده‌ها را در چندین مرکز داده پیاده‌سازی می‌کند.تست و استقرار (Test and deployment): در تنظیمات چند مرکز داده‌ای، آزمایش وب‌سایت/اپلیکیشن در مکان‌های مختلف اهمیت حیاتی دارد. ابزارهای استقرار خودکار (Automated deployment) برای حفظ یکپارچگی سرویس‌ها در تمام مراکز داده ضروری هستند.برای مقیاس‌دهی بیشتر سیستم، نیاز داریم تا اجزای مختلف سیستم را از هم جدا (Decouple) کنیم تا بتوانند به‌طور مستقل مقیاس‌پذیر شوند. صف پیام (Message Queue) یک استراتژی کلیدی است که در بسیاری از سیستم‌های توزیع‌شده واقعی برای حل این مشکل به کار گرفته می‌شود.صف پیام (Message Queue)صف پیام یک جزء بادوام (Durable) است که در حافظه ذخیره شده و از ارتباطات ناهمگام (Asynchronous) پشتیبانی می‌کند. این جزء به عنوان یک بافر عمل کرده و درخواست‌های ناهمگام را توزیع می‌کند. معماری پایه یک صف پیام ساده است: سرویس‌های ورودی که تولیدکننده (Producers/Publishers) نامیده می‌شوند، پیام‌ها را ایجاد کرده و در صف پیام منتشر می‌کنند. سرویس‌ها یا سرورهای دیگر که مصرف‌کننده (Consumers/Subscribers) نامیده می‌شوند، به صف متصل شده و عملیات تعریف‌شده در پیام‌ها را انجام می‌دهند. این مدل در شکل ۱۷ نشان داده شده است.شکل 17جداسازی اجزا (Decoupling)، صف پیام را به معماری محبوبی برای ساخت اپلیکیشن‌های مقیاس‌پذیر و قابل‌اطمینان تبدیل می‌کند. با استفاده از صف پیام، تولیدکننده می‌تواند زمانی که مصرف‌کننده برای پردازش در دسترس نیست، پیام را در صف قرار دهد. همچنین مصرف‌کننده می‌تواند پیام‌ها را از صف بخواند، حتی اگر تولیدکننده در آن لحظه در دسترس نباشد.مورد کاربری (Use case) زیر را در نظر بگیرید: اپلیکیشن شما از قابلیت‌های سفارشی‌سازی عکس، از جمله برش (Cropping)، افزایش وضوح (Sharpening)، محو کردن (Blurring) و غیره پشتیبانی می‌کند. انجام این وظایف زمان‌بر است. در شکل ۱۸، وب‌سرورها وظایف پردازش عکس را در صف پیام منتشر می‌کنند. سپس، کارگرهای پردازش عکس (Photo processing workers) وظایف را از صف پیام برداشته و عملیات سفارشی‌سازی عکس را به‌صورت ناهمگام (Asynchronous) انجام می‌دهند.در این ساختار، تولیدکننده و مصرف‌کننده می‌توانند به‌طور مستقل مقیاس‌دهی شوند. وقتی حجم صف بزرگ می‌شود، می‌توان کارگرهای (Workers) بیشتری اضافه کرد تا زمان پردازش کاهش یابد. با این حال، اگر صف در بیشتر مواقع خالی باشد، می‌توان تعداد کارگرها را کاهش داد.شکل 18گزارش‌گیری، معیارها و اتوماسیون (Logging, Metrics, Automation)هنگام کار با یک وب‌سایت کوچک که روی چند سرور محدود اجرا می‌شود، استفاده از گزارش‌گیری، معیارها و ابزارهای اتوماسیون یک «رویکرد خوب» است اما ضرورت حیاتی ندارد. با این حال، اکنون که سایت شما برای خدمات‌رسانی به یک کسب‌وکار بزرگ رشد کرده است، سرمایه‌گذاری روی این ابزارها الزامی است.گزارش‌گیری (Logging): پایش گزارش‌های خطا (Error Logs) اهمیت زیادی دارد، زیرا به شناسایی خطاها و مشکلات سیستم کمک می‌کند. شما می‌توانید گزارش‌های خطا را در سطح هر سرور بررسی کنید یا از ابزارهایی برای تجمیع آن‌ها در یک سرویس متمرکز استفاده کنید تا جستجو و مشاهده آن‌ها آسان‌تر شود.معیارها (Metrics): جمع‌آوری انواع مختلف معیارها به ما کمک می‌کند تا بینش‌های تجاری کسب کرده و از وضعیت سلامت سیستم آگاه شویم. برخی از معیارهای زیر مفید هستند:معیارهای سطح میزبان (Host level): مانند CPU، حافظه (Memory)، ورودی/خروجی دیسک (Disk I/O) و غیره.معیارهای سطح تجمیعی (Aggregated level): برای مثال، عملکرد کل لایه پایگاه داده، لایه حافظه پنهان و غیره.معیارهای کلیدی کسب‌وکار: مانند کاربران فعال روزانه (DAU)، نرخ بازگشت کاربر (Retention)، درآمد و غیره.اتوماسیون (Automation): وقتی سیستم بزرگ و پیچیده می‌شود، برای افزایش بهره‌وری نیاز به ساخت یا بهره‌گیری از ابزارهای اتوماسیون داریم. یکپارچگی مداوم (Continuous Integration) یک تمرین مناسب است که در آن هر بار ثبت کد (Code check-in) از طریق اتوماسیون تایید می‌شود و به تیم‌ها اجازه می‌دهد مشکلات را زودتر شناسایی کنند. علاوه بر این، خودکارسازی فرآیندهای ساخت (Build)، تست، استقرار (Deploy) و غیره می‌تواند بهره‌وری توسعه‌دهندگان را به شکل قابل توجهی افزایش دهد.افزودن صف‌های پیام و ابزارهای مختلفشکل ۱۹ طراحی به‌روزرسانی‌شده را نشان می‌دهد. به دلیل محدودیت فضا، تنها یک مرکز داده در تصویر نمایش داده شده است.۱. این طراحی شامل یک صف پیام (Message Queue) است که به سیستم کمک می‌کند تا اجزای آن وابستگی کمتری به هم داشته باشند (Loosely coupled) و در برابر خرابی‌ها مقاوم‌تر شود. ۲. ابزارهای گزارش‌گیری، پایش (Monitoring)، معیارها و اتوماسیون به سیستم اضافه شده‌اند.شکل 19با افزایش روزافزون داده‌ها، پایگاه داده شما بیش از پیش تحت فشار قرار می‌گیرد. اکنون زمان آن فرا رسیده است که لایه داده را مقیاس‌دهی کنید.مقیاس‌دهی پایگاه داده (Database Scaling)به‌طور کلی دو رویکرد برای مقیاس‌دهی پایگاه داده وجود دارد: مقیاس‌دهی عمودی و مقیاس‌دهی افقی.مقیاس‌دهی عمودی (Vertical Scaling)مقیاس‌دهی عمودی که با نام Scaling Up نیز شناخته می‌شود، به معنای افزودن قدرت بیشتر (CPU، رم، دیسک و غیره) به یک ماشین موجود است. سرورهای پایگاه داده بسیار قدرتمندی وجود دارند؛ به عنوان مثال، طبق مستندات سرویس پایگاه داده رابطه‌ای آمازون (RDS)، شما می‌توانید سروری با ۲۴ ترابایت رم تهیه کنید. این نوع سرورهای قدرتمند می‌توانند حجم عظیمی از داده را ذخیره و مدیریت کنند. برای مثال، سایت stackoverflow.com در سال ۲۰۱۳ با وجود داشتن بیش از ۱۰ میلیون بازدیدکننده منحصربه‌فرد ماهانه، تنها از یک پایگاه داده اصلی (Master) استفاده می‌کرد. با این حال، مقیاس‌دهی عمودی با معایب جدی همراه است:شما می‌توانید CPU و رم بیشتری اضافه کنید، اما محدودیت‌های سخت‌افزاری وجود دارد. اگر پایگاه کاربران شما بسیار بزرگ باشد، یک سرور واحد پاسخگو نخواهد بود.ریسک بالاتری برای ایجاد نقطه شکست واحد (SPOF) وجود دارد.هزینه کلی مقیاس‌دهی عمودی بالاست؛ سرورهای فوق‌قدرتمند بسیار گران‌تر هستند.مقیاس‌دهی افقی (Horizontal Scaling)مقیاس‌دهی افقی که با عنوان شاردینگ (Sharding) نیز شناخته می‌شود، روشی است که در آن سرورهای بیشتری به سیستم اضافه می‌گردد.شکل ۲۰ تفاوت بین مقیاس‌دهی عمودی و افقی را با هم مقایسه می‌کند.شکل 20شاردینگ (Sharding) پایگاه‌های داده بزرگ را به بخش‌های کوچک‌تر و قابل‌مدیریت‌تری به نام شارد (Shard) تقسیم می‌کند. هر شارد از طرح‌واره (Schema) یکسانی بهره می‌برد، اما داده‌های واقعی موجود در هر شارد، منحصر به همان بخش است.شکل ۲۱ نمونه‌ای از پایگاه‌های داده شاردشده را نشان می‌دهد. داده‌های کاربران بر اساس شناسه کاربری (User ID) به یک سرور پایگاه داده اختصاص می‌یابند. هر زمان که بخواهید به داده‌ای دسترسی پیدا کنید، از یک تابع هش (Hash Function) برای یافتن شارد مربوطه استفاده می‌شود. در این مثال، از فرمول $user\_id \pmod 4$ به عنوان تابع هش استفاده شده است. اگر باقیمانده برابر با ۰ باشد، از «شارد ۰» برای ذخیره و واکشی داده‌ها استفاده می‌شود؛ اگر برابر با ۱ باشد، از «شارد ۱» استفاده خواهد شد و همین منطق برای سایر شاردها نیز اعمال می‌گردد.شکل 21شکل ۲۲ جدول کاربران را در پایگاه‌های داده شاردشده (Sharded Databases) نشان می‌دهد.در این ساختار، به جای اینکه تمام داده‌های کاربران در یک جدول عظیم ذخیره شوند، داده‌ها در چندین سرور (شارد) توزیع شده‌اند. هر سطر بر اساس مقدار تابع هش (در اینجا شناسه کاربر) در شارد مشخصی قرار می‌گیرد تا بار پردازشی و حجم ذخیره‌سازی بین سرورها تقسیم شود.شکل 22مهم‌ترین عاملی که باید هنگام پیاده‌سازی استراتژی شاردینگ در نظر گرفت، انتخاب کلید شاردینگ (Sharding Key) است. کلید شاردینگ (که به آن کلید پارتیشن نیز می‌گویند) از یک یا چند ستون تشکیل شده است که نحوه توزیع داده‌ها را تعیین می‌کنند. همان‌طور که در شکل ۲۲ نشان داده شد، user_id همان کلید شاردینگ است. یک کلید شاردینگ به شما اجازه می‌دهد تا با مسیریابی پرس‌وجوها (Queries) به پایگاه داده صحیح، داده‌ها را به‌طور کارآمد بازاریابی کرده و تغییر دهید. هنگام انتخاب کلید شاردینگ، یکی از مهم‌ترین معیارها انتخاب کلیدی است که بتواند داده‌ها را به‌طور یکنواخت توزیع کند.شاردینگ تکنیک فوق‌العاده‌ای برای مقیاس‌دهی پایگاه داده است، اما اصلاً راهکار بی‌نقصی نیست؛ چرا که پیچیدگی‌ها و چالش‌های جدیدی را به سیستم تحمیل می‌کند:تغییر شاردبندی داده‌ها (Resharding): این کار زمانی لازم است که: ۱) یک شارد واحد به دلیل رشد سریع دیگر نتواند داده بیشتری را در خود جای دهد. ۲) برخی شاردها به دلیل توزیع نامتوازن داده، زودتر از بقیه دچار ظرفیت‌زدگی (Exhaustion) شوند. وقتی ظرفیت یک شارد تمام می‌شود، باید تابع شاردینگ به‌روزرسانی شده و داده‌ها جابه‌جا شوند. هشینگ سازگار (Consistent Hashing) تکنیکی رایج برای حل این مشکل است.مشکل سلبریتی‌ها (Celebrity problem): به این مسئله، مشکل «کلید داغ» (Hotspot key) نیز می‌گویند. دسترسی بیش از حد به یک شارد خاص می‌تواند باعث اضافه‌بار سرور شود. تصور کنید داده‌های کتی پری، جاستین بیبر و لیدی گاگا همگی در یک شارد قرار بگیرند؛ در اپلیکیشن‌های اجتماعی، آن شارد تحت فشار شدید عملیات خواندن قرار خواهد گرفت. برای حل این مشکل، ممکن است مجبور شویم برای هر سلبریتی یک شارد اختصاصی در نظر بگیریم و یا هر شارد را دوباره بخش‌بندی کنیم.جوئین و غیرنرمال‌سازی (Join and de-normalization): وقتی یک پایگاه داده در چندین سرور شارد می‌شود، انجام عملیات Join روی شاردهای مختلف دشوار خواهد بود. یک راهکار رایج، غیرنرمال‌سازی (De-normalization) پایگاه داده است تا پرس‌وجوها بتوانند تنها در یک جدول واحد انجام شوند.در شکل ۲۳، ما پایگاه‌های داده را برای پشتیبانی از ترافیکِ داده‌ای که به سرعت در حال افزایش است، شارد می‌کنیم. هم‌زمان، برخی از قابلیت‌های غیررابطه‌ای را به یک ذخیره‌ساز داده NoSQL منتقل می‌کنیم تا بار پایگاه داده کاهش یابد.شکل 23میلیون‌ها کاربر و فراتر از آنمقیاس‌دهی یک سیستم یک فرآیند تکرارپذیر (Iterative) است. تکرار و تمرین بر اساس آنچه در این فصل آموخته‌ایم، می‌تواند ما را تا مسیر زیادی پیش ببرد. برای فراتر رفتن از مرز میلیون‌ها کاربر، به بهینه‌سازی‌های دقیق‌تر و استراتژی‌های جدیدی نیاز است. به عنوان مثال، ممکن است نیاز باشد سیستم خود را بهینه‌سازی کرده و آن را به سرویس‌های کوچک‌تر (Microservices) تجزیه کنید. تمام تکنیک‌های آموخته‌شده در این فصل، پایه و اساس خوبی برای مقابله با چالش‌های جدید فراهم می‌کند.در پایان این فصل، خلاصه‌ای از چگونگی مقیاس‌دهی سیستم برای پشتیبانی از میلیون‌ها کاربر ارائه می‌دهیم:لایه وب را بدون وضعیت (Stateless) نگه دارید.در هر لایه، قابلیت افزونگی (Redundancy) ایجاد کنید.تا حد امکان داده‌ها را کش (Cache) کنید.از چندین مرکز داده (Data Centers) پشتیبانی کنید.دارایی‌های ایستا را در CDN میزبانی کنید.لایه داده‌های خود را با استفاده از شاردینگ (Sharding) مقیاس‌دهی کنید.لایه ها را به سرویس‌های مجزا تقسیم کنید.سیستم خود را پایش (Monitor) کرده و از ابزارهای اتوماسیون استفاده کنید.تبریک می‌گویم که تا اینجا پیش آمدید! حالا می‌توانید به خودتان افتخار کنید. کارتان عالی بود!منابع و مراجع[۱] پروتکل انتقال ابرمتن (HTTP): https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol[۲] آیا باید فراتر از پایگاه‌های داده رابطه‌ای رفت؟: https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases[۳] تکثیر (Replication): https://en.wikipedia.org/wiki/Replication_(computing[۴] تکثیر چند-اصلی (Multi-master replication): https://en.wikipedia.org/wiki/Multi-master_replication[۵] تکثیر کلاستر NDB: تکثیر دوطرفه و حلقوی: https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-replication-multi-source.html[۶] استراتژی‌های حافظه پنهان و نحوه انتخاب گزینه مناسب: https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/[۷] نیشتالا و همکاران، "مقیاس‌دهی Memcache در فیس‌بوک،" دهمین سمپوزیوم USENIX در طراحی و پیاده‌سازی سیستم‌های شبکه‌ای (NSDI ’13): https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf[۸] نقطه شکست واحد (SPOF): https://en.wikipedia.org/wiki/Single_point_of_failure[۹] تحویل محتوای پویا در Amazon CloudFront: https://aws.amazon.com/cloudfront/dynamic-content/[۱۰] پیکربندی Sticky Sessions برای Load Balancer کلاسیک: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html[۱۱] معماری Active-Active برای تاب‌آوری چند-منطقه‌ای: https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b[۱۲] نمونه‌های Amazon EC2 با حافظه بالا (High Memory Instances): https://aws.amazon.com/ec2/instance-types/high-memory/[۱۳] آنچه برای اجرای Stack Overflow لازم است: http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow[۱۴] واقعاً برای چه کارهایی از NoSQL استفاده می‌کنید؟: http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html

بررسی اجمالی داکر

محسن نیک نژاد — Tue, 24 Mar 2020 17:28:34 +0430

داکر یک سرویس مدیریت کانتیرهاست. داکر از سه کلمه کلیدی (Build,Ship,RUN) به تفسیر من توسعه بده ، ببر تو عمل ، اجرا کن و حالشو ببره.ایده اصلی داکر اینه که به راحتی توسعه بدی و از محیط توسعه خیلی سریع محصولت رو ببری تو عمل بدون اینکه نگران اجرا شدنش یا همون ترس بلو پیج باشی.اولین نسخه داکر سال 2013 اومد و در حال حاضر به شاه بیت توسعه چابک در مواجهه با پروژه های مختلف شده استسایت اصلی داکرویژگی های داکر:داکر با کمترین اثرگذاری مشکلات توسعه مبتنی بر سیستم عامل ، میتونه زمان توسعه و تحویل رو به مقدار قابل ملاحظه ای کاهش بده بره.با داشتن کانتینرها، کار یکپارچه سازی برنامه ها ، کنترل کیفیت ، تست ، توسعه و نگهداری خیلی راحت میشه.میتونید کانیتنرهاتون رو هرجایی خواستین از ابر گرفته ، سرور سازمانی یا ماشین محلی خودتون برپت کنید و استفاده کنید.از اونجا که کانتینرها خیلی کم حجم و چابکن ، خوراک مقیاس پذیری هستن.مولفه های مختلف داکر:داکر مولفه های زیر را داراست:داکر برای مک: به داکر اجازه میده کانتینرها را در IOS اجرا کنه.داکر بر ویندوز: اجازه میده کانتینرها در ویندوز اجرا بشه.داکر برای لینوکس: اجازه اجرای کانتینرها در لینوکس رو میده.موتور داکر(Docker Engine):برای ساخت imageها و کانتینرها به کار برده میشه.داکر هاب(Docker Hub): محلی برای هاست کردن کانتینرها و imageهای مختلف.داکر کامپوز(Docker Compose):برای ساخت برنامه های کامل تشکیل شده از چند کانتینر استفاده میشهسایت اصلی داکر https://www.docker.com که میتونید مستندات بهتری اونجا پیدا کنید.

آموزش داکر:: فصل اول :: نگهداشت مرتب و قابل اطمینان یک کامپیوتر

محسن نیک نژاد — Tue, 24 Mar 2020 02:26:15 +0430

سرفصل های این فصل:. داکر چیه. مقدمه ای بر کانتینرها. مسائل آدرس دهی داکر . کی ، کجا و چطوری باید از داکرها استفاده کرد. مثال همیشگی Hello Worldداکر چیه؟داکر یک برنامه خط فرمان باحاله ، که در سرویس های پس زمینه در حال اجراست (یک Daemon) و

داکر در عمل ::‌ درک انعطاف پذیری کانتینرها

محسن نیک نژاد — Sat, 29 Feb 2020 17:56:31 +0330

بهترین راه برای فهمیدن اینکه چرا به سادگینمیتوان کانتینرها دارای محدودیت مانند NGINX را ایجاد کرد بهتر است بگذاریم خودتان با ایده خودتان که قطعاً بد خواهد بود امتحان کنید:docker run -d --name webid nginx 1 docker run -d --name webid nginx 2 در هنگام اجرای دستور دوم به خاطر تداخل دستورات با خطایی مانند خطای زیر روبرو خواهیدشد:FATA[0000] Error response from daemon: Conflict. The name "webid" is already in use by container 2b5958ba6a00. You have to delete (or rename) that container to be able to reuse that name.استفاده از اسامی کانتینر ثابت مانند وب برای آزمایش و مستندات مفید است ، اما در سیستمی با چندین کانتینر ، استفاده از نامهای ثابت مانند آن می تواند درگیری ایجاد کند.به طور پیش فرض ، داکر به هر کانتینری كه ایجاد می كند نامی منحصر به فرد (انسان دوستانه) اختصاص می دهد.با استفاده از ویژگی دیگر نیازی به استفاده از نشان --name نمی باشد.اگر شرایطی ایجاد شد که نیاز به تغییر نام یک کانتینر داشتید می توانید از دستور docker rename استفاده کنید:docker rename webid webid-old 1 docker run -d --name webid nginx 2 در دستور اول webid به webid-old تغییر نام داده می شود.در دستور دوم یک کانتینر با نام webid ایجاد می شود.تغییر نام کانتینرها می تواند به کاهش تعارضات نامگذاری یک طرفه کمک کند اما در وهله اول کمک چندانی به جلوگیری از بروز مشکل نمی کند.علاوه بر نام ، Docker شناسه منحصر به فردی را اختصاص می دهد که در مثال اول به آن اشاره شد.این اعداد 1024 بیتی رمزگذاری شده هگز شده و چیزی شبیه به این است:7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5هنگامی که کانتینرها در حالت جداگانه شروع می شوند ، شناسه آنها در ترمینال چاپ می شود.می توانید به جای نام کانتینر با هر دستوری که نیاز به شناسایی یک کانتینر خاص دارد از این شناسه ها استفاده کنید.به عنوان مثال ، می توانید از شناسه قبلی با دستور توقف یا اجرای استفاده کنید:docker exec \ 7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5 \ echo hello docker stop \ 7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5احتمال بالای یگانگی شناسه هایی که ایجاد می‌شوند به این معنی است که احتمال برخورد با شناسه تکراری وجود ندارد.همچنین بعید است که حتی یک برخورد با ۱۲ کاراکتر اول این شناسه روی یک کامپیوتر وجود داشته باشد.پس در اکثر رابط های docker،دوازده کاراکتر ابتدایی قطعا متفاوت خواهد بود و می توانید به جای رشته طولانی از ۱۲ کاراکتر ابتدایی استفاده کنید.این باعث می شود شناسه های تولید شده کمی کاربر پسند تر شوند. می توانید از آنها در هر کجا که شناسه ظرف مورد نیاز باشد استفاده کنید. دو دستور قبلی می تواند به صورت زیر نوشته شود:docker exec 7cb5d2b9a7ea ps docker stop 7cb5d2b9a7eaهیچ یک از این شناسه ها به خصوص برای استفاده انسان مناسب نیستند.اما آنها با اسکریپت ها و تکنیک های اتوماسیون خوب کار می کنند.Docker برای دستیابی به شناسه یک کانتینر چندین وسیله مختلف دارد تا اتوماسیون امکان پذیر باشد.در این موارد از شناسه عددی کامل یا کوتاه استفاده می شود.اولین روش برای بدست آوردن شناسه عددی یک کانتینر ، صرفاً شروع یا ایجاد یک مورد جدید و اختصاص نتیجه دستور به متغیر shell است.همانطور که قبلاً دیدید ، هنگامی که یک کانتینر جدید در حالت جداگانه شروع می شود ، شناسه کانتینر به ترمینال (stdout) نوشته می شود.اگر این تنها راه برای دریافت شناسه در زمان ایجاد بود، قادر به استفاده از این کانتینرهای تعاملی نخواهید بود(منظور ایجاد کانتینرها بدون اجرا ).خوشبختانه می‌توانید از یک فرمان دیگر برای ایجاد یک ظرف بدون شروع آن استفاده کنید.فرمان docker create شبیه به docker run است ، تفاوت اصلی این است که ظرف در حالت متوقف ایجاد می شود:docker create nginxنتیجه باید مانند این خط باشد:b26a631e536d3caae348e9fd36e7661254a11511eb2274fb55f9f7c788721b0dاگر از پوسته فرمان Linux مانند sh یا bash استفاده می کنید ، می توانید نتیجه را به متغیر پوسته اختصاص دهید و بعداً دوباره از آن استفاده کنید:CID=$(docker create nginx:latest) 1 echo $CID این روی پوسته های سازگار با POSIX کار خواهد کرد.متغیرهای شل یک فرصت جدید برای تعارض ایجاد می‌کنند، اما دامنه آن تعارض محدود به نشست پایانه یا محیط پردازش فعلی است که در آن متن راه‌اندازی شد.آن تعارضات باید به راحتی قابل اجتناب باشند چون یک برنامه یا برنامه مدیریت آن محیط را مدیریت می‌کند.مشکلی که در این رویکرد وجود دارد این است که اگر چندین کاربر یا فرآیندهای خودکار نیاز به اشتراک این اطلاعات داشته باشند، به این مساله کمک نخواهد کرد.در این موارد ، می توانید از شناسه کانتینر (CID) استفاده کنید.هر دو دستور docker run و docker create از یک پارامتر خاص برای این منظور استفاده می کنند:docker create --cidfile /tmp/web.cid nginx 1 cat /tmp/web.cid 2 یک کانتینر متوقف شده جدید ایجاد می کند.فایل ایجاد شده را باز می کند.بهترین راه برای فهمیدن اینکه چرا به سادگینمیتوان کانتینرها دارای محدودیت مانند NGINX را ایجاد کرد بهتر است بگذاریم خودتان با ایده خودتان که قطعاً بد خواهد بود امتحان کنید:docker run -d --name webid nginx 1 docker run -d --name webid nginx 2 یک کانتینر با نام webid ایجاد می کندیک کانتینر دیکر با همان نام ایجاد میکند.در هنگام اجرای دستور دوم به خاطر تداخل دستورات با خطایی مانند خطای زیر روبرو خواهید شد:FATA[0000] Error response from daemon: Conflict. The name "webid" is already in use by container 2b5958ba6a00. You have to delete (or rename) that container to be able to reuse that name.استفاده از اسامی کانتینر ثابت مانند وب برای آزمایش و مستندات مفید است ، اما در سیستمی با چندین کانتینر ، استفاده از نامهای ثابت مانند آن می تواند درگیری ایجاد کند.به طور پیش فرض ، داکر به هر کانتینری كه ایجاد می كند نامی منحصر به فرد (انسان دوستانه) اختصاص می دهد.با استفاده از ویژگی دیگر نیازی به استفاده از نشان --name نمی باشد.اگر شرایطی ایجاد شد که نیاز به تغییر نام یک کانتینر داشتید می توانید از دستور docker rename استفاده کنید:docker rename webid webid-old 1 docker run -d --name webid nginx 2 در دستور اول webid به webid-old تغییر نام داده می شود.در دستور دوم یک کانتینر با نام webid ایجاد می شود.تغییر نام کانتینرها می تواند به کاهش تعارضات نامگذاری یک طرفه کمک کند اما در وهله اول کمک چندانی به جلوگیری از بروز مشکل نمی کند.علاوه بر نام ، Docker شناسه منحصر به فردی را اختصاص می دهد که در مثال اول به آن اشاره شد.این اعداد 1024 بیتی رمزگذاری شده هگز شده و چیزی شبیه به این است:7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5هنگامی که کانتینرها در حالت جداگانه شروع می شوند ، شناسه آنها در ترمینال چاپ می شود.می توانید به جای نام کانتینر با هر دستوری که نیاز به شناسایی یک کانتینر خاص دارد از این شناسه ها استفاده کنید.به عنوان مثال ، می توانید از شناسه قبلی با دستور توقف یا اجرای استفاده کنید:docker exec \ 7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5 \ echo hello docker stop \ 7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5احتمال بالای یگانگی شناسه هایی که ایجاد می‌شوند به این معنی است که احتمال برخورد با شناسه تکراری وجود ندارد.همچنین بعید است که حتی یک برخورد با ۱۲ کاراکتر اول این شناسه روی یک کامپیوتر وجود داشته باشد.پس در اکثر رابط های docker،دوازده کاراکتر ابتدایی قطعا متفاوت خواهد بود و می توانید به جای رشته طولانی از ۱۲ کاراکتر ابتدایی استفاده کنید.این باعث می شود شناسه های تولید شده کمی کاربر پسند تر شوند. می توانید از آنها در هر کجا که شناسه ظرف مورد نیاز باشد استفاده کنید. دو دستور قبلی می تواند به صورت زیر نوشته شود:docker exec 7cb5d2b9a7ea ps docker stop 7cb5d2b9a7eaهیچ یک از این شناسه ها به خصوص برای استفاده انسان مناسب نیستند.اما آنها با اسکریپت ها و تکنیک های اتوماسیون خوب کار می کنند.Docker برای دستیابی به شناسه یک کانتینر چندین وسیله مختلف دارد تا اتوماسیون امکان پذیر باشد.در این موارد از شناسه عددی کامل یا کوتاه استفاده می شود.اولین روش برای بدست آوردن شناسه عددی یک کانتینر ، صرفاً شروع یا ایجاد یک مورد جدید و اختصاص نتیجه دستور به متغیر shell است.همانطور که قبلاً دیدید ، هنگامی که یک کانتینر جدید در حالت جداگانه شروع می شود ، شناسه کانتینر به ترمینال (stdout) نوشته می شود.اگر این تنها راه برای دریافت شناسه در زمان ایجاد بود، قادر به استفاده از این کانتینرهای تعاملی نخواهید بود(منظور ایجاد کانتینرها بدون اجرا ).خوشبختانه می‌توانید از یک فرمان دیگر برای ایجاد یک ظرف بدون شروع آن استفاده کنید.فرمان docker create شبیه به docker run است ، تفاوت اصلی این است که ظرف در حالت متوقف ایجاد می شود:docker create nginxنتیجه باید مانند این خط باشد:b26a631e536d3caae348e9fd36e7661254a11511eb2274fb55f9f7c788721b0dاگر از پوسته فرمان Linux مانند sh یا bash استفاده می کنید ، می توانید نتیجه را به متغیر پوسته اختصاص دهید و بعداً دوباره از آن استفاده کنید:CID=$(docker create nginx:latest) 1 echo $CID1. این روی پوسته های سازگار با POSIX کار خواهد کرد. متغیرهای شل یک فرصت جدید برای تعارض ایجاد می‌کنند، اما دامنه آن تعارض محدود به نشست پایانه یا محیط پردازش فعلی است که در آن متن راه‌اندازی شد.آن تعارضات باید به راحتی قابل اجتناب باشند چون یک برنامه یا برنامه مدیریت آن محیط را مدیریت می‌کند.مشکلی که در این رویکرد وجود دارد این است که اگر چندین کاربر یا فرآیندهای خودکار نیاز به اشتراک این اطلاعات داشته باشند، به این مساله کمک نخواهد کرد.در این موارد ، می توانید از شناسه کانتینر (CID) استفاده کنید.هر دو دستور docker run و docker create از یک پارامتر خاص برای این منظور استفاده می کنند:docker create --cidfile /tmp/web.cid nginx 1 cat /tmp/web.cid 2 1. یک کانتینر متوقف شده جدید ایجاد می کند.2.فایل ایجاد شده را باز می کند.این ویژگی مانند استفاده از متغیرهای shell، این فرصت را برای تعارض افزایش می‌دهد. نام پرونده CID (که پس از cidfile-- ارایه شده‌است)باید شناخته شود یا ساختار شناخته‌شده‌ای داشته باشد.درست مانند نامگذاری یک کانتینر دستی، این روش از نام‌های شناخته‌شده در فضای نامی سراسری (docker - wide)استفاده می‌کند.خبر خوب این است که اگر این پرونده قبلاً وجود داشته باشد ، داکر با استفاده از پرونده CID ارائه شده ، ظرف جدیدی ایجاد نخواهد کرد.این فرمان درست مانند زمانی که شما دو کانتینر با همان نام ایجاد می‌کنید، شکست خواهد خورد.یکی از دلایل استفاده از فایلهای CID به جای اسم این است که پرونده های CID را می توان به راحتی با کانتینرها به اشتراک گذاشت و برای آن کانتینر تغییر نام داد.با استفاده از یک ویژگی Docker به نام volume ، که به آن خواهیم بعدا به آن خواهیم پرداخت.نام پرونده CID (که پس از cidfile-- ارایه شده‌است)باید شناخته شود یا ساختار شناخته‌شده‌ای داشته باشد.درست مانند نامگذاری یک کانتینر دستی، این روش از نام‌های شناخته‌شده در فضای نامی سراسری (docker - wide)استفاده می‌کند.خبر خوب این است که اگر این پرونده قبلاً وجود داشته باشد ، داکر با استفاده از پرونده CID ارائه شده ، ظرف جدیدی ایجاد نخواهد کرد.این فرمان درست مانند زمانی که شما دو کانتینر با همان نام ایجاد می‌کنید، شکست خواهد خورد.یکی از دلایل استفاده از فایلهای CID به جای اسم این است که پرونده های CID را می توان به راحتی با کانتینرها به اشتراک گذاشت و برای آن کانتینر تغییر نام داد.با استفاده از یک ویژگی Docker به نام volume ، که به آن خواهیم بعدا به آن خواهیم پرداخت.نکته:یک استراتژی برای رسیدگی به مشکلات تداخلات در فایل های CID عبارت است از تقسیم فضای نام با استفاده از قراردادهای معروف یا قابل‌پیش‌بینی.برای مثال، در این سناریو، شما ممکن است از مسیری استفاده کنید که شامل همه کانتینرها تحت یک دایرکتوری مشخص باشد و قسمت بعدی آن دایرکتوری را با شناسه مشتری تقسیم کنید. نتیجه این عمل چیزی شبیه این است/containers/web/customer1/web.cidیا/containers/web/customer8/web.cidدر موارد دیگر ، می توانید از دستورات دیگری مانند docker ps برای دریافت شناسه یک ظرف استفاده کنید. به عنوان مثال ، اگر می خواهید شناسه مختصر آخرین ظرف ایجاد شده را بدست آورید ، می توانید از این موارد استفاده کنید:CID=$(docker ps --latest --quiet) 1 echo $CID CID=$(docker ps -l -q) 2 echo $CID۱. این روی پوسته های سازگار با POSIX کار خواهد کرد.۲. مانند دستور بالا اما در فرم مختصر نوشته شده است.نکته: اگر می خواهید شناسه کامل کانتینر را بدست آورید ، می توانید از گزینه --no-trunc در دستور docker ps استفاده کنید.موارد اتوماسیون تحت پوشش ویژگی هایی است که تاکنون مشاهده کرده اید. اما حتی اگر کمک به کوتاه کردن رشته ها کند ،باز هم این شناسه های کانتینر به ندرت قابل خواندن یا به خاطر سپردن آسان است. به همین دلیل ، داکر همچنین برای هر ظرف نامهای قابل خواندن برای انسان تولید می کند.کنوانسیون نامگذاری از یک صفت شخصی استفاده می کند. زیرنویس؛ و نام خانوادگی یک دانشمند ، مهندس ، مخترع یا دیگر رهبران صاحب تأثیر.برخی اسامی تولید شدهcompassionate_swartz, hungry_goodall, distracted_turingبه نظر می‌رسد که اینها به نقطه مناسبی برای خوانایی و حافظه می‌رسند. وقتی با ابزار docker به طور مستقیم کار می‌کنید، همیشه می‌توانید از docker ps برای نگاه به نام های دوست دار انسان استفاده کنید.

داکر در عمل :: از بین بردن تداخلات ، ساخت یک فارم از سایت‌ها (ادامه سفارش مشتری)

محسن نیک نژاد — Sat, 12 Oct 2019 23:49:09 +0330

شما در بخش آخر متوجه شدید که چگونه می‌توان از تداخل نرم‌افزارها جلوگیری کرد. اما اگر در استفاده از داکر دقت نکنید می‌توانید سیستم‌هایی با تداخلات شدید در بین کانتینرها ایجاد کنید. مثال دیگری را در نظر بگیرید که مشتری از شما خواسته تعداد زیادی از وب سایت‌هایی آنها را میربانی کنید. آنها همچنین خواستار تکنولوژی‌های نظارتی مانند مثال قبل است. به سادگی می‌توانید سیستم قبلی را که ساخته‌اید گسترش دهید بدون اینکه تنظیمات ngnix را تغییر دهید. در این مثال شما یک سیستم با چندین وب سرور و هر وب یک ناظر عملکردی مانند مثال‌های قبل دارد. مانند معماری زیر:معماری کلان سفارش مشتریبخش اول تعدادی کانتینر وب داریم که به نظر از این ساده‌تر نداریم اما مشکل اصلی افزایش تعداد آنها است. در ادامه این سناریو رو بطور کامل پیاده سازی می‌کنیم.

داکر در عمل :: مسائل حل شده و فضای نامی PID

محسن نیک نژاد — Sat, 12 Oct 2019 23:21:29 +0330

هر برنامه در حال اجرا یا فرآیند- در ساختار لینوکس دارای یک شماره منحصر به فرد است این شناسه فرآیند (PID) نامیده می شود. فضای نام PID مجموعه ای از اعداد است که برای شناسایی فرایندها استفاده می‌شود. لینوکس امکاناتی جهت ایجاد فضای نامی PID چندگانه دارد.هر فضای نامی (Namespace) مجموعه ای کامل از PIDهای ممکن دارد.این بدان معنی است که هر فضای نامی PID حاوی PID 1 ، 2 ، 3 و غیره خواهد بود.فضاهای نامی چندگانه هستند یعنی ممکن است یک PID زیر مجموعه یک PID دیگر باشد که به آن نظارت دارد. یک فضای نامی، PID 1 ممکن است به یک پوسته فرمان مانند bash مراجعه کند.ایجاد یک فضای نامی PID منحصر برای یک کانتینر یکی از ویژگی‌های اصلی داکر است.موارد زیر را اجرا کنید تا در عمل تمام توضیحات را درک کنید:docker run -d --name namespaceA busybox:latest /bin/sh -c "sleep 30000" docker run -d --name namespaceB busybox:latest /bin/sh -c "nc -l -p 0.0.0.0:80" docker exec namespaceA ps #قسمت1 docker exec namespaceB ps #قسمت2فرمان صادر شده در قسمت 1 لیستی مانند زیر به نمایش در می‌آورد:PID USER COMMAND1 root /bin/sh -c sleep 300005 root sleep 30000 6 root psفرمان صادر شده در قسمت 2 لیستی مانند لیست بالا با کمی تغییرات ایجاد می‌کندPID USER COMMAND1 root /bin/sh -c sleep 300007 root sleep 30000 8 root psدر این مثال با docker exec می‌توانید دستوراتی که می‌خواهید را درون کانتینرها به اجرا در بیاورید. در این مثال ما از فرمان ps استفاده کردیم که برنامه‌های درحال اجرا به همراه PID آنها به نمایش در می‌آورد. همانطور که می‌بینید هر کانتینر PID 1 دارد. بدون فضای نامی PID، پردازش‌های درون یک کانتینر باید با مابقی میزبان‌های دیگر PID‌ها را به اشتراک بگذارد. مانند بسیاری از ویژگی‌های داکر، شما می‌توانید کانتینرهای سفارشی خود را بدون فضای نامی PID ایجاد کنید. شما خودتان می‌توانید با تنظیم PID-Flag در داکر شناسه‌های سفارشی خودتان را تنظیم کنید. حالا برای آزمون کردن این موارد آماده شود ، یک کانتینر BusyBox اجرا و دستور ps را امتحان کنید:docker run --pid host busybox:lastest psنکته: شما هم می‌توانید PID را جدا و هم یکپارچه با دستور بالا ببنیددر ادامه مثال پیشین، یعنی پایش وب سرور را در نظر بگیرید.فرض کنید از داکر استفاده نمی‌کنید و ngnixرا مستقیم روی کامپیوترتان اجرا کرده اید. دوباره فرض کنید فراموش کرده‌اید که ngnixروی سیستم خودتان دارید و پروژی جدیدی را با ngnix روی کامپیوترتان شروع می‌کنید ؛ قطعا قادر به اجرا ngnix جدید نخواهید بود چون قبلی تمام منابع را در دست گرفته و شما منابع لازم برای اجرای نسخه جدید را نخواهید داشت. این تنها یک نمونه کوچک از تداخلات نرم‌افزاری است. حالا همین کار رای برو یک کانتینر با دو اجرا ngnix انجام می‌دهیم:docker run –d --name webConflict nginx:latest docker logs webConflictبا اجرای دو دستور بالا قطعا موردی برای نمایش در خروجی نخواهیم داشتdocker exec webConflict nginx -g 'daemon off;'با اجرای دستور بالا خروجی مانند این خروجی خواهید داشت2019/03/29 22:04:35 [emerg] 10#0: bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) ...فرآیند دوم نمی‌تواند اجرا شود و پیام مبتنی بر استفاده از پورت را به شما می‌دهد. این مورد درگیری پورت (Port Conflict) نامیده می‌شود. این مسئله رایج در سیستم‌های دنیای واقعی می‌باشد. حال راهکار اجرا هر کدام آنها با استفاده از داکر است. مانند این:docker run -d --name webA nginx:latestابتدا یک نمونه از ngnix را با استفاده از داکر اجرا می‌کنیمdocker logs webAبررسی عملکرد ، احتمال بسیار زیاد خالی باشدdocker run -d --name webB nginx:latestحالا دومین نمونه را اجرا کردیمdocker logs webBبررسی عملکرد نسخه دوم، احتمال بسیار زیاد خالی می‌باشد.این کار یک راه حل عمومی برای برنامه‌هایی است که ممکن است با هم تداخل کنند. یک پارکینگ را در نظر بگیرید. پارکینگ دارای ویژگی‌های زیر است:سیستم پرداختچند فضای پارک اختصاصیفضای پارک شماره‌گذاری شدهبا اتصال این ویژگی‌های به رایانه ، منابع اشتراکی با یک رابط خاص را دارا هستیم. سیستم پرداخت ممکن است پول نقد قبول کند یا عابر بانک. کسانی که هر یک از این دو را دارند می‌توانند از جاهای پارک استفاده کنند. حالا اگر شخصی توان پرداخت نداشته باشد نمی‌تواند ماشین خود را پارک کند. به همین ترتیب، برنامه‌هایی که وابسته به برخی از مولفه‌های مشترک مانند نسخه خاصی از یک کتابخانه دارند قادر نخواهند بود بروی رایانه‌ای که نسخه دیگری از آن کتابخانه را دارد اجرا شوند. فضاهای رزرو شده استعاره‌ای است که نشان دهد منابع محدود و کمیاب هستند.مثلا در مثال پارکینگ اگر دو نفر یکجا را رزرو کنند تا زمانی که هر دو نخواهند همزمان از پارکینگ استفاده کنند مشکلی نیست اما در صورت درخواست همزمان تداخل رخ می‌دهد مانند مثال ngnix گفته شده. در نهایت، اگر جای پارک کس دیگری به یکی از طرفین اختصاص دهیم و صاحب آن باز گردد این مشکل دوباره رخ می‌دهد که کاری کاملا احمقانه است.برخی مشکلات منابع مشترک که می‎توانم به آنها اشاره کنم:دو برنامه به طور همزمان میخواهند به یک پورت شبکه متصل شوند.دو برنامه از یک فایل مشترک بهره می‌برند.دو برنامه می‌خواهند از نسخه‌های مختلف کتابخانه‌های نصب شده به صورت عمومی استفاده کنند.دو نسخه از یک برنامه می‌خواهند از یک PID مشترک استفاده کنند.دو برنامه که نصب دارید یک متغییر محیطی برنامه‌های دیگر را تغییر می‌دهد و موجب خرابی برنامه‌های دیگر می‌شود.تمام این مشکلات زمانی رخ می‌دهد که یک یا چند برنامه دارای وابستگی یکسان باشند.

داکر در عمل :: لیست ، متوقف، راه‌اندازی مجدد و نمایش خروجی کانتینرها(ادامه مثال پایش وب)

محسن نیک نژاد — Sun, 22 Sep 2019 01:17:09 +0330

سلام ، وقت بخیر همونطور که بخاطر دارین در پست قبلی هر سه ماشین مورد نیاز مثال مشتری را طبق شکل زیر راه‌اندازی کردیم و قرار شد قبل تحویل به مشتری حتما باید کانتینرها تست شونداولین کاری که برای تست میاز دارید این است که چک کنید چه کانتینرهای فعالی دارید، دستور زیر کانتینرهای در حال اجرا را به شما نمایش می دهدdocker psبا اجرای دستور بالا اطلاعات زیر نمایش داده می‌شود:شناسه کانتینرتصویر (image) استفاده شدهدستور اجرا شده در کانتینرمدت زمان ایجادمدت زمان اجراپورت‌های شبکهنام کانتینردر ایم مرحله شما باید سه کانتینر با نام‌های web، mailer و agent در حال اجرا داشته باشید، البته ممکن است از دستورات اشتباهی استفاده کرده باشید و یا اشتباهی یکی از آنها را متوقف کرده باشید، البته که داکر دارای منطق راه‌اندازی مجدد آنها است.مطابق دستور زیر یکبار راه اندازی مجدد کانتینرهای مشتری را تمرین می‌کنیم:docker restart web/mailer/agentحالا شما قطعا سه ماشین در حال اجرا دارید و باید تست کنید که بدرستی کار می‌کنند یا خیر. بهترین روش برای انجام اینکار، بررسی فایل‌های لاگ هر کانتینر می‌باشد، با کانتینر وب شروع می‌کنیم:docker logs webاگر کانتینر بدرستی و با صحت کامل کار کند پیام Get HTTP/1.0 200 را خواهیم داشت و در ترمینال چاپ می‌شود. در هر بار تست یک خط جدید به لاگ اضافه می‌شود. فرمان بالا جهت بررسی صحت عملکرد مفید است اما تکیه بر آن می‌تواند برای شما خطرناک باشد. هر چیزی که توسط برنامه‌ها در stdin و stdout نوشته می‌شود در این لاگ‌ها ثبت می‌شود. البته از آنجا که این لاگ فایل‌های همراه با چرخه عمر یک کانتینر رشد می‌کنند، استفاده طولانی مدت از آنها می‌تواند مشکلاتی را برای پردازش‌های مختلف در طولانی مدت ایجاد کند. راهکار بهتر استفاده از volumes است که در ادامه بحث خواهد شد.شما با همین روش لاگ‌خوانی می‌توانید کانتینرهای دیگر مثال را نیز بررسی کنید. برای تکمیل بحث ،لاگ‌های دو کانتینر دیگر را نیز بررسی می‌کنیم:docker logs mailer/agentبرای نمایش پیوسته لاگ از سوییچ follow-- یا f- استفاده می‌کنیم و برای توقف Ctrl+C را می‌زنیم.حالا که شما اعتبار کانتینرها را بررسی کردید و دید آنها در حال اجرا هستند، می‌بایستی بررسی کنیم با توقف وب سرور آیا کانتینر ناظر ما (agent) متوجه می‌شود وب سرور قطع شده است یا خیر.خوب حالا وارد عمل می‌شویم و دستورات زیر را برای تست وارد می‌کنیم:docker stop web #Adocker logs mailer #Bبخش A# : وب سرور با توجه به دستور متوقف می‌شود.بخش B#: چند ثانیه منتظر بمانید و لاگ‌های کانتینر پست‌الکترونیکی (mailer) را بررسی نمایید.به انتهای خط لاگ mailer نگاه کنید و یک فایل مانند زیر می‌بینیدSend Mail To: admin@work Message: Service is Down!خوب اگر تا اینجا تمامی دستورات را با دقت و با اصول آموزش داده پیش رفته باشید می‌توان گفت شما توانسته‌اید بخش عمده‌ای از کارخواست مشتری را انجام بدهید. در ادامه به یک سری از مسائل زیرساختی می‌پردازم که با اکتساب دانش آن می‌توانید که تحویل غنی تر به مشتری داشته باشید.برای امروز کافیه! کلی کار مشتری مونده سریعتر آماده گام‌های بعدی سفارش بشید.

داکر در عمل :: راه اندازی کانتینرهای تعاملی (ادامه پروژه پایش وب مشتری)

محسن نیک نژاد — Sat, 21 Sep 2019 01:50:22 +0430

برنامه‌هایی که تعامل بیشتری با کاربران را دارند، احساس تعاملی بودن بیشتری را منتقل می‌کنند. یک وایرایشگر متن تحت ترمینال می‌تواند مثال بسیار خوبی برای این امر باشد. ابزار خط فرمان داکر یک مثال کامل از یک برنامه ترمینال تعاملی است. این نوع برنامه‌ها ممکن است دریافت ورودی از کاربر و یا نمایش خروجی در ترمینال را داشته باشند. برای اجرای برنامه‌های تعاملی داخل کانتینرها نیازمند این هستید که بخشی از ورودی و خروجی‎های کانتینریتان را به ترمینال، از طریق داکر متصل کنید.با دستور زیر شروع به ایجاد کانتینرهای تعاملی می‌کنیم:docker run --interactive --tty --link web:web --name web_test busybox:lastest /bin/shدر فرمان بالا ما run را با دو گزینه interactive و tty استفاده کردیم که می‌توانستیم به جای آنها از (i-) و (t-) هم استفاده کنیم.گزینه interactive به داکر می‌گوید که جریان ورودی استاندارد(stdin) برای کانتینرها ظاهر شود حتی اگر ترمینالی وصل نشده باشد.گزینه tty به داکر می‌گوید که یک ترمینال مجازی برای کانتینر من اجرا کن.ترمینال مجازی به شما اجازه می‌دهد تا سیگنال‌ها را به کانتینر منتقل کنید.این‌ها دقیقاً همان چیزی است که شما از یک برنامه تعاملی خط فرمان می‌خواهید. شما هر زمان نیاز به برنامه‌ای مانند Shell داشتید از هر دو این‎ها همزمان می‌توانید استفاده کنید. هنگامی که شما یک کانتینر را شروع کردید و برنامه‌ای را در دل کانتینر به اجرا در آوردید، می‌توانید Shell درون کانتینر خودتان را به اجرا درآورید و با اجرای آن تمام برنامه‌های درون کانتینرتان را به اجرای کامل در بیاورید.در دستور زیر یک کانتینر را اجرا و آن را به ترمینال و به کانتینر ngnix متصل می‌کنیم، این دستور را اجرا کنید تا بتوانید صحت عملکرد کانتینرها را ببنید.wget -O - http://web:80/برنامه‌ای که ما از آن استفاده می‌کنیم برنامه wget است که به جهت ارسال درخواست http به وب سرور استفاده می‌شود(NGINX سرور شما در قالب کانتینر پیش‌تر و در پست قبلی اجرایی شده است) و پس از اجرای آن محتوای صفحه وب روی ترمینال استاندارد چاپ خواهد شد.درمیان متن‌های چاپ شده متنی مانند این خواهید دید “Welcome to NGINX!” اگر پیام گفته شده را مشاهده می‌کنید، همه چیز به درستی کار می‌کند و شما می‌توانید با تایپ فرمان exit از کانتینر خارج شوید. با این کار فعالیت ترمینال کانتینر خاتمه می‌باید و کانتینر متوقف می‌شود. شما می‌توانید یک کانتینر تعاملی ایجاد کنید ، یک فرآیند در داخل آن کانتینر شروع کنید و سپس آن را از ترمینال خود جدا کنید. شما این کار را می‌توانید با نگهداشتن دکمه کنترل ctrl و بعد دکمه P و سپس Q انجام دهید. از این کلید تنها زمانی می‌توانید استفاده کنید که از گزینه tty-- استفاده کرده باشید.تکمیل سفارش مشتریبرای به اتمام رساندن سفارش شما ما باید برنامه ناظر را ایجاد کنیم.این کانتینر یک عاملی است که وب سرور را پایش می‌کند و در زمانی که وب سرور متوقف شد به کانتینر پست الکترونیکی می‎گوید که یک پست‌الکترونیکی حاوی پیام اخطار برای مدیران از پیش تعیین شده ارسال کند. دستور زیر کانتینر ناظر را با استفاده از گزینه‌های خلاصه شده ایجاد می‌کند:docker run -it --name agent --link web:insideweb --link mailer:insidemailer dockerinaction/ch2_agentپس از اجرای فرمان بالا کانتینر ناظر اجرا شده و پس از بررسی هرباره در هر ثانیه پیام زیر را چاپ می‌کند:System up.حالا که دیدید کانتینر ناظر چگونه کار می‌کند، کانتینر را از ترمینال با روش گفته شده جدا کنید، یعنی ابتدا کلید کنترل ctrl و بعد P و سپس Q. بعد از انجام این کار قطعا به ترمینال سیستم خودتان باز خواهید گشت. اگر برنامه ناظر را متوقف کنید ، روند بررسی وب سرور بطور کامل متوقف خواهد شد.اگر چه با حالت detach و daemon قادر خواهید بود برنامه‌های کانتینری خود را روی سرورها تحت شبکه اجرا کنید ، اما استفاده تعاملی کانتینرها برای استفاده در رایانه شخصی و اجرا دستی بسیار موثر و کاربردی می‌باشد.خوب ما تا اینجا تمام درخواست‌های مشتری را انجام داده‌ایم ، اما قبل از اینکه ادعایی در مورد اتمام کار داشته باشیم باید آن را آزمایش کنیم.در پست بعدی به آن خواهیم پرداخت

داکر در عمل :: شروع و ایجاد یک کانتینر جدید(ادامه پروژه پایش وب مشتری)

محسن نیک نژاد — Fri, 20 Sep 2019 01:26:08 +0430

زمانی که ما از طریق داکر بخواهیم نرم‌افزاری را نصب کنیم در واقع آنچه به اصطلاح گفته می‌شود ما یک Image را نصب کرده ایم، روش‌های مختلفی برای نصب imageها وجود دارد و منابع مختلفی برای تهیهآنها پیش بینی شده است.بحث image ها را حتما در پست‌های آتی بطور کامل تحت پوشش قرار خواهم داد. در ادامه پست قبلی و نرم افزار کارخواست شده توسط مشتری:معماری درخواستی مشتریما قصد داریم یک image برای ngnix را از داکر هاب دانلود و نصب کنیم.داکر هاب (docker hub) یکی از مخازن اصلی تهیه imageها می‌باشدبا اجزای فرمان زیر ngnix را دانلود و نصب می‌کنیم:docker run --detach \ --name web nginx:latestزمانی که شما این دستور را اجرا می‎کنید ، داکر آخرین نسخه ngnix را از مخزن اصلی nginx در داکرهاب نصب و نرم‌افزار ngnix را اجرا می‌کند. بعد از نصب و اجرای ngnix ، یک خط از کارکترهای تصادفی در قالب یک رشته بروی ترمینال نوشته می‌شود مانند این:7cb5d2b9a7eab87f07182b5bf58936c9947890995b1b94f412912fa822a9ecb5این کاراکترها یک شناسه منحصر به فرد برای این کانتینر می‌باشد که فقط برای اجرای ngnix تولید شده است. هر زمان شما از دستور docker run برای ایجاد یک کانتینر جدید استفاده می‌کنید آن کانتینر شناسه‌ای شبیه به همین می‌گیرد. این یک روش معمول برای کاربران جهت گرفتن خروجی از یک کانتینر در دل یک متغییر و استفاده در دستورات دیگر است.بعد از نمایش شناسه منحصر به فرد شما خواهید دید که اتفاق دیگری رخ نخواهد داد. به دلیل استفاده از گزینه detach و شروع برنامه در پس‌زمینه شاهد این اتفاق هستیم.این عمل این را به ما می‌رساند که برنامه شروع شده به ترمینال الحاق نشده است.شاید در این لحظه به این فکر می‌کنید که این برنامه را مانند برنامه‎های مختلف درون رایانه خودتان فقط یک نسخه می‌توانید اجرا کنید، این تفکر اشتباه است و من به شما اجرا تعداد زیادی نسخه از یک نرم‌افزار را آموزش خواهم داد.استفاده از گزینه detach راهکار بسیار با کیفیتی برای اجرا برنامه‌ها در پس‌زمینه (Background) است.این نوع برنامه‎ها Daemon نامیده می‌شوند. یک Daemon به طور عمومی برنامه‌ای است که محیط اجرا که با برنامه‎های دیگر، انسانها و ساختارها تحت یک شبکه و یا ابزارهای و پروتکل‎ها ارتباط می‌گیرد.زمانی که می‌خواهید یک برنامه را در پس‌زمینه با داکر تحت یک Daemon اجرا کنید از سوئیچ detach-- یا d- استفاده کنید.برنامه دیگری که مشتری شما نیاز داشت برنامه پست‌الکترونیکی بود که منتظر می‎ماند تا یک ارتباط با آن برقرار شود و مشکل را در قالب یک پست الکترونیکی ارسال کند.با دنبال کردن دستور زیر علاوه بر نصب نرم‌افزار پست‌الکترونیکی با ساختار آن نیز آشنا شوید:docker run -d --name mailer dockerinaction/ch2_mailerبا راه اندازی این کانتینر دومین ساختار مورد نیاز مشتری ایجاد شده است. حالا تا اینجا ما دو سیستم از سه سیستم را راه‌اندازی کرده‌ایم. آخرین بخش ، راه اندازی کانتینر ناظر است که تعاملات سیستم درخواستی توسط آن انجام می‌شود.خوب فکر می‎کنم تا اینجا کافی باشه، من رو دنبال کنید :)

داکر در عمل :: کنترل کردن کانتینرها (انجام پروژه پایش وب)

محسن نیک نژاد — Wed, 18 Sep 2019 21:18:05 +0430

در آموزش، اکثر مثال‌هایی که از آنها بهره می‌گیریم بر مبنای نیازهای روز ساختارهای نرم‌افزاری طراحی شده‌اند و من سعی دارم چگونگی استفاده از آنها را در فعالیت‌های روزانه برای شما را شرح دهم. در مثال این بخش سعی داریم یک وب سرویس بنام NGNIX نصب کنیم. فرض کنید :یک مشتری به دفتر شما می‌آید و سفارش یک وب‌سایت جدید را می‌دهد و آنها می‌خواهند وب‌سایت خودشان را از نزدیک پایش (Monitor) کنند و این مشتری خاص می‌خواهد عملیات‌های خاض خودش را اجرا کند، آنها می‌خواهند زمانی که سرورشان از کار افتاد(Down شد) برای آنها ایمیلی ارسال شود، آنها همچنین اسم وب سرور معروفی بنام NGNIX را شنیده‌اند و می‌خواهند سایت آنها روی آن اجرا شود و با توجه به شنیده‌ها راجب داکر می‌خواهند روی آن این طرح را به اجرا در آورند و شما باید راجب استفاده از آنها تصمیم بگیریدشکل معماری برنامه ریزی شده برای پروژه مانند شکل زیر است:پروژه درخواست شده توسط مشتریاین مثال از سه کانتینر استفاده می‌کند. اول وب سرور NGNIX اجرا خواهد شد ، دومین ماشین ، کانتینر پست‌الکترونیکی می‌باشد که به عنوان دومین ماشین اجرا خواهد شد، هر دو ماشین به صورت جداگانه اجرا خواهند شد، بدون اینکه از طریق هیچ جریان ورودی یا خروجی به هم متصل باشند. در برنامه سوم که ما آن را ناظر می‌نامیم ما یک کانتینر تعاملی خواهیم داشت . هر دو ماشین پست‌الکترونیکی و ناظر دارای اسکریپت‌های کوچکی هستند که برای این مثال ایچاد شده است. در این قسمت نحوه انجام موارد زیر را فراخواهید گرفت:ایجاد کانتینرهای جداگانه و تعاملیلیست کانتینرهای روی سیستمنمایش لاگ‌های کانتینرهاتوقف و راه‌اندازی مجدد کانتینرهااضافه کردن یک ترمینال به یک کانتینرجدا کردن یک کانتینر متصلحالا با سرعت بریم سفارش مشتری رو روی پست‌های بعدی انجام بدهید. صفحه من رو دنبال کنید و بهم نظراتتون رو بگید:)

داکر در عمل :: گرفتن کمک از خط فرمان داکر

محسن نیک نژاد — Wed, 18 Sep 2019 00:48:47 +0430

اگر چه در ادامه دستورات مختلف داکر را کاملا آموزش می‌دهیم ، اما ما می‌خواهیم جهت درک فرامین داکر از خود داکر بهره‌گیری کنیم و از فرمانی که دقیقا شرح می‌دهد که چگونه از داکر درون سیستم رایانه خودتان استفاده کنید. حالا ترمینال خود را باز کنید و در خط فرمان دستور زیر را واردکنید#docker helpاجرای دستور بالا لیستی راجب دستورات پایه و کاربرد آنها ارائه می‌دهد.خروجی اجرای فرماناجرا فرمان فوق اطلاعات سطح بالایی به شما ارائه می‌دهد که در خیلی از موارد کافی به نظر نمی‌رسد، برای گرفتن اطلاعات با جزئیات بیشتر پس از دستور بالا ، فرمانی را که می‌خواهید پیرامون آن اطلاعات بیشتری داشته باشید را بیاورید مانند:#docker help cp #docker cp helpخروجی فرمانهر دو دستور بالا معادل یکدیگر می‌باشند، حالا با وارد کردن این دستور به شما اطلاعات با جزئیات بیشتری را ارائه می‌کند.

داکر در عمل :: چرخه اجرای کانتینرها در داکر

محسن نیک نژاد — Wed, 18 Sep 2019 00:27:27 +0430

در پست قبلی یک کانتینر در داکر اجرا کردیمdocker run dockerinaction/hello_wordوقتی این دستور را اجرا می کنید یک چرخه اجرا می شود که به آن می‌پردازیمچرخه اجرای فرمان در داکرپس از اجرا فرمان Hello World داکر از کانتینر خارج شده و خودکار متوقف می‌شود. این موضوع را درک کنید که حالت اجرا یک کانتینر یا مخزن به اجرا برنامه درون آن بستگی دارد.

داکر در عمل :: سلام دنیا Hello World!

محسن نیک نژاد — Tue, 17 Sep 2019 00:12:26 +0430

همه دوست دارن کار را با یک مثال شروع کنند که با توجه به سنت دیرینه‌ی ما مردان و زنان فناوری‌اطلاعات با یک "Hello World" شروع می‌کنیم. قبل از شروع باید داکر را طبق دستورالعمل‌هایی که در دو پست قبلی به آنها اشاره کردم نصب کنید، اگر آموزش‌ها برای شما کافی نبوده به لینک زیر بروید و نصب و راه اندازی خود را کامل کنید:https://docs.docker.com/installationکاربران OSX و Windows حتماً ابزار Docker ToolBox را نصب و راه اندازی کنند.هنگامی که داکر را نصب کردید یک اتصال فعال اینترنت داشته باشید.نکته: از آنجا که داکر برای کشور عزیزمان تحریم‌های ناجوانمردانه و بر خلاف قوانین نشر آزاد علم وضع کرده ، حتما از VPN استفاده کنید.به خط فرمان بروید و خط زیر را تایپ کنید:docker run dockerinaction/hello_worldنکته: داکر را با کاربر ریشه (root) در سیستم خودتان اجرا کنید، یعنی از فرمان sudo بهره‌گیری کنید. اگر این کار را انجام ندهید با خطاهای مجوز روبرو خواهید شد.شما می توانید یک گروه کاری برای داکر ایجاد کنید و به این گروه مجوز سوکت بدهید و با اضافه کردن کاربر به این گروه این الزام را از بین ببرید. پس از انجام این کار، داکر می‌تواند به کار خود به راحتی ادامه دهد.با انجام این کارها ابتدا image لازم دانلود شده ، کانتینر اجرا شده و پیام "Hello World" روی صفحه چاپ می‌شود.نکته: اگر دستور بالا را دوباره اجرا کنید ، فقط پیام "Hello World" روی صفحه چاپ می‌شود.تبریک شما اولین قدم در آموزش داکر را برداشتید.

داکر در عمل :: نصب داکر روی دبیان/ابونتو/مینت

محسن نیک نژاد — Mon, 16 Sep 2019 22:40:15 +0430

نصب داکر از مخازن لینوکسیسلام ، در ادامه آموزش داکر درعمل نصب و راه‌اندازی داکر از طریق مخازن رو فرا می‏‏‌گیریم. من برای این آموزش نصب (Docker CE (Community Edition را انجام خواهم داد،این نسخه کاملاً متن باز و انعطاف‌پذیر می باشد و برای تیم های توسعه و کوچک بهترین گزینه محسوب می‌شود.برای شروع کار با داکر ، Docker CE بهترین گزینه است ، حتما وقت بگذارید و با دنبال کردن آموزش آن را فرا بگیرید.در ابتدا توصیه می‌کنم قبل از هر کاری بررسی کنید در محیط لینوکس خود هیچگونه نسخه از داکر از قبل نصب نشده باشد. برای این کار فرمان زیر را وارد می‌کنیم:sudo apt remove docker docker-engine docker.io containerd runcبررسی و حذف نسخه‌های مختلف داکر در لینوکسپیش از هر کاری apt را بروز کنید sudo apt updateبه طور پیش‌فرض ، apt از پروتکل HTTPS استفاده نمی‌کند. بسته‌های زیر را نصب کنید که به APT امکان استفاده از مخازن HTTPS را می‌دهد.sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-commonبسته‏‌های پیش‌نیاز جهت استفاده از مخازن HTTPSبرای فعال کردن مخازن Docker ، کلید رسمی Docker دارای اهمیت است. روش اضافه کردن کلید رسمی GPG Docker به لیست مخازن APT:curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -افزودن کلید رسمی داکر جهت استفاده از مخازن اصلی و استانداردحتی پس از نمایش تائیدیه ، جهت اطمینان از افزوده شدن صحیح کلید دستور زیر را در خط فرمان وارد کنید:sudo apt-key fingerprint 0EBFCD88بررسی صحت افزوده شدن کلیددر مورد داکر ، سه مخزن مختلف وجود دارد - مخزن "پایدار" (برای همه توصیه می شود) ، "شبانه" یا "تست". بگذارید مخزن "پایدار" را پیکربندی کنیم.sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"افزودن مخزن پایدارنکته:اگر هر کدام از مخازن تست (test) یا شبانه(nightly) را برای نصب انتخاب کردید. کافی است با کلمه stable در فرمان بالا جابه‌جا کنید.بعد از اضافه شدن مخزن داکر به لیست مخازن APT حتماً است تا دوباره آن را بروزرسانی کنید تا لیست آدرس‌های نصب داکر درون سیستم شما بارگذاری شود.sudo apt updateقرار گرفتن آدرس های نصبی داکر درون سیستم و مخزن aptدر نهایت هم دستور زیر را برای نصب داکر وارد می‌کنیم:sudo apt install docker-ce docker-ce-cli containerd.ioنصب داکرنصب کامل شد و حالا دیگه می‌توانید از داکر استفاده کنید :)نکات اضافه:اگر دنبال نصب نسخه خاصی از داکر و افزونه‌های آن هستید به روش زیر عمل کنیدابتدا دستور زیر را وارد می‌کنیم تا نسخه در دسترس را به ما نمایش دهدapt-cache madison docker-ceلیست نسخه‌های قابل نصب داکرحالا نسخه‌ای را که می‌خواهید نصب کنید در قالب زیر وارد نماییدsudo apt-get install docker-ce=<نسخه مورد نظر> docker-ce-cli=<نسخه مورد نظر> containerd.ioخوب آموزشمون در این بخش به پایان می‌رسد اگر نظر یا نکته‌ای دارید با من در میان بگذارید.

داکر در عمل :: نصب داکر روی ویندوز

محسن نیک نژاد — Fri, 13 Sep 2019 22:47:13 +0430

داکر برای مبنای ساختارهای موجود در کرنل لینوکس توسعه داده شده، داکر را روی خانواده سیستم عامل های مایکروسافت فقط می توان روی خانواده ویندوز 10 که از ساختار کرنل های متن باز بهره می‌برد استفاده کرد. قبلا برای نصب داکر روی ویندوز نیاز بود که حتما از یک لینوکس مجازی استفاده کرد که برای آن از روش‌هایی همانند Docker Machine و یا استفاده از Docker ToolBox توصیه می‌شد. به صورت کلی یعنی یک سیستم‌عامل لینوکس به صورت مجازی روی سامانهعامل ویندوز نصب شود که از طریق آن بتوان داکر را نصب و از امکانات آن استفاده کرد. اما خوب مایکروسافت با سازگاری که با کرنل متن باز لینوکسی کرد ساختار استفاده از داکر را برای ما بطور مستقیم فراهم آورده است.نکته: نصب به صورت پکیج بر روی ویندوز، تنها در ویندوز‌های زیر ممکن خواهد بود:Windows 10 ProWindows 10 Enterprise Version 14393Windows Server 2016 RTMنصب به صورت پکیج بر روی ویندوز:در ابتدا لازم است تا پکیج مورد نظر را دانلود کنید. همانطور که در جریان هستید داکر کلا روی ایران لینک‌های خود را مسدود کرده است. برای همین شما برای دانلود با خطای ۴۰۳ مواجه خواهید شد. برای رفع این موضوع پیشنهاد می‌کنم از فیلتر شکن استفاده کنید که بهترین و عقلانی ترین راه ممکن است. ابتدا Control Panel را باز کنید.بر روی Network and Sharing Center کلیک کنید.در قسمت گوشه سمت چپ صفحه بر روی Change adapter settings کلیک کنید.سپس بر روی کارت شبکه خود راست کلیک کرده و گزینه‌ی Properties را انتخاب کنید.بعد از آن (Internet Protocol Version 4 (TCP/IPv4 را از لیست باز شده انتخاب کرده و بر روی گزینه‌ی Properties کلیک کنید.بر روی گزینه‌ی Use the following DNS server addresses کلیک کنید و این IP را در خانه‌های آن وارد نمایید. 94.232.174.194بعد از وارد کردن IP جدید بر روی گزینه‌ی OK کلیک کرده و سپس Close را انتخاب نمایید.انتظار می‌رود بعد از این مراحل و تغییر DNS Server بتوانید از سایت داکر پکیج مورد نظر را دانلود کنید.از اینجا پکیج را دانلود کنید. بعد از دانلود بر روی Docker for Windows Installer.exe کلیک کرده تا نصب شروع شود. مراحل نصب که بسیار ساده است را طی کنید تا تمام شود. نیاز به اجازه برای استفاده شبکه و استفاده از Hyper-V خواهد داشت. در صورتی که بر روی ویندوز شما فعال نباشد آن را فعال خواهد کرد. در طول این مسیر ممکن است چند بار سیستم‌عامل شما ریستارت شود تا این مراحل کامل شود.بعد از اتمام نصب شما در ویندوز خود نرم‌افزاری همانند تصویر زیر خواهید داشت.داکر نصب شده در ویندوز 10در قسمت Status Bar ویندوز نیز لوگوی داکر را خواهید دید که بعد از استارت نرم‌افزار زمان نیاز دارد تا بتواند کل داکر را راه‌اندازی نماید. تا زمانی که این تصوری کامل نشود هنوز سرویس داکر به صورت کامل استارت نشده است. بعد از تکمیل همانند تصویر زیر خواهد شد.لوگوی داکر در Status Barبعد از راه‌اندازی کامل داکر تصویر زیر به شما نمایش داده می‌شود که مشخص می‌کند داکر به صورت کامل بر روی ویندوز شما آماده‌ی کار بود و با استفاده از cmd ویندوز می‌توانید از دستورها داکر استفاده کنید.تصویر نهایی که نشان می‌دهد داکر به صورت کامل بر روی ویندوز راه‌اندازی شده است.بعد از این تصویر شما می‌توانید به صورت کامل از دستورها Docker Client در cmd ویندوز استفاده کنید.منبع

داکر در عمل :: کی و کجا از داکر استفاده کنیم

محسن نیک نژاد — Fri, 13 Sep 2019 22:31:23 +0430

داکر را می‌توانید روی اغلب کامپیوترها چه در خانه و چه در محیط کاری استفاده کنید. عملا این کار در چه جایی انجام شود بهتر است؟داکر تقریبا در هر نقطه ای قابل اجرا است، اما این بدان معنی نیست که دقیقا برای کار شما مناسب باشد. به عنوان مثال داکر در حال حاضر روی کرنل‌های لینوکس قابل اجرا می‌باشد و شما نمی‌توانید آن را روی ساختارهای بومی مایکروسافت و شرکت اپل اجرا کنید.داکر همه جا هست اما با قوائد خاص خودشدر خانواده مایکروسافت ویندوز 10 که از کرنل لینوکس بهره می برد توانایی اجرای داکر را دارد بنابراین شما می‌توانید بنا به نیاز و محدود سازی نرم افزارهای دستکتاپی و سروری سازگار با لینوکس را به راحتی درون کانتینرها اجرا کنید.برنامه‌های سروری مانند سرورهای وب، سرورهای پستی، بانکهای اطلاعاتی، پروکسی‌ها و موارد مشابه آن را می توان نام برد که در این ساختارها قابل استفاده است از طرفی نرم افزارهای دسکتاپی مانند مرورگرهای وب، پردازشگرهای کلمه، سرویس گیرنده ایمیل یا سایر ابزارها نیز از ویژگی‌های خوبی برخوردار هستند قابل بهره‌برداری می‌باشند. این روش جداسازی ساختارهای نرم افزاری، کاربران را کمک می‌کند تا از رایانه خود محافظت کنند.فراتر از فواید اضافه شده در دفاع، استفاده از داکر برای کارهای روزانه به تمیز نگه داشتن رایانه کمک می‌کند.پاک نگه داشتن رایانه کمک می‌کند تا از ورود به منابع مشترک پیشگیری شده و سهولت در نصب و حذف نرم افزارها داشته باشیم. همین حذف و نصب ساده به شرکت‌های نرم افزاری کمک می‌کند تا کمتر به فکر پشتیبانی از نرم‌افزار باشند و دغدغه اصلی خود را به تولید منعطف کنند.مهمترین چیزی که باید به یاد داشته باشیم این است که کانتینرها در کجاها نامناسب هستند. کانتینرها به برنامه های امنیتی که نیاز به دسترسی کامل به منابع سیستم دارند هیچ کمکی نمی‌کند. البته انجام این کار قابل است اما بسیار پیچیده و پر دردسر. پس استفاده از ساختارهای کانتینری در مواقع نیاز به دسترسی کامل و بدون محدودیت به منابع سیستمی اصلا توصیه نمی‌شود.نکته بعدی این است که کانتینرها یک راهکار جامع برای امنیت نیست، اما از آنها می توان برای پیشگیری انواع بسیاری از حملات استفاده کرد. بخاطر داشته باشید که به هیچ وجه از منابع نرم افزاری نا مطمئن استفاده نکنید. این مورد را بویژه در مواقعی که نیاز به دسترسی های مدیریتی وجود دارد حتماً رعایت کنید.در ساختارهای سرویس دهی به مشتری ، کانتینرهای مشتری های مجموعه را کورکورانه در کنار هم قرارندهید.

داکر در عمل :: چرا داکر مهم است؟

محسن نیک نژاد — Wed, 11 Sep 2019 01:30:13 +0430

داکر برای شما آنچه را که چکیده (abstraction) نامیده می‌شود فراهم می‌آورد. چکیده سازی یا abstraction به شما این امکان را می‌دهد که مسائل پیچیده را به سادگی انجام دهید. بنابراین، در مورد Docker، به جای توجه به همه پیچیدگی ها و مشخصات مربوط به نصب یک برنامه، تمام چیزی که ما نیاز داریم این است که چه نرم افزاری را می‌خواستیم نصب کنیم!مانند جرثقیل که هرگونه کانتینری را برای حمل و نقل یک شکل روی کشتی قرار می‌دهد، روند نصب هرگونه نرم‌افزار با Docker با سایر نرم افزارها یکسان است.نصب در داکر به راحتی انتزاع کردن انتقال کانتینرها با کشتی استشکل و اندازه کانتینرها ممکن است متفاوت باشد اما روش عملکرد جرثقیل با آنها همواره یکسان است و تمام ابزارهای حمل و نقل کانتینرها قابلیت استفاده مجدد را دارند.در مورد حذف برنامه ها نیز همین نکته صادق است، وقتی می‌خواهیم نرم افزاری را حذف کنیم به داکر می‌گوییم کدام نرم‌افزار را می‌خواهیم حذف کنیم. هیچ داده ای به خاطر مدیریت و حسابرسی دقیق نیز باقی نمی‌ماند. بر خلاف نرم افزارهایی که روی رایانه خودتان نصب می‌کنید، پس از حذف با داکر کامیپوتر به قدری تمیز خواهد بود که قبل از نصب بود.داکر و ابزارهای خلاصه ساز آن اصول مدیریت و استفاده از کانتینرها را برا شما فراهم می آورد. داکر مهم است چون به توسط آن کانتینرها در دسترس همه هستند و استفاده از آن موجب صرفه جویی در وقت ، پول و انرژی می شوددومین دلیلی که برای مهم بودن داکر داریم، فشار جامعه نرم افزاری جهت همگام سازی تکنولوژی های خود با داکر و کانتینر است. این فشارها به حدی قوی است که شرکت هایی مانند آمازون ، مایکروسافت و گوگل همه با هم همکاری کرده اند تا در این امر سهیم باشند و دقیقا از این تکنولوژی در ساختارهای ابری خود بهره ببرند.سومین دلیل این است که مانند ساختارهای آپ استور و فروشگاه های نرم افزار موبایل داکر برای شما ساختارهای ویژه به جهت نصب ، حذف محاسبات فراهم آورده است. البته داکر چندسکویی می باشد و این ساختار پویا بر خلاف تلفن های همراه در اغلب پلت فرم ها رایج قابل اجرا می باشد.چهارم ، ما سرانجام در حال شروع به دیدن جداسازی بهتر برخی از ویژگی های پیشرفته تر سیستم عامل ها هستیم. ممکن است این نکته ساده به نظر برسد اما افراد کمی ایزوله سازی های امنیتی را روی سیستم عامل خود انجام می دهند البته این شرم آور است که کار سخت آنها اینقدر طول کشیده است که شاهد پذیرش دسته جمعی هستیم. با این وجود که فناوری کانتینرها دو دهه است که وجود دارد.حالا این بسیار عالی است که داکر این قدرت را به ما می دهد تا از همه این ویژگی ها به راحتی استفاده کنیم.

داکر در عمل :: حفاظت از رایانه شما

محسن نیک نژاد — Wed, 11 Sep 2019 00:55:24 +0430

قبل از اینکه از منظر کار با خود نرم افزار داکر و مزایای کار با آن صحبت کنم به مزایای مخازن (کانتینرها) از دیدگاه خارجی اشاره کردم اما داکر و مخازن ما رو از نرم افزارهایی که درون خودشان اجرا می کنند محافظت می کنند.انواع و اقسام روش هایی وجود دارد که یک برنامه ممکن است با استفاده از آنها باعث سوء رفتار شود یا خطرات امنیتی برای ما ایجاد کند:یک برنامه می تواند بطور کاملا اختصاصی توسط یک مهاجم نوشته شده باشد.توسعه دهندگان خوب می توانند برنامه هایی با اشکالات مضر بنویسند.یک برنامه میتواند کاملا تصادفی و بر مبنای مدیریت ضعیف ورودی ها با یک برنامه مهاجم ادغام شود.از هر راهی که این مسیرها رو قطع کنید ، تا زمانی که نرم افزارها مستقیم روی سیستم شما اجرا می شوند شما ریسک امنیتی را به جان خریده اید.مانند سلول ها در زندان های فیزیکی ، برنامه های درون کانتینرها فقط به چیزهایی که درون آن است به خوبی دسترسی دارد.البته استثناء هایی در زمانی که کانتینر توسط کاربر ایجاد شود وجود دارد.کانتینرها یا همون مخارن برنامه های درون خودشان را محدود به اجرای خود برنامه و وابستگی هایش می کند و برنامه در دسترسی به داده ها ، منابع سیستم و خیلی جزئیات رایانه میزبان محدود شده است. شکل زیر مدل محدود شده توسط کانتینرها و بدون آن را به خوبی نمایش می دهد.سمت چب برنامه مخرب با دسترسی مستقیم به تمامی منابع ، سمت راست برنامه مخرب در کانتینر و محدود شدهاین مدل اجرا شده در داکر و کانتینرها این پیام را برای کسب و کار شما دارد که دامنه فعالیت هر برنامه و معضلات امنیتی مرتبت با آن فقط محدود به آن کانتینر است.به نظر من ساختن مخازن (کانتینرها) یک استراتژی دفاع در عمق است و امنیت سازمانی شما را ارتقاء می دهد.تو این ایام دعا برای من فراموش نشود. منتظر نظرات شما هستم

داکر در عمل:: بهبود قابلیت انتقال

محسن نیک نژاد — Sun, 08 Sep 2019 23:24:14 +0430

یکی دیگر از مسائلی که برنامه با آن درگیر هستند مسئله ی وابستگی آنها به کتابخانه یک سیستم عامل خاص می باشد. مشکل قابلیت انتقال نرم افزار بین سیستم عامل های مختلف مشکل اساسی کاربران نرم افزار در این روزها می باشد. البته امکان سازگاری بین برخی نرم افزارهای سیستم های مختلف مانند لینوکس و مک os وجود دارد اما همین کار با ساختارهای ماکروسافت بسیار مشکل و پیچیده می باشد. اگر بدون داکر بخواهیم به این مسئله پاسخ دهیم بهترین روش تولید نسخه های مستقل هر سیستم عامل می باشد. یک نکته بسیار مهم در این بخش وجود دارد که هزینه نگهداشت نرم افزار به شدت ارتقاء می یابد. برای کاربران معمولی هم همواره داشتن چندین نرم افزار قدرتمند روی سیستم چالش بزرگی بوده است.در حال حاضر با داکر, یک ساختار مجازی ارائه شده به راحتی روی تمامی سیستم عامل ها اجرا می شود. این همگرایی در مدل داکر به این معنی می باشد که شما در مخازن یکبار نرم افزارها و وابستگی های آنها را قرار می دهید و بارها در ساختارهای سیستم عاملی مختلف از آن استفاده می کنید.شاید در همین لحظه با خودتان فکر کنید "من که همین کارها رو با ماشین مجازی انجام میدادم دیگه چه نیازی به داکر دارم" در پاسخ به شما می توان گفت که این فناوری ها مکمل هم هستد و شما در ساختارهای کانتینرها که من به آنها مخازن می گویم از ساختار مورد نیاز سیستم عامل میهمان جدا شده و ساختاری پویا و کوچک ارائه می دهد که به راحتی این ساختارهای مجازی کوچک را می توانید گسترش داده و مقیاس پذیر کنید.قابلیت های داکر از جمله قابلیت انتقال آن, اول فرصت های بسیار زیادی در مقابل کاربران نرم افزار قرار می دهد, آن هم باز شدن قفل استفاده از تمام نرم افزارهای موجود در جهان نرم افزارها می باشد. دوم اینکه همان نرم افزار را به مشابه سایر نرم افزارها به اجرا در می آورد.این بدان معنی است که دسکتاپ ، محیط توسعه ، سرور و ابر شرکت شما می توانند همه برنامه های مشابه ای را اجرا کنند.اجرا در محیط سازگار خیلی مهم است و این کار منحنی یادگیری فناوری های جدید را به حداقل می رساند. علاوه بر اینها این فناوری کمک می کند تا توسعه دهندگان نرم افزار مثل من درک بهتری از اجرای برنامه در محیط عملیاتی داشته باشند و به اصطلاح در موقع اجرا کمتر سوپرایز شوند. سوم اینکه واحدهای پشتیبانی و نگهداری نرم افزار میتوانند تمام تمرکز خودشان را روی برنامه خودشان و وابستگی های نرم افزاریشان در یک پلت فرم مشخص قرار دهند. اینکار رو میتوانیم یک پس انداز زمانی بزرگ بر آنها و یک برد برای مشتریان قلمداد کنیم.بدون داکر و ماشین های مجازی قابلیت انتقال محدود به اجرای برنامه های فردی روی بعضی بسترهای معمول آنها میشود مثلا میتوانید یک برنامه به زبان جاوا بنویسید و با استفاده اژ مجازی ساز جاواش JVM برنامه خودتان را روی پلت فرم های مختلف ایجاد کنید.البته این رویکرد در بسیاری موارد راهکاری قابل قبول است و توسط بسیاری از شرکت ها مورد استفاده قرار می گیرد اما نکته ی مهمی در این بین است آن برای نوشتن وابستگی نرم افزاری که تا بحال نوشته نشده اند زمان زیادی باید صرف شود.داکر با فراهم آوردن قابلیت انتقال جدا از اینکه با چه زبانی نوشته شده اند یا در چه سیستم عاملی کار می کنند و یا به چه محیطی برای اجرا نیاز دارند، قابلیت بهره برداری از نرم افزارها را به شدت ارتقا می دهد.

داکر در عمل :: سازماندهی کردن

محسن نیک نژاد — Sat, 07 Sep 2019 11:37:36 +0430

بدون داکر, کامپیوترها شبیه کشوهای بهم ریخته دراور به نظر می رسد.برخی از برنامه ها برای موارد مشترکی مانند صدا ، شبکه ، گرافیک و غیره به کتابخانه های خاص در سیستم وابستگی دارند. برخی دیگر متناسب با زبانی که نوشته شده اند به کتابخانه های آن زبان وابسته هستند. بعضی از برنامه ها هم به برنامه های دیگر وابستگی دارند مثلا یک برنامه جاوا به Java Virtual Machine وابستگی دارد و یا یک برنامه وب به بانک اطلاعاتی وابستگی دارد. در موارد نادر هم برنامه هایی برای اجرا به یک فایل یا شبکه وابستگی دارند.شکل ۱ - وابستگی میان چند برنامه نمونهامروز بدون داکر برنامه ها در سراسر فایل سیستم گسترش پیدا کرده و تعاملات بسیار بهم ریخته ایجاد می کند که می تواند دردسر ساز شود. شکل بالا همین مسئله را نمایش می دهد.داکر, با سازماندهی و ایزوله سازی همه چیز را درون مخازن (Containers) و تصاویر(images ) نگهداری می کند.شکل ۲ نگهداری و اجرا برنامه ها را درون مخازنContainers را نشان می دهد.شکل ۲ :‌اجرا برنامه ها درون مخازن همراه با کپی از وابستگی آنهابا شکسته شدن پیوندهای پیچیده سیستم فایلی درون داکر انجام وظایف کاملا سهل الوصل تر می شود.خوب فکر می کنم برای این بخش کافی باشهُ منتظر نظراتتون هستم.