برنامه های کاربردی "ابر بومی" یا به سادگی "ابر" به طور خاص برای کار در زیرساخت های ابری ایجاد می شوند. آنها معمولاً به عنوان مجموعه‌ای از میکروسرویس‌های با جفت آزاد بسته‌بندی شده در ظروف ساخته می‌شوند که به نوبه خود توسط یک پلت فرم ابری مدیریت می‌شوند. چنین برنامه‌هایی به‌طور پیش‌فرض برای خرابی‌ها آماده می‌شوند، به این معنی که حتی در صورت خرابی‌های جدی در سطح زیرساخت، به طور قابل اعتماد و مقیاس‌پذیر کار می‌کنند. روی دیگر سکه مجموعه ای از محدودیت ها (قراردادها) است که پلتفرم ابری برای برنامه های کاربردی کانتینری اعمال می کند تا بتواند به صورت خودکار آنها را مدیریت کند.
در حالی که کاملاً از نیاز و اهمیت حرکت به سمت برنامه های کاربردی مبتنی بر ابر آگاه هستند، بسیاری از سازمان ها هنوز نمی دانند از کجا شروع کنند. در این پست، تعدادی از اصول را بررسی خواهیم کرد که در صورت رعایت آنها هنگام توسعه برنامه های کاربردی کانتینری، به شما این امکان را می دهد که به پتانسیل پلتفرم های ابری پی ببرید و حتی در صورت خرابی های جدی در زیرساخت فناوری اطلاعات، به عملکرد و مقیاس بندی قابل اعتماد برنامه ها دست یابید. مرحله. هدف نهایی اصولی که در اینجا ذکر شده است، یادگیری نحوه ساخت برنامه هایی است که می توانند به طور خودکار توسط پلتفرم های ابری مانند Kubernetes مدیریت شوند.
اصول طراحی نرم افزار
در دنیای برنامه نویسی، اصول به قوانین نسبتاً کلی اشاره دارد که باید هنگام توسعه نرم افزار رعایت شوند. هنگام کار با هر زبان برنامه نویسی می توان از آنها استفاده کرد. هر اصل اهداف خاص خود را دارد که ابزار دستیابی به آنها معمولاً الگوها و شیوه ها هستند. همچنین تعدادی اصول اساسی برای ایجاد نرم افزار با کیفیت بالا وجود دارد که سایر اصول از آن سرچشمه می گیرند. در اینجا چند نمونه از اصول اساسی آورده شده است:
- (آن را ساده نگه دارید، احمقانه) - آن را پیچیده نکنید.
- (خودت را تکرار نکن) - خودت را تکرار نکن;
- (شما به آن نیاز نخواهید داشت) - چیزی را ایجاد نکنید که فورا مورد نیاز نیست.
- تفکیک نگرانی ها - تقسیم مسئولیت ها.
همانطور که می بینید، این اصول قوانین خاصی را تعیین نمی کنند، بلکه متعلق به دسته ملاحظات به اصطلاح عقل سلیم مبتنی بر تجربه عملی هستند که توسط بسیاری از توسعه دهندگان به اشتراک گذاشته شده است و مرتباً به آن اشاره می کنند.
علاوه بر این ، وجود دارد – مجموعه ای از پنج اصل اول برنامه نویسی و طراحی شی گرا که توسط رابرت مارتین فرموله شده است. SOLID شامل اصول گسترده، باز و مکمل است که - وقتی با هم به کار می روند - به ایجاد سیستم های نرم افزاری بهتر و نگهداری بهتر آنها در طولانی مدت کمک می کنند.
اصول SOLID متعلق به حوزه OOP است و به زبان مفاهیم و مفاهیمی مانند کلاس‌ها، رابط‌ها و وراثت فرموله شده است. بر اساس قیاس، اصول توسعه را می توان برای برنامه های ابری نیز فرموله کرد، فقط عنصر اساسی در اینجا یک کلاس نیست، بلکه یک ظرف است. با پیروی از این اصول، می توانید برنامه های کاربردی کانتینری ایجاد کنید که اهداف و اهداف پلتفرم های ابری مانند Kubernetes را بهتر برآورده کنند.
ظروف بومی ابر: رویکرد کلاه قرمزی
امروزه تقریباً هر برنامه کاربردی را می توان به راحتی در ظروف بسته بندی کرد. اما برای اینکه برنامه‌ها به طور موثر در یک پلتفرم ابری مانند Kubernetes خودکار و هماهنگ شوند، تلاش بیشتری لازم است.
مبنای ایده های ذکر شده در زیر روش شناسی بود و بسیاری کارهای دیگر در مورد جنبه های مختلف ساخت برنامه های کاربردی وب، از مدیریت کد منبع گرفته تا مدل های مقیاس بندی. اصولی که توضیح داده شد فقط برای توسعه برنامه‌های کانتینری که بر روی میکروسرویس‌ها ساخته شده‌اند و برای پلتفرم‌های ابری مانند Kubernetes طراحی شده‌اند، اعمال می‌شود. عنصر اساسی در بحث ما تصویر کانتینر است و زمان اجرای کانتینر هدف پلت فرم هماهنگ سازی کانتینر است. هدف اصول پیشنهادی ایجاد محفظه‌هایی است که وظایف زمان‌بندی، مقیاس‌بندی و نظارت را می‌توان در اکثر پلتفرم‌های ارکستراسیون خودکار کرد. اصول بدون ترتیب خاصی ارائه شده است.
اصل نگرانی واحد (SCP)
این اصل از بسیاری جهات شبیه به اصل مسئولیت واحد است. ) که بخشی از مجموعه SOLID است و بیان می کند که هر شی باید یک مسئولیت داشته باشد و مسئولیت باید به طور کامل در یک کلاس کپسوله شود. نکته SRP این است که هر مسئولیتی دلیلی برای تغییر است و یک کلاس باید یک و تنها یک دلیل برای تغییر داشته باشد.
در SCP، ما از کلمه "نگرانی" به جای کلمه "مسئولیت" برای نشان دادن سطح بالاتر انتزاع و هدف گسترده تر یک ظرف در مقایسه با کلاس OOP استفاده می کنیم. و اگر هدف SRP داشتن تنها یک دلیل برای تغییر باشد، پس SCP تمایل به گسترش توانایی استفاده مجدد و جایگزینی کانتینرها است. با پیروی از SRP و ایجاد یک ظرف که یک مشکل را حل می کند و آن را به روشی کامل انجام می دهد، شانس استفاده مجدد از آن تصویر ظرف در زمینه های مختلف برنامه را افزایش می دهید.
اصل SCP بیان می کند که هر ظرف باید یک مشکل واحد را حل کند و آن را به خوبی انجام دهد. علاوه بر این، SCP در دنیای کانتینر آسان‌تر از SRP در دنیای OOP است، زیرا کانتینرها معمولاً یک فرآیند واحد را اجرا می‌کنند و بیشتر اوقات این فرآیند یک کار واحد را حل می‌کند.
اگر یک میکروسرویس کانتینری باید چندین مشکل را همزمان حل کند، آنگاه می‌توان آن را به کانتینرهای تک وظیفه‌ای تقسیم کرد و با استفاده از قالب‌های کانتینر کناری و اولیه در یک غلاف (یک واحد استقرار سکوی کانتینر) ترکیب کرد. علاوه بر این، SCP جایگزینی یک کانتینر قدیمی (مانند یک وب سرور یا کارگزار پیام) را با یک ظرف جدید آسان می کند که همان مشکل را حل می کند اما دارای عملکرد گسترده یا مقیاس بهتر است.
اصل مشاهده پذیری بالا (HOP)
هنگامی که کانتینرها به عنوان روشی یکپارچه برای بسته بندی و اجرای برنامه ها استفاده می شوند، خود برنامه ها به عنوان یک جعبه سیاه در نظر گرفته می شوند. با این حال، اگر اینها کانتینرهای ابری هستند، باید APIهای ویژه ای را برای زمان اجرا ارائه کنند تا سلامت کانتینرها را نظارت کنند و در صورت لزوم اقدامات مناسب را انجام دهند. بدون این، امکان یکپارچه سازی اتوماسیون به روز رسانی کانتینرها و مدیریت چرخه عمر آنها وجود نخواهد داشت که به نوبه خود پایداری و قابلیت استفاده سیستم نرم افزار را بدتر می کند.
در عمل، یک برنامه کاربردی کانتینری حداقل باید یک API برای انواع مختلف بررسی های سلامتی داشته باشد: تست های زنده بودن و تست های آمادگی. اگر برنامه ای ادعا می کند که کارهای بیشتری انجام می دهد، باید ابزار دیگری برای نظارت بر وضعیت خود ارائه دهد. به عنوان مثال، ثبت رویدادهای مهم از طریق STDERR و STDOUT برای جمع آوری گزارش با استفاده از Fluentd، Logstash و سایر ابزارهای مشابه. و همچنین ادغام با کتابخانه های مجموعه ردیابی و معیارها، مانند OpenTracing، Prometheus و غیره.
به طور کلی، برنامه همچنان می تواند به عنوان یک جعبه سیاه در نظر گرفته شود، اما باید تمام API های مورد نیاز پلتفرم را در اختیار داشته باشد تا بتوان آن را به بهترین شکل ممکن نظارت و مدیریت کرد.
اصل انطباق چرخه عمر (LCP)
LCP نقطه مقابل HOP است. در حالی که HOP بیان می کند که کانتینر باید API های خوانده شده را در معرض پلتفرم قرار دهد، LCP از برنامه می خواهد که بتواند اطلاعات پلتفرم را بپذیرد. علاوه بر این، ظرف نه تنها باید رویدادها را دریافت کند، بلکه باید خود را تطبیق دهد، به عبارت دیگر، به آنها واکنش نشان دهد. از این رو نام این اصل است که می تواند به عنوان یک الزام برای ارائه پلت فرم با نوشتن API در نظر گرفته شود.
پلتفرم ها انواع مختلفی از رویدادها برای کمک به مدیریت چرخه حیات یک کانتینر دارند. اما این به خود برنامه بستگی دارد که تصمیم بگیرد کدام یک از آنها را درک کند و چگونه واکنش نشان دهد.
واضح است که برخی از رویدادها مهمتر از دیگران هستند. به عنوان مثال، اگر یک برنامه به خوبی خرابی ها را تحمل نمی کند، باید پیام های سیگنال: خاتمه (SIGTERM) را بپذیرد و روال خاتمه خود را در سریع ترین زمان ممکن آغاز کند تا سیگنال را بگیرد: kill (SIGKILL) که بعد از SIGTERM می آید.
علاوه بر این، رویدادهایی مانند PostStart و PreStop می توانند برای چرخه عمر یک برنامه مهم باشند. برای مثال، پس از راه‌اندازی یک برنامه، ممکن است قبل از اینکه بتواند به درخواست‌ها پاسخ دهد، به زمان آماده‌سازی نیاز دارد. یا برنامه باید هنگام خاموش شدن، منابع را به روش خاصی آزاد کند.
اصل تغییرناپذیری تصویر (IIP)
به طور کلی پذیرفته شده است که برنامه های کاربردی کانتینری پس از ساخت باید بدون تغییر باقی بمانند، حتی اگر در محیط های مختلف اجرا شوند. این امر نیاز به خارجی سازی ذخیره سازی داده ها در زمان اجرا (به عبارت دیگر استفاده از ابزارهای خارجی برای این کار) و تکیه بر پیکربندی های خارجی و خاص زمان اجرا را به جای تغییر یا ایجاد کانتینرهای منحصر به فرد برای هر محیط ضروری می کند. پس از هر تغییری در برنامه، تصویر کانتینر باید بازسازی شود و در تمام محیط‌های مورد استفاده مستقر شود. به هر حال، هنگام مدیریت سیستم های فناوری اطلاعات، از یک اصل مشابه استفاده می شود که به عنوان اصل تغییر ناپذیری سرورها و زیرساخت ها شناخته می شود.
هدف IIP جلوگیری از ایجاد تصاویر کانتینر مجزا برای محیط های زمان اجرا مختلف و استفاده از یک تصویر در همه جا همراه با پیکربندی خاص محیطی مناسب است. پیروی از این اصل به شما این امکان را می دهد که از نقطه نظر اتوماسیون سیستم های ابری، اقدامات مهمی مانند به روز رسانی برنامه های کاربردی را به عقب برگردانید و رول به جلو پیاده سازی کنید.
اصل یکبار مصرف فرآیندی (PDP)
یکی از مهم ترین ویژگی های یک کانتینر زودگذر بودن آن است: یک نمونه از یک ظرف به راحتی ایجاد می شود و به راحتی از بین می رود، بنابراین می توان آن را به راحتی با نمونه دیگری در هر زمان جایگزین کرد. دلایل زیادی برای چنین جایگزینی وجود دارد: شکست تست قابلیت سرویس، مقیاس‌پذیری برنامه، انتقال به میزبان دیگر، فرسودگی منابع پلتفرم یا موقعیت‌های دیگر.
در نتیجه، برنامه های کاربردی کانتینری باید با استفاده از برخی ابزارهای خارجی وضعیت خود را حفظ کنند یا برای این کار از طرح های توزیع شده داخلی با افزونگی استفاده کنند. علاوه بر این، برنامه باید سریع شروع شود و به سرعت خاموش شود و برای خرابی سخت افزاری مرگبار ناگهانی آماده شود.
یکی از روش هایی که به اجرای این اصل کمک می کند، کوچک نگه داشتن ظروف است. محیط‌های ابری می‌توانند به‌طور خودکار میزبانی را برای راه‌اندازی یک نمونه کانتینر انتخاب کنند، بنابراین هرچه ظرف کوچکتر باشد، سریعتر شروع به کار می‌کند - به سادگی سریعتر در میزبان هدف از طریق شبکه کپی می‌شود.
اصل خودکنترلی (S-CP)
طبق این اصل، در مرحله مونتاژ، تمام اجزای لازم در ظرف گنجانده شده است. کانتینر باید با این فرض ساخته شود که سیستم فقط یک هسته لینوکس خالص دارد، بنابراین تمام کتابخانه‌های اضافی لازم باید در خود ظرف قرار گیرند. همچنین باید شامل مواردی مانند زمان اجرا برای زبان برنامه نویسی مربوطه، پلت فرم برنامه (در صورت لزوم) و سایر وابستگی هایی باشد که در حین اجرای برنامه کانتینر مورد نیاز خواهند بود.
برای پیکربندی‌هایی که از محیطی به محیط دیگر متفاوت است، استثناهایی وجود دارد و باید در زمان اجرا ارائه شوند، به عنوان مثال از طریق یک Kubernetes ConfigMap.
یک برنامه ممکن است شامل چندین مؤلفه کانتینری باشد، به عنوان مثال، یک ظرف DBMS جداگانه در یک برنامه وب کانتینری. طبق اصل S-CP، این کانتینرها نباید در یک واحد ترکیب شوند، بلکه باید به گونه ای ساخته شوند که کانتینر DBMS حاوی همه چیزهایی باشد که برای عملکرد پایگاه داده لازم است و کانتینر برنامه وب حاوی همه چیزهایی باشد که برای عملکرد وب لازم است. برنامه، همان وب سرور. در نتیجه، در زمان اجرا، کانتینر برنامه وب به کانتینر DBMS بستگی دارد و در صورت نیاز به آن دسترسی خواهد داشت.
اصل محدودیت زمان اجرا (RCP)
اصل S-CP تعریف می کند که ظرف چگونه باید ساخته شود و تصویر باینری باید شامل چه مواردی باشد. اما یک ظرف فقط یک "جعبه سیاه" نیست که فقط یک مشخصه دارد - اندازه فایل. در طول اجرا، ظرف ابعاد دیگری به خود می گیرد: میزان حافظه استفاده شده، زمان CPU و سایر منابع سیستم.
و در اینجا اصل RCP مفید است، که طبق آن کانتینر باید نیازهای خود را برای منابع سیستم جدا کرده و آنها را به پلت فرم منتقل کند. پلتفرم با نمایه‌های منابع هر کانتینر (میزان CPU، حافظه، شبکه و منابع دیسکی که نیاز دارد)، می‌تواند زمان‌بندی و مقیاس خودکار را به‌طور بهینه انجام دهد، ظرفیت IT را مدیریت کند و سطوح SLA را برای کانتینرها حفظ کند.
علاوه بر برآورده کردن منابع مورد نیاز کانتینر، برای برنامه نیز مهم است که از مرزهای خود فراتر نرود. در غیر این صورت، هنگامی که کمبود منبع رخ می دهد، پلتفرم به احتمال زیاد آن را در لیست برنامه هایی که باید خاتمه یا مهاجرت کنند، قرار دهد.
وقتی در مورد ابر اول بودن صحبت می کنیم، در مورد نحوه کار خود صحبت می کنیم.
در بالا، تعدادی از اصول کلی را فرموله کردیم که پایه های روش شناختی را برای ساخت برنامه های کاربردی کانتینری با کیفیت بالا برای محیط های ابری تنظیم می کند.
توجه داشته باشید که علاوه بر این اصول کلی، به روش ها و تکنیک های پیشرفته دیگری نیز برای کار با ظروف نیاز خواهید داشت. علاوه بر این، ما چند توصیه کوتاه داریم که خاص تر هستند و بسته به شرایط باید اعمال شوند (یا اعمال نشوند):
- سعی کنید اندازه تصاویر را کاهش دهید: فایل های موقت را حذف کنید و بسته های غیر ضروری را نصب نکنید - هرچه اندازه کانتینر کوچکتر باشد، سریعتر مونتاژ شده و در میزبان مورد نظر از طریق شبکه کپی می شود.
- روی User-ID های دلخواه تمرکز کنید: از دستور sudo یا هر userid خاصی برای راه اندازی کانتینرهای خود استفاده نکنید.
- علامت گذاری پورت های مهم: می توانید شماره پورت ها را در زمان اجرا تنظیم کنید، اما بهتر است آنها را با استفاده از دستور EXPOSE مشخص کنید - این کار استفاده از تصاویر شما را برای افراد و برنامه ها آسان تر می کند.
- ذخیره داده‌های پایدار در حجم‌ها: داده‌هایی که باید پس از نابودی کانتینر باقی بمانند باید در حجم‌ها نوشته شوند.
- ابرداده تصویر بنویسید: برچسب‌ها، برچسب‌ها و حاشیه‌نویسی‌ها استفاده از تصاویر را آسان‌تر می‌کنند - توسعه‌دهندگان دیگر از شما تشکر خواهند کرد.
- همگام‌سازی میزبان و تصاویر: برخی از برنامه‌های کانتینری نیازمند همگام‌سازی کانتینر با میزبان بر روی ویژگی‌های خاص، مانند شناسه زمان یا ماشین هستند.
- در پایان، ما الگوها و بهترین روش‌هایی را به اشتراک می‌گذاریم که به شما کمک می‌کند اصول فهرست‌شده در بالا را به‌طور مؤثرتر پیاده‌سازی کنید:
11 ژوئن ساعت 11.00
چه چیزی یاد خواهید گرفت:
- غیرقابل تغییر Red Hat Enterprise Linux CoreOS
- مش سرویس OpenShift
- چارچوب اپراتور
- چارچوب Knative
منبع: www.habr.com