در این بخش از دوره آموزشیمان قصد داریم بپردازیم به انواع حالت های اسقرار سازی در حوزه Configuration Management
مفهوم استقرار سازی یا Deployment به این معنا میباشد که من بتوانم مقدار ها و پیکربندی های خاصی که نیاز دارم رو بر روی چندین دیوایس خود Deployed یا استقرار سازی کنیم. که البته توضیح این موضوع به این شکل بیشتر در دید حوزه Configuration Management میباشد در حوزه های دیگر و موقعیت های دیگر نیز همین معنا را میدهد اما با کمی تغییر
حالت های استقرار سازی در Configuration Management به دو دسته متفاوت تقسیم بندی میشوند که عبارتند از:
Push-Based: در این روش از طریق Master Node پیکربندی انجام میشود.
Pull-Based: در این روش استقرار سازی توسط Agent انجام میشود.
در این حالت Matser Node ما به عنوان یک سرور مرکزی عمل میکند و در این خود و دیوایس های مورد نظر یک ارتباط امن و مطمئن را ایجاد میکند، پس از ایجاد ارتباط شروع به پیکربندی و ارسال دستورات میکند مانند نرم افزار های Salt Stack و Ansible
در این حالت دیوایس ها به سرور مورد نظر متصل میشوند ارتباط امن و مطمئن را ایجاد میکنند و از برقراری صحیح ارتباط اطمینان حاصل میکنند و پس از آن پیکربندی را از سمت سرور دانلود میکنند و بر روی خود استقرار سازی میکنند مانند Chef و Puppet
نحوه کار Puppet بر پایه Pull یا همان Pull Based Deployment میباشد و از این بابت دیوایس ها و تجهیزات مورد نظر ما در هر 1800ثانیه به سمت Puppet یک ارتباط را ایجاد میکنند و بررسی میکنند که آیا در Puppet پیکربندی جدیدی برایشان قرار گرفته است یا که خیر، درصورتی که پیکربندی خاصی در Puppet قرار گفته باشد کد های مورد نظر را دانلود میکنند و بر روی خود استقرار میسازند.
سناریو ما در Configuration Management از دو بخش Master و Agent تشکیل شده است که به شرح زیر هستند:
بخش Master - در این بخش Puppet بر روی یک سیستم لینوکسی اجرا سازی میشود و قرار است که به سرور ها و تجهیزات مورد نظر پیکربندی مورد نظرشان را ارائه کند.
نکته: Puppet فقط روی سیستم های لینوکسی اجرا سازی میشود به طور معمول
بخش Agent - این بخش را تجهیزات و دیوایس ها ما تشکیل داده اند که هیچ محدودیتی در سیستم عاملشان وجود ندارد و میتوانند طیف گسترده ایی از سیستم های مختلف از جمله خانواده Microsoft سیستم های هسته لینوکس سیستم های خانواده BSD و سیستم عامل های متعدد دیگری مانند Solaris و Mac OS
در ابتدا در بین Matser و Agent یک ارتباط امن ایجاد میشود.
نکته: ارتباطات بین Master و Agent از طریق Certificate امن سازی میشود.
مرحله اول - ابتدایی ترین کاری که پس از ایجاد شدن ارتباط صورت میگیرد این است که از سمت Agent های ما اطلاعاتی در رابطه خودشان به سمت Master ارسال میشود که از جمله این اطلاعات عبارتند از:
مرحله دوم - در این شرایط پس از دریافت اطلاعات توسط Puppet یک فایل توسط Puppet ایجاد میشود که اطلاعات تکمیلی Agent ها به همراه پیکربندی های مورد نیازشان در آن قرار میگیرد که آن را با عنوان Configuration List میشناسم و تمامی اطلاعات در کنار در فایلی به نام Catalog قرار میگیرد. از جمله پیکربندی های که میتوان توی Configuration List: نصب، حذف و بروزرسانی بسته نرم افزار خاصی، ایجاد User و حذف User، راه اندازی مجدد و Restart کردن سیستم، پیکربندی و تغییر تنظیمات IP و...
مرحله 3 - در این مرحله فایل قسمت Configuration List در فایل Catalog به سمت Agent ها ارسال میشود و آنها پس از دریافت پیکربندی ها آنهارا بر روی خودشان اعمال میکنند.
نکته: درصورتی که Configuration List خالی باشد هیچ پیکربندی بر روی Agent ها انجام نمیشود.
مرحله چهارم - در این مرحله گزارشی به سمت Puppet در رابطه با موفقیت آمیز بودن فرآیند اعمال پیکربندی ارسال میشود.
مباحث متنوعی را در رابطه با Puppet یادگرفتیم حالا بیاید بررسی کنیم که Puppet دارای چه ویژگی هایی میباشد به نوع دیگر قرار است توی این بخش به Feature های متعدد Puppet بپردازیم
این ویژگی یکی از جالب ترین تکنیک های مورد استفاده در Puppet است که به سبب آن، نرم افزار Puppet یک نرم افزار منحصر به فرد در این حوزه شده است. به واسطه Idempotency ما توانایی و این امکان را داریم که مجموعه ایی از پیکربندی هارا در بازه های زمانی خاص بر روی یک دیوایس اعمال کنیم. در شرایطی که تغییری در دیوایس مورد نظر ایجاد شود Puppet آن را بررسی میکند و ویژگی های قبلی را به سمت همان دیوایس در بازه های زمانی مختلف استقرار سازی میکند.
توجه داشته باشید ویژگی Puppet Idempotency در شرایطی میتواند بکار بیاید که شما بخواهید در بازه های زمانی یک پیکربندی خاصی را بر روی دیوایس اعمال کنید. درنظر داشته باشید که وقتی یک سیستم اجرا سازی میشود و شروع به کار میکند تا پایان عمر آن در بازه های زمانی نیاز به پیکربندی و تعمیر و بروزرسانی دارد که ما میتوانیم به سبب این ویژگی در Puppet اینکار هارا به انجام برسانیم، معمولا از این ویژگی برای بروزنگه داشتن سیستم ها استفاده میشود
اگر یادتان باشد در قسمت قبل ما عنوان کردیم که در Puppet محدودیتی وجود ندارد که سیستم های Agent چه سیستم عاملی را داشته باشند اما چطور؟! از کجا Puppet میتونه متوجه این بشه که برای سیستم مورد نظر از چه پیکربندی استفاده کند و از چه دستوری برای پیکربندی های مورد نظر استفاده کند؟ دقیقا اینجاست که ویژگی تحت عنوان RAL یا همان Resource Application Layer پا به میدان میگذارد و این نگرانی هارا برطرف میکند.
مهندس و مدرس شبکه و امنیت سایبری و مدیر کل جزیره هک و امنیت اطلاعات توسینسو
متخصص امنیت اطلاعات و کارشناس شکار تهدیدات بانک ملی ایران ، دارای مدارک مختلف از Splunk و AWS و Fortinet و Huawei حوزه اصلی فعالیت بنده در زمینه شبکه مباحث R&S و Service Provider میباشد و در زمینه امنیت نیز در موقعیت های مختلفی مانند PenTest و SoC فعالیت داشته و دارم. سابقه همکاری با بعضی سازمان های در قالب پروژه و... را داشته ام الان به عنوان تحلیلگر امنیت سایبری در زیرساخت بانک ملی مشغول به کار هستم. لینکداین: https://www.linkedin.com/in/amirhoseintangsirinezhad/
زمان پاسخ گویی روز های شنبه الی چهارشنبه ساعت 9 الی 18
فقط به موضوعات مربوط به محصولات آموزشی و فروش پاسخ داده می شود