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

تجربه خود مایکروسافت با مایکروسافت ۳۶۵ نشان می‌دهد که حتی زمانی که کد زیادی برای جابه‌جایی دارید، انتقال به فضای ابری امکان‌پذیر است.

یک ضرب المثل قدیمی وجود دارد که اغلب توسط توسعه دهندگانی که بر روی پلتفرم های مایکروسافت ایجاد می کنند به اشتراک گذاشته می شود: “چگونه می توانید تشخیص دهید که یک محصول مایکروسافت برای بهترین زمان آماده است؟ وقتی مایکروسافت از آن برای یکی از برنامه‌ها یا سرویس‌های پرچم‌دار خود استفاده می‌کند.»

این بدان معناست که زمان شروع استفاده از چارچوب برنامه توزیع‌شده اورلئان است که بخش‌های بزرگی از Halo را تامین می‌کند، زمان استفاده از Fluid Framework زمانی که وارد Teams می‌شود، و همینطور ادامه دارد. آخرین سرویسی که مهر تأیید را دریافت کرد، کانتینرهای Windows در سرویس Azure Kubernetes است. مایکروسافت یک سال گذشته را صرف کرده است برای انتقال قطعات بزرگ پلت فرم Microsoft 365 به AKS با هدف مقیاس پذیرتر و انعطاف پذیرتر کردن آن در پرتو تغییرات سریع در الگوهای کاری ناشی از همه گیری COVID-19.

انتقال Microsoft 365 به cloud-native و AKS

انتقال سرویسی به اندازه Microsoft 365 به کانتینرها فرآیند پیچیده ای بود. رفتن از سیستم‌های تک مستاجر آفیس آنلاین به معماری مجازی‌سازی چند مستاجر، به‌ویژه زمانی که با حرکت به سمت CI/CD (ادغام پیوسته و تحویل مداوم) ترکیب می‌شد، به اندازه کافی سخت بود. آن تغییر اول بسیاری از اصلاحات معماری را که برای تغییر به کانتینرها ضروری است، انجام داد. اول از همه، انتقال وضعیت از VMs برنامه به چیزی که ما اکنون به عنوان Microsoft Graph می شناسیم، بود. با این حال، بسیاری از خدمات سفارشی بود، به ویژه برای مدیریت در دسترس بودن و پشتیبانی از شبکه بین ماشین‌ها و سرویس‌هایی که مستاجر را تشکیل می‌دادند.

این رویکرد منجر به عدم ثبات شد: ساخت‌های برنامه باید پلتفرم‌های خاصی را هدف قرار دهند. در نتیجه، ناکارآمدی‌های معماری را ایجاد کرد زیرا انواع سرورهای مختلف برای میزبانی ماشین‌های مجازی مختلف مورد نیاز بودند، که پیچیدگی و هزینه‌های مراکز داده‌ای را که میزبان خدمات مایکروسافت ۳۶۵ بودند، افزایش داد. که به هزینه اجرای سرویس اضافه شد. بارها را نمی‌توان به راحتی بین سرورها جابه‌جا کرد تا از استفاده بهینه اطمینان حاصل شود، که این امر مزیت‌های هزینه‌ای hyperscale را کاهش داد.

ساخت بر روی Kubernetes مستلزم بازنگری در مورد خدمات یکپارچه و بازسازی آنها برای کارکردن به عنوان میکروسرویس های مقیاس پذیر است. با این حال، از آنجایی که آنها می‌توانستند از کانتینرهای ویندوز استفاده کنند، تیم چیزی را که قبلاً استفاده می‌کرد از دست نداد: میزبان‌های کانتینر AKS می‌توانستند با ابزارها و سرویس‌های دات‌نت مناسب با دسترسی به APIهای ویندوز تدارک ببینند. در حالی که این ویژگی‌های میزبان بین کانتینرها به اشتراک گذاشته می‌شوند، جداسازی کانتینر تضمین می‌کند که می‌توان به طور ایمن به آنها دسترسی داشت.

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

حرکت به معماری بومی ابری برای مایکروسافت ۳۶۵ مزایای دیگری نیز دارد. همه توسعه‌دهندگان سطح API یکسانی دارند، که آزمایش‌ها و مدیریت تغییرات را ساده می‌کند و به تیم اجازه می‌دهد تا از CI/CD به عنوان بخشی از یک مدل عملیات برنامه کاربردی استفاده کند و حفظ کند. عملیات پلت فرم جدا از کد و مدیریت ویژگی های AKS مورد استفاده توسط سرویس است. برنامه‌ها ابتدا برای آزمایش خوشه‌ها، سپس به حلقه‌های اولیه برای کاربران داخلی و خودی‌های خارجی قبل از انتقال به تولید، ساخته و مستقر می‌شوند.

چگونه کد خود را کانتینری کنید

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

معمولاً، تیم Windows Containers مایکروسافت اخیراً مستنداتی را بر اساس تجربه اش ارائه کرده است در کار با مشتریانی مانند Microsoft 365. این به شما مجموعه ای از نکات را می دهد که هنگام جابجایی یک برنامه از محیط ویندوز سرور – حتی یک مورد که مجازی شده است – به کانتینرها. کار با کانتینرها مانند کار با یک سرور نیست، حتی اگر به API ها و کتابخانه های آشنا دسترسی داشته باشیم.

مراقب مسدود کننده های ظرف باشید

بسیاری از لیست مسدود کننده ها عقل سلیم است. کانتینرها برای برنامه های تعاملی نیستند و پشتیبانی از رابط کاربری گرافیکی نیز وجود ندارد. سیستم عامل میزبان نسخه ای از Windows Server Core است، بنابراین کد باید طوری طراحی شود که برای آن کار کند، به عنوان مثال، فقط از نصب های بی صدا پشتیبانی می کند یا اجازه دسترسی به RDP را نمی دهد. بدون UI، کد به APIهای مدیریت جایگزین نیاز دارد، به عنوان مثال، ارائه نقاط پایانی برای استفاده با Windows Admin Center.

به طور مشابه، باید مطمئن شوید که کد هرگز داده ها را در داخل یک ظرف ذخیره نمی کند. که شامل تنظیمات می شود. کانتینرها باید به عنوان اقلام بی حالت و زودگذری در نظر گرفته شوند که طبق نیاز پلتفرم ارکستراسیون کانتینری مانند Kubernetes ایجاد و از بین می روند. اگر AKS را هدف قرار می‌دهید، از یک نمونه ذخیره‌سازی Azure، مانند Azure Files یا Blob برای نگهداری وضعیت و داده‌ها برای کانتینرهای خود استفاده کنید. به این ترتیب، اگر کانتینری که فرآیند پرداخت را مدیریت می کند با شکست مواجه شود، جایگزینی می تواند وضعیت جلسه را دریافت کند و بدون اینکه کاربر متوجه شود ادامه دهد. به طور مشابه، اگر تقاضا به کانتینرهای اضافی نیاز داشته باشد، می توانند وضعیت و تنظیمات برنامه را به محض آماده شدن دریافت کنند.

محدودیت های دیگری نیز وجود دارد. کد شما باید روی ویندوز سرور ۲۰۱۶ یا جدیدتر اجرا شود، بنابراین برنامه‌های قدیمی‌تر ممکن است نیاز به کار سازگاری داشته باشند. همین امر در مورد نسخه های قدیمی تر دات نت فریم ورک نیز صدق می کند. اگرچه مایکروسافت تصاویر کانتینر را با نسخه‌های پشتیبانی شده ارائه می‌کند، بهتر است مطمئن شوید که کد تحت نسخه‌های جدیدتر اجرا می‌شود که برای پشتیبانی از معماری‌های میکروسرویس طراحی شده‌اند و ردپای کوچک‌تری دارند و به کانتینرهای بیشتری اجازه می‌دهند روی همان میزبان اجرا شوند. مهم است که از هر گونه وابستگی به نقش های Active Directory یا هر گونه ویژگی زیرساخت ویندوز سرور اجتناب کنید. ظرف شما برای برنامه شما است، نه چیز دیگری.

در صورت امکان از خدمات ابری استفاده کنید

اگر قصد دارید به AKS یا نمونه‌های کانتینر Azure یا حتی برنامه‌های کانتینر Azure بروید، ارزش این را دارد که در کجا می‌توانید از سایر سرویس‌های Azure در برنامه خود استفاده کنید. . اگر به پایگاه‌های داده یا سایر برنامه‌ها وابستگی دارید، ممکن است استفاده از معادل Azure آسان‌تر از راه‌اندازی یک سرور مجازی برای میزبانی برنامه باشد. از طرف دیگر، یک نسخه بهینه سازی شده برای ابر و نسخه پشتیبانی شده توسط فروشنده ممکن است در Azure Marketplace باشد. به طور مشابه، در جایی که ممکن است از Active Directory برای کنترل دسترسی استفاده کرده باشید، از Azure Active Directory API استفاده کنید زیرا با کانتینرهای زودگذر سازگار هستند.

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

Containerization یک تکنیک مفید برای ساخت برنامه‌های کاربردی جدید ابری، تلقی کانتینرها به عنوان نقطه پایانی خط لوله CI/CD و استفاده از Kubernetes برای هماهنگ‌سازی و مقیاس‌بندی سرویس‌هایی است که برنامه شما را تشکیل می‌دهند. تجربه خود مایکروسافت نشان می‌دهد که انتقال از زیرساخت‌های مجازی به cloud-native امکان‌پذیر است و مستندات آن نکاتی را در مورد چگونگی ایجاد تغییرات لازم ارائه می‌دهد. این آسان نیست، اما همانطور که مایکروسافت ۳۶۵ ثابت می کند، مزایای آن می تواند ارزش تلاش مهندسی لازم را داشته باشد.