آیا میدانستید که Facebook در حال حاضر بیشتر از 400 میلیون کاربر فعال دارد که حدود 200 میلیون از این کاربران هر روز از این سرویس استفاده میکنند؟ آماری که این سرویس داده به این صورت است که تا سال 2010، کاربرانش در هر روز حدود 16 بیلیون دقیقه از وقت خودشان را به استفاده از این سرویس اختصاص دادهاند. در هر هفته کاربران این سرویس حدود 6 بیلیون مطلب را که شامل عکس و متن بوده را به اشتراک گذاشتهاند. هر ماه بیشتر از 3 بیلیون عکس توسط این سرویس Upload شدهاست. کاربرانش روزانه بیشتر از 1 بیلیون عکس را توسط این سرویس مشاهده کردهاند. این سرویس در ثانیه حدود 50 میلیون عملیات را انجام میدهد!
آیا میدانستید که سرویس Twitter در حال حاضر 350 میلیون کاربر فعال دارد که حدود 100 میلیون از این کاربران روزانه از این سرویس استفاده میکنند و هر روز کاربران این سرویس 500 میلیون توییت را ارسال میکنند. این سرویس در فینال جام جهانی حدود 618,725 توییت را در یک دقیقه دریافت کردهاست.
و یا سرویس Telegram حدود 100 میلیون کاربر فعال دارد که بصورت متوسط در هر روز 220 هزار کاربر جدید در آن ثبت نام میکنند. کاربران این سرویس روزانه 15 بیلیون پیام را ارسال میکنند و 700 میلیون عکس را به اشتراک میگذارند.
چه سروری به تنهایی میتواند این آمار و ارقام را پوشش دهد؟ هزینه خرید و نگهداری آن چقدر است؟ چقدر باید هزینه کنیم تا این سرور از دسترس خارج نشود؟ یک سرور به تنهایی چه راهکاری را میتواند ارائه دهد که هیچوقت از دسترس خارج نشود؟
بهتر است بدانید که سرویس Facebook روی بیش از 60,000 سرور ارائه میشود! چه سروری به تنهایی میتواند کارآیی 60,000 سرور را داشته باشد؟
چه نوع پایگاه داده ای که روی یک سرور سرویس ارائه میدهد، قادر است روزانه به بیشتر از 1 تریلیون درخواست، پاسخ دهد؟ اصلا چه سروری به تنهایی قادر است این حجم داده را که هر روز رو به افزایش است، نگهداری کند؟
بهتر است بدانید پایگاه داده سرویسهای شرکت Apple، روی بیش از 75,000 Node قرار دارند که روزانه حدود 10 پتابایت داده ذخیره میکنند. یا Netflix که از 2,500 Node استفاده میکند و روزانه 420 ترابایت داده را در قالب 1 تریلیون درخواست دریافت میکند یا Easou که پایگاه داده آن روی 270 Node قرار دارد و روزانه 300 ترابایت داده را در قالب 800 میلیون درخواست دریافت میکند! اینها اعداد و ارقامی نیستند که ما بتوانیم با SqlServerی که روی یک سرور قرار دارد، پوشش دهیم.
چه تعداد سرویس را در کشورمان میشناسید که در زمان بالا رفتن تعداد درخواست از دسترس خارج میشوند؟ چه تعداد سرویس را میشناسید که تنها راهکاری را که میتوان در این زمان برای آنها ارائه داد، ارتقاء سخت افزار آنهاست؟ پس از مدتی با بالا رفتن تعداد کاربران، دوباره سخت افزار را ارتقاء میدهیم. تا کجا باید این کار را تکرار کنیم؟ چقدر هزینه کنیم برای سخت افزاری که ممکن است به هر دلیلی در هر لحظه از دسترس خارج شود؟ آیا با توجه به آمار تعداد کاربران، تعداد درخواست و حجم دادهی سرویسهایی که میشناسید و قابل مقایسه با آمار ذکر شده است، باز هم از دسترس خارج میشوند؟
در سری مقالات Distributed systems in .NET من سعی میکنم شما را با خصوصیات و اصطلاحات موجود در سیستمهای توزیع شده آشنا کنم و ابزارهایی را که در NET. برای پیاده سازی این نوع سیستمها وجود دارد، به شما معرفی کنم و با هم ببینیم که این نوع سیستمها چه راهکاری را برای رفع نیازمندیهای ما ارائه میدهند.
نمونهای از طراحی یک سیستم توزیع شده
Owin چیست ؟ قسمت اول
مروری بر Claim
Relying party application
هر برنامه سمت client که از Claim پشتیبانی کند
مزایای Claim
- جدا سازی برنامه از جزییات شناسایی
- انعطاف پذیری در احراز هویت
- Single sign-on
- عدم نیاز به VPN
- متحد کردن مجموعه با دیگر شرکت ها
- متحد کردن مجموعه با سرویسهای غیر از AD
عناصر Claim
Claim شامل عناصر زیر میباشد :
- Token
- Claim
- Provider/Issuer
- Sharepoint STS
- ADFS
- ACS
- OID
- ,و غیره
یک اینترفیس را به اسم ICustomService ایجاد کردم که یک Prop به اسم InjectType دارد و مشخص میکند به چه صورتی این سرویس به ServiceCollection تزریق شود. از طرفی با استفاده از Order، الویت اضافه شدن سرویس به ServiceCollection را مشخص میکنیم و در نهایت با ImplementationType مشخص میکنیم سرویسی که اضافه شده، باید به یک اینترفیس Map شود یا خیر؟ اما مهمتر از اینکه ویژگیهای تزریق وابستگی مشخص شود، مشخص میکند چه سرویسهایی توسط ما اضافه شدهاند و از سرویسهای nop تفکیک میشوند.
namespace Nop.Services { public interface ICustomService { protected InjectType Inject { get; } protected int Order { get; } protected ImplementationType implementationType { get; } } public enum ImplementationType { WithInterface = 0, WithoutInterface = 1 } public enum InjectType { Scopped=0, Transit=1, SingleTon=2 } }
قانون اول
برای هر سرویسی که ایجاد میکنیم و میخواهیم به DI معرفی کنیم، آن سرویس باید ICustomService را پیاده سازی کرده باشد؛ دقیقا به خاطر دو دلیلی که در بالا به آنها اشاره شد.
قانون دوم
هر کلاسی که Interface مرتبط به سرویسها را پیاده سازی میکند، باید prop InjectType را در سازندهی خودش مقدار دهی کند. بدین شکل متوجه میشویم از چه طریقی باید تزریق انجام شود. تا اینجا یک چارچوب را مشخص کردیم تا سرویسها را بتوانیم تشخیص دهیم\ اما هنوز کار اصلی باقی ماندهاست. برای نمونه میتوان کد زیر را در نظر گرفت :
namespace Nop.Services { public interface IMyCustomService: ICustomService { int ok(); } }
namespace Nop.Services { public class MyCustomService : IMyCustomService { public InjectType Inject { get; } public int Order { get; } public ImplementationType implementationType { get; } public MyCustomService() { implementationType = ImplementationType.WithInterface; Inject = InjectType.Scopped; Order = 1; } public int ok() { return 10; } } }
تعیین نقطه شروع
کد زیر در واقع نقطهی اتصال سرویسهای نوشته شده و اتمام کار تزریق وابستگی است. با توجه به پیاده سازیهای انجام شدهی توسط سرویسها میتوان با Reflection سرویسهای نوشته شده را تشخیص داد که در نهایت با ویژگیهایی که در سرویسها پیاده سازی شده موجود است، به ServiceCollection اضافه میشوند.
namespace Nop.Web.Framework.Infrastructure { public class CustomDependencyInjection : NopStartup { private static bool IsSubInterface(Type t1, Type t2) { if (!t2.IsAssignableFrom(t1)) return false; if (t1.BaseType == null) return true; return !t2.IsAssignableFrom(t1.BaseType); } public override void ConfigureServices(IServiceCollection services, IConfiguration configuration) { //-------------Get All Services------------- var asm = AppDomain.CurrentDomain .GetAssemblies() .Single(x => x.FullName.Contains("Nop.Services")); //-------------find Services that inheriance of ICustomService------------- var types = asm.DefinedTypes.Where(x => IsSubInterface(x, typeof(ICustomService))); //-----------Get All Custom Service Classess------- var allRelatedClassServices = types .Where(x => x.IsClass) .OrderBy(x=>(Int32)x.GetProperty("Order") .GetValue(Activator.CreateInstance(x), null)); //-----------Get All Custom Service Interfaces------- var allRelatedInterfaceServices = types.Where(x => x.IsInterface); //-----------Matche Class Services To Related Interface Services------- TypeInfo interfaceService=null; foreach (var classService in allRelatedClassServices) { //-----------detect Implementation Type for service----------- var implementationValue = (ImplementationType)classService.GetProperty("implementationType") .GetValue(Activator.CreateInstance(classService), null); //-----------detect inject type for service----------- var InjectValue = (InjectType)classService.GetProperty("Inject") .GetValue(Activator.CreateInstance(classService), null); //-----------get related interface for service class----------- if (implementationValue == ImplementationType.WithInterface) interfaceService = allRelatedInterfaceServices.Single(x => x.Name == $"I{classService.Name}"); //----------finally Add Custom Service To Service Collection----------- switch (InjectValue) { case InjectType.Scopped: if(interfaceService!=null) services.AddScoped(interfaceService, classService); else services.AddScoped(classService); break; case InjectType.Transit: if (interfaceService != null) services.AddTransient(interfaceService, classService); else services.AddTransient(classService); break; case InjectType.SingleTon: if (interfaceService != null) services.AddSingleton(interfaceService, classService); else services.AddSingleton(classService); break; default: break; } interfaceService = null; } } } }
لینک گیتهاب
دانت فریم ورک با بهرهگیری از این تکنولوژیها، امکاناتی را برای ایجاد HTTP سرویسها، به ما میدهد و قبل از بکارگیری لازم است انتخاب کنیم که از کدام تکنولوژی باید استفاده کنیم.
Web Service
1. پایهی آن براساس SOAP است و دادهها را در قالب XML به ما میدهد.
2. فقط از HTTP پروتکل پشتیبانی میکند.
3. متن باز نیست اما میتوان از آن در هر کلاینتی که از XML پشتیبانی میکند، استفاده کرد.
4. فقط بر روی IIS میتوان آنرا هاست کرد.
WCF
1. پایهی پیش فرض آن براساس SOAP است و دادهها را در قالب XML به ما میدهد.
2. تکامل یافتهی وب سرویسها است (ASMX) و از پروتکلهای مختلفی همچون TCP, HTTP, HTTPS, Named Pipes, MSMQ پشتیبانی میکند.
3. مشکل اصلی WCF در بد قلقی و گسترده بودن تنظیمات آن میباشد.
4. متن باز نیست، اما میتوان از آن در هر کلاینتی که از XML پشتیبانی میکند، استفاده کرد.
5. بر روی IIS یا برنامهها و یا ویندوز سرویسها، میتوان آنرا هاست کرد.
WCF REST
1. برای استفاده از WCF و WCF REST باید حتما webHttpBindings را فعال کرده باشید.
2. از دستور العملهای HTTP Get و HTTP POST با استفاده از ترکیب خصیصههای [WebGet] و [WebInvoke] ، پشتیبانی میکند.
3. برای فعال کردن سایر دستور العملهای HTTP باید تنظیماتی را در IIS انجام دهید، تا درخواستهایی که بر اساس دستورالعملهای ویژهی در فایل svc. میباشند را قبول کند.
4. ارسال دیتا به آن از طریق پارامتر، با استفاده از WebGet احتیاج به تنظیماتی دارد و یا UriTemplate باید مشخص شود.
5. از XML, JSON and ATOM پشتیبانی میکند.
Web API
1. یک فریم ورک جدید برای ساختن HTTP سرویس، یک راه ساده و آسان.
2. متن باز است و یک راه ایده آل برای ساخت REST-ful سرویسها بر روی دات نت فریم ورک.
3. برخلاف WCF Rest، سرویسهای آن از ویژگیهای کامل HTTP مانند ( URIs, request/response headers, caching, versioning various content formats) پشتیبانی میکنند.
4. همچنین از ویژگیهای کامل MVC از قبیل routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing بهسادگی و قوی پشتیبانی میکند.
5. بر روی IIS و یا برنامهها، میتوان آنرا هاست کرد.
6. یک معماری سبک و مناسب برای دستگاههایی که پهنای باند محدودی دارند، مانند گوشیهای هوشمند.
7. پاسخها بوسیله Web API’s MediaTypeFormatter به صورت JSON, XML فرمت میشوند؛ و یا هر فرمتی را که شما میخواهید، بهعنوان MediaTypeFormatter اضافه کنید .
انتخاب بین WCF یا WEB API
1.انتخاب WCF زمانی مناسب است که شما میخواهید یک سرویس را ایجاد کنید که باید از سناریوهای مختلفی از قبیل پیغامهای یکطرفه و صف پیغامها و ارتباطات دو طرفه پشتیبانی کند و یا میخواهید یک سرویس را ایجاد کنید که از کانالهای انتقال سریع استفاده کند؛ از قبیل TCP و Named Pipes و یا شاید گاهی UDP در WCF 4.5 و همچنین میخواهید از HTTP پشتیبانی کند؛ وقتی که همهی کانالهای دیگر انتقال در دسترس نیستند.
2. انتخاب Web API زمانی مناسب است که شما میخواهید یک resource-oriented سرویس را بر روی HTTP ایجاد کنید. در اینجا میتوان از ویژگیهای کامل HTTP مانند URIs, request/response headers, caching, versioning, various content formats استفاده کرد و یا میخواهید سرویس را در معرض طیف گستردهای از کلاینتها شامل مرورگرها، موبایلها، iphone و تبلت قرار دهید.
سناریویی را در نظر بگیرید که یک برنامه وب نوشته شده، قرار است به چندین مستاجر (مشتری یا tenant) خدماتی را ارائه کند. در این حالت اطلاعات هر مشتری به صورت کاملا جدا شده از دیگر مشتریان در سیستم قرار دارد و فقط به همان قسمتها دسترسی دارد.
مثلا یک برنامه مدیریت رستوران را در نظر بگیرید که برای هر مشتری، در دامین
مخصوص به خود قرار دارد و همه آنها به یک سیستم متمرکز متصل شده و اطلاعات
خود را از آنجا دریافت میکنند.
در معماری Multi-Tenancy، چندین کاربر میتوانند از یک نمونه (Single
Instance) از اپلیکیشن نرمافزاری استفاده کنند. یعنی این نمونه روی سرور
اجرا میشود و به چندین کاربر سرویس میدهد. هر کاربر را یک Tenant
مینامیم. میتوان به Tenantها امکان تغییر و شخصیسازی بخشی از اپلیکیشن
را داد؛ مثلا امکان تغییر رنگ رابط کاربری و یا قوانین کسبوکار، اما آنها نمیتوانند
کدهای اپلیکیشن را شخصیسازی کنند.
خوشبختانه اوضاع با وجود OWIN بهتر شده و ما در این مطلب قصد استفاده از یک تولکیت را به نام SaasKit، برای پیاده سازی این معماری در ASP.NET Core داریم. هدف از این toolkit، سادهتر کردن هر چه بیشتر ساخت برنامههای SaaS (Software as a Service) هست. با استفاده از OWIN ما قادریم که بدون در نظر گرفتن فریم ورک مورد استفاده، رفتار مورد نظر خودمان را مستقیما در یک چرخه درخواست HTTP پیاده سازی کنیم و البته به لطف طراحی خاص ASP.NET Core 1.0 و استفاده از میان افزارهایی مشابه OWIN در برنامه، کار ما با SaasKit باز هم راحتتر خواهد بود.
شروع کار
یک پروژه ASP.NET Core جدید را ایجاد کنید و سپس ارجاعی را به فضای نام SaasKit.Multitenancy (موجود در Nuget) بدهید.PM> Install-Package SaasKit.Multitenancy
شناسایی مستاجر (tenant)
اولین جنبه در معماری multi-tenant، شناسایی مستاجر بر اساس اطلاعات درخواست جاری میباشد که میتواند از hostname ، کاربر جاری یا یک HTTP header باشد.ابتدا به تعریف کلاس مستاجر میپردازیم:
public class AppTenant { public string Name { get; set; } public string[] Hostnames { get; set; } }
public class AppTenantResolver : ITenantResolver<AppTenant> { IEnumerable<AppTenant> tenants = new List<AppTenant>(new[] { new AppTenant { Name = "Tenant 1", Hostnames = new[] { "localhost:6000", "localhost:6001" } }, new AppTenant { Name = "Tenant 2", Hostnames = new[] { "localhost:6002" } } }); public async Task<TenantContext<AppTenant>> ResolveAsync(HttpContext context) { TenantContext<AppTenant> tenantContext = null; var tenant = tenants.FirstOrDefault(t => t.Hostnames.Any(h => h.Equals(context.Request.Host.Value.ToLower()))); if (tenant != null) { tenantContext = new TenantContext<AppTenant>(tenant); } return tenantContext; } }
سیم کشی کردن
بعد از پیاده سازی این اینترفیس نوبت به سیم کشیهای SaasKit میرسد. من در اینجا سعی کردم که مثل الگوی برنامههای ASP.NET Core عمل کنم. ابتدا نیاز داریم که وابستگیهای SaasKit را ثبت کنیم. فایل startups.cs را باز کنید و کدهای زیر را در متد ConfigureServices اضافه نمایید:public void ConfigureServices(IServiceCollection services) { services.AddMultitenancy<AppTenant, AppTenantResolver>(); }
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { // after .UseStaticFiles() app.UseMultitenancy<AppTenant>(); // before .UseMvc() }
دریافت مستاجر جاری
حالا هر جا که نیاز به وهلهای از شیء مستاجر جاری داشتید، میتوانید به روش زیر عمل کنید:public class HomeController : Controller { private AppTenant tenant; public HomeController(AppTenant tenant) { this.tenant = tenant; } }
@inject AppTenant Tenant;
<a asp-controller="Home" asp-action="Index">@Tenant.Name</a>
اجرای نمونه مثال
فایل project.json را باز کنید و مقدار web را به شکل زیر مقدار دهی کنید: (در اینجا برای سایت خود 3 آدرس را نگاشت کردیم)"commands": { "web": "Microsoft.AspNet.Server.Kestrel --server.urls=http://localhost:6000;http://localhost:6001;http://localhost:6002", },
dotnet run
و اگر آدرس http://localhost:6002 را وارد کنیم، مستاجر 2 را مشاهده میکنیم:
قابل پیکربندی کردن مستاجر ها
از آنجائیکه نوشتن مشخصات مستاجرها در کد زیاد جالب نیست، برای همین
تصمیم داریم که این مشخصات را با استفاده از قابلیتهای ASP.NET Core از
فایل appsettings.json دریافت کنیم. تنظیمات مستاجرها را مطابق اطلاعات زیر به این فایل اضافه کنید:
"Multitenancy": { "Tenants": [ { "Name": "Tenant 1", "Hostnames": [ "localhost:6000", "localhost:6001" ] }, { "Name": "Tenant 2", "Hostnames": [ "localhost:6002" ] } ] }
public class MultitenancyOptions { public Collection<AppTenant> Tenants { get; set; } }
services.Configure<MultitenancyOptions>(Configuration.GetSection("Multitenancy"));
public class AppTenantResolver : ITenantResolver<AppTenant> { private readonly IEnumerable<AppTenant> tenants; public AppTenantResolver(IOptions<MultitenancyOptions> options) { this.tenants = options.Value.Tenants; } public async Task<TenantContext<AppTenant>> ResolveAsync(HttpContext context) { TenantContext<AppTenant> tenantContext = null; var tenant = tenants.FirstOrDefault(t => t.Hostnames.Any(h => h.Equals(context.Request.Host.Value.ToLower()))); if (tenant != null) { tenantContext = new TenantContext<AppTenant>(tenant); } return Task.FromResult(tenantContext); } }
در آخر
اولین قدم در پیاده سازی یک معماری multi-tenant، تصمیم گیری درباره این
موضوع است که شما چطور مستاجر خود را شناسایی کنید. به محض این شناسایی شما میتوانید عملیاتهای بعدی خود را مثل تفکیک بخشی از برنامه، فیلتر کردن دادهای، نمایش یک view خاص برای هر مستاجر و یا بازنویسی قسمتهای مختلف
برنامه بر اساس هر مستاجر، انجام دهید.
_ سورس مثال بالا در گیت هاب قابل دریافت میباشد.
_ منبع: اینجا
مقدمهای بر Docker
دو مفهوم اساسی در محیط Docker وجود دارند که دانستن آنها ضروری است: Image و Container
image عملا چیزی است که از آن برای Build یک Container استفاده میشود. image دارای یک سری فایلهای لازم و اساسی است که باعث میشود بر روی یک Operation System اجرا شود؛ مثل Ubuntu یا Windows. بنابراین شما Application Framework خود را خواهید داشت و همچنین Databaseی که با آن کار میکند. بنابراین قابلیت استفاده از زبانها و فریم ورکهای مختلف چون Asp.net Core, Nodejs, Python و غیره را خواهد داشت. یک image به خودی خود غیر قابل استفاده است تا زمانیکه بر روی یک Container توزیع شده باشد، تا قابلیت اجرا پیدا کند. بنابراین نقطهی شروع اصلی اجرایی یک برنامه با Container مربوط به آن میباشد.
به صورت خلاصه Image یک template از نوع Readonly است که ترکیبی از لایههای File System میباشد، به همراه فایلهای share شدهی دیگر (از قبیل فریم ورکها و ...) که میتوانند یک Docker Container Instance را تولید نمایند.
Container یک محیط امن و ایزوله است که به وسیلهی image ساخته شده است و میتواند اجرا، متوقف، منتقل و یا حذف شود (بطور قابل ملاحظهای اجرا کردن و متوقف کردن آن سریع میباشد).
تفاوت Docker Containers و Virtual Machines
Virtual Machines همیشه بر روی Host Operation System اجرا میشوند (که میتواند بر روی ویندوز یا لینوکس باشد) و بعد از آن اجرای Guest OS بر روی سطحی به نام Hypervisor. پس میتوان گفت یک کپی کامل از سیستم عامل است که که بر روی hypervisor اجرا میشود و خودش نیز بر روی سخت افزار اجرا میشود. بنابراین میتوان مثل شکل زیر، یک App داشت که عملا یک سری باینری و کتابخانه است و اگر قرار باشد بر روی سیستم عاملهای مختلفی کار کند، احتیاج به کپی کردن کل آن میباشد و بطور واضحی زمان و هزینهی بیشتری برای بالا آوردن آن لازم است.
اما بر خلاف آن، داکر با استفاده از ابزاری به نام Docker Engine کار میکند که میتواند Containerهای مختلفی از OSهای مختلف را اجرا نماید و نیازی به کپی گرفتن از کل سیستم عامل برای اجرای هر container نخواهد بود.
بنابراین با استفاده از ابزارهای مجازی سازی چون Vmware، نسخهی کاملی را از سیستم عامل مطبوع خود میتوان نصب و اجرا نمود؛ اما برخلاف آن با استفاده از داکر، یک نسخهی کوچک از سیستم عامل، بدون وابستگیها و پیچیدگیهای نسخهی اصلی در اختیار خواهد بود.
با این وجود، بوسیله داکر به راحتی میتوان تعداد زیادی از Containerها را به راحتی و با سرعت بالا اجرا نموده و مورد تست و ارزیابی قرار داد.
چطور Docker میتواند سریعتر از Virtual Machineها عمل کند ؟
داکر از چیزی به نام Copy On Write استفاده میکند؛ به معنای کپی کردن همزمان با نوشتن. همانطور که گفته شد هر Container از یک Image ساخته میشود و عملا Imageها همان FileSystemهای از قبل تولید شده هستند و هر کدام از لایهای از کتابخانهها استفاده میکنند که برای اجرای برنامههای کاربردی مورد استفاده قرار میگیرند. سرور آپاچی را در نظر بگیرید، به عنوان یک فایل image که FileSystem بر روی آن ذخیره شدهاست. با نصب Php یک لایه بر روی لایه دیگر ایجاد شده و فقط تغییرات جدید به آن اضافه خواهند شد و حال اگر بخواهید تغییری را بر روی source code خود بدهید، عملا فقط آن تغییر به Image و FileSystem اضافه خواهد شد. این معماری لایه لایه باعث تولید یک FileSystem بصورت read-only میشود که شامل لایههای متفاوتی است و سبب کم حجم شدن آن، بالا رفتن سرعت آن میشود و همچنین با استفاده از Caching، قدرت زیادی را بدان میبخشد.
پس همانطور که در شکل فوق مشاهده میکنید، هر image از لایههای مختلفی تشکیل شده است و توانایی به اشتراک گذاشتن این لایههای متمایز از یکدیگر در Containerها وجود دارد.
بنابراین طبق شکل فوق، بحث را اینگونه خلاصه میکنیم که هر Image از ترکیبی از لایههایی از نوع read-only تشکیل شده است و با اضافه شدن Container، عملا یک لایهی دیگری که قابلیت read/write را دارد بر روی آن اضافه میشود و درون آن source code میتواند قرار گیرد و اینکه بر مبنای شکل زیر میبینید که قابلیت به اشتراک گذاری Image layerها به Containerهای مختلف تعبیه شده است که باعث میشود لایهی نصب شده بر روی سیستم، بصورت اشتراکی قابل استفادهی مجدد باشد و فضای دیسک کمتری، به علاوه سرعت اجرای بالاتری را داشته باشد. هر لایه یک مقدار هش شدهی یکتایی را در اختیار دارد تا از لایههای دیگر تمیز داده شود و قابل شناسایی باشد.
داکر در شبکه چگونه کار میکند؟
ضمنا نکتهی قابل توجه که در مقالههای بعدی به صورت عملی به آن میپردازیم این است که با استفاده از داکر میتوانیم وب سرورهایی را بر روی Containerهای مختلفی داشته باشیم که همگی بر روی پورت بطور مثال 80 هستند؛ طوری که درون هر Container بدلیل ایزوله بودن پروسسهای مخصوص Container مربوط به خود، به پورتهای باز داخل آن شبکه دسترسی دارند و میتوانند پورت در نظر گرفته شدهی درون Container را با پورت دیگری بیرون Container به اصطلاح Expose نمایند.
ضمن اینکه نکتهی دیگری که وجود دارد، ارتباط Containerها با یکدیگر است. برای مثال یک Container برای Database و دیگری برای WebApp میباشد که باید به همدیگر link شده تا قابل استفاده گردند و عملا نیازی به نوشتن ip یکدیگر در این حالت وجود ندارد. البته راههای دیگری از قبیل Compose کردن نیز وجود دارد که در ادامه بیشتر با آنها آشنا خواهیم شد.
Docker Volume چیست؟
بحث دیگری که وجود دارد، Volumeها هستند که قسمتی از FileSystemها میباشند و بصورت ساده، مثال کاربردیاش میتواند قسمتی از یک سیستم و دایرکتوری خاصی را بر روی Container خاصی Map کردن باشد و عملا داخل آن دایرکتوری میتواند source code بوده باشد (یکی از راههای ممکن برای map کردن source code به container) و بر روی Container ایجاد شود.
فوایدی که با استفاده از Volumeها میتوان به آن رسید از قبیل موارد زیر میباشند:
قابلیت به اشتراک گذاری یک Volume بین Containerهای مختلف که به شدت میتواند قابل استفاده باشد.
Data Volumeها ماندگار هستند. یعنی حتی بعد از اینکه Container مربوطه را حذف نمایید، volume مربوط به آن بطور اتوماتیک حذف نمیشود (مگر اینکه خودتان دستور حذف کردن آن را وارد نمایید). پس عملا قابلیت استفادهی مجدد را نیز خواهد داشت.
طبق شکل فوق ما میتوانیم درون یک container یک volume داشته باشیم. وقتی ما چیزی را درون آن مینویسیم عملا داریم در قسمت خاصی به نام Docker Host عمل write کردن را انجام میدهیم که باعث میشود داکر متوجه آن شود. وقتی اسمی را به یک Volume انتساب میدهیم همانند /var/www، در واقع یک اسم مستعار (alias) میباشد که اشاره میکند به این Docker host موجود. در ادامه بیشتر با Volumeها آشنا خواهیم شد.
DockerFile و ساخت imageها چگونه است؟
روش دیگر برای اجرای source code در داکر، ساخت یک image اختصاصی از آن و اجرا کردن آن بر روی یک container مجزا است. با استفاده از DockerFile میتوانید imageهای خود را build کرده که عملا هر image در آخر باید به یک سیستم عامل برسد و همانطور که گفته شد به صورت لایهای کار میکنند و مراتب اجرای آن از قبیل working directory و expose کردن بر روی پورتی خاص، همچنین استفاده از Environment Variableها میباشد و همچنین با استفاده از DockerHub (که نسخهی enterprise نیز دارد) میتوان imageهای ساخته شده را بر روی cloud نگه داشت و همهی اعضای تیم از یک image بخصوص استفاده کنند؛ برای مثال همهی اعضای تیم از یک نسخهی Nodejs استفاده کنند و اشتباها بر روی ماشینهای توسعهی مختلف برنامه نویسان، از نسخههای مختلفی استفاده نشود و همچنین روند بهروز رسانی به سادگی انجام گیرد.
مزایای Docker برای برنامه نویسان
فرض کنید که یک App Service از Azure تهیه کرده باشید. تستهای unit, integration, acceptance را انجام داده و با خیال راحت Container خود را از طریق برای مثال Visual studio team service بر روی App service به صورت انتشار از طریق مدل Continuous Integration و Continuous Deployment داشته باشید. پس عملا داکر به Devops بودن محیط و چابک بودن تیم توسعه کمک شایانی کرده و فرآیندهای سخت و زمانبر انتقال Codeها از محیط توسعه به محیط انتشار را تسریع میبخشد.
بنابراین از داکر به راحتی میتوان در محیط Production نیز استفاده کرد و مزایای فوق العاده ای را برای برنامه نویسان ارائه کرده است. بطور مثال فرض کنید در تولید نرمافزار یک Web server ، تعدادی Database و یک Caching server که کانفیگ کردن، اجرا و ... به صورت عادی بسیار صعب و مشکل ساز بوده را به راحتی میتوان اجرا نمود. ضمن اینکه ممکن است هر کدام از ابزارهایی که استفاده شده، فقط مخصوص سیستم عاملی خاص باشد که قاعدتا احتیاج به بالا آوردن Virtual Machine خواهید بود و در سناریوهای خاصی مثل سیستم هایی با معماری Microservice که هر کدام از این ریز سرویسها ممکن است زبان، فریم ورک، دیتابیس و ... مخصوص به خود را داشته باشند، عملا کار بسیار سخت و پر هزینه خواهد بود (ضمن اینکه استفادهی همزمان از چند Virtual Machine در کنار هم در محیط توسعه، حجم زیادی از memory و disk سیستم شما را خواهد گرفت و شما را مجبور به ارتقای سیستم خود خواهد کرد!).
مشکل دیگری که Docker آن را حل کرده، Conflictهای ورژنهای مختلف ابزارهای مورد استفاده است. به راحتی میتوان Containerی از Imageها را به صورت ایزوله با ورژنهای مختلفی ایجاد کرد تا بطور کامل برنامه نویسان را از مشکل همیشگی بهروزرسانیها و Role-back کردنها آسوده خاطر نماید.
از آنجایی که داکر قابلیت اجرای در محیط production را نیز دارد، عملا محیط Development با محیط Production تفاوتی ندارد و این جملهی معروف که «در سیستم من کار میکند اما در نسخهی انتشار داده شده خیر» دیگر اتفاق نخواهد افتاد.
به راحتی میتوانید از یک Image خاص، Containerهای ایزولهی متفاوتی را ساخته و همگی آنها را در کنار هم اجرا نمود و مورد تست و ارزیابی قرار داد.
Dokcer hub
مخرنی است از هزاران Image آماده از قبیل سیستم عامل، فریم ورک و... که قابلیت استفادهی مجدد خواهد داشت. همچنین شما میتوانید Imageهای خود را نیز بدان اضافه نموده تا دیگران از آن استفاده نمایند. استفاده از مخزنهای public آن رایگان میباشد. از آنجایی که Docker یک محصول متن باز و رایگان است، یک بخش از درآمدهای آن از فروش اختصاصی مخزنها در DokcerHub میباشد (چیزی شبیه به Private Repository در Github).
بیشتر از این به مفاهیم نمیپردازیم. برای مطالعهی بیشتر، کتاب فوق العادهی Mastering Docker را پیشنهاد میکنم.
شروع به کار با Docker
بعد از نصب کردن نسخهی رسمی Docker و باز کردن ترمینال مربوطه، اولین دستوراتی را که باید با آن آشنا باشیم، شامل موارد زیر میباشد:
لیست Imageهای کش شدهی بر روی سیستم:
docker images
docker ps
برای آزمایش کردن و نصب اولین image، دستور زیر را وارد میکنیم (میتوانید اطلاعات بیشتری از imageها را در dockerHub پیدا کنید). من در اینجا kitematic/hello-world-nginx را به عنوان image از مخزن dokcerhub، بر روی سیستم خود pull کردهام (این یک نسخهی بسیار سبک از کانتینر nginx میباشد).
docker pull kitematic/hello-world-nginx
حال وقت اجرای این image و توزیع آن بر روی container میباشد که با استفاده از دستور زیر است:
docker run -p 80:80 kitematic/hello-world-nginx
بعد از اجرای این دستور میتوانید با وارد کردن ip مربوط به virtual machine ساخته شده بر روی سیستم خود (اگر از مک یا ویندوز استفاده میکنید احتمالا 192.168.99.100 خواهد بود) که البته با دستور docker-machine ip میتوانید آن را پیدا کنید و وارد کردن آن بر روی مرورگر خود، تصویری مثل زیر را مشاهده کنید:
بدین معناست که container شما اجرا شده و قابلیت مورد استفاده قرار گرفتن را خواهد داشت. حال اگر دستور docker ps را مجددا وارد نمایید، اطلاعات این container را از نوع id, status port و غیره، مشاهده خواهید کرد.