حالت تاریک
فصل ۱۳ — ایمیج سرور بهصورت کد
فصل ۱۱ به ایده ایجاد چند نمونه سرور از یک منبع واحد اشاره کرد («Prebuilding Servers» در صفحه ۱۸۳)، و استفاده از image سرور ساختهشده بهصورت تمیز را توصیه کرد («Creating a Clean Server Image» در صفحه ۱۸۵). اگر میپرسیدید بهترین راه برای پیروی از این توصیه چیست، این فصل برای کمک به شماست.
مانند بیشتر چیزها در سیستم شما، باید از کد برای ساخت و بهروزرسانی imageهای سرور بهصورت قابل تکرار استفاده کنید. هر بار که تغییری در image میدهید — مثلاً نصب آخرین patchهای سیستمعامل — میتوانید مطمئن باشید که آن را بهصورت سازگار میسازید.
با استفاده از فرایند خودکار و مبتنی بر کد برای ساخت، تست، تحویل و بهروزرسانی imageهای سرور، میتوانید راحتتر سرورها را بهروز نگه دارید و از انطباق و کیفیت آنها اطمینان حاصل کنید.
چرخه عمر پایه image سرور شامل ساخت image سفارشی از منبع مبدأ است (شکل ۱۳-۱ را ببینید).
شکل ۱۳-۱. چرخه عمر image سرور
ساخت image سرور
بیشتر پلتفرمهای مدیریت زیرساخت قالبی برای imageهای سرور دارند که برای ایجاد نمونه سرور استفاده میشود. Amazon دارای AMI، Azure دارای managed image و VMware دارای VM template است. پلتفرمهای میزبانیشده imageهای stock از پیش بستهبندیشده با سیستمعاملها و توزیعهای رایج ارائه میدهند تا بتوانید سرور بسازید بدون اینکه خودتان image بسازید.
چرا image سرور بسازیم؟
بیشتر تیمها در نهایت imageهای سفارشی میسازند بهجای استفاده از imageهای stock فروشنده پلتفرم. دلایل رایج:
انطباق با حاکمیت سازمانی بسیاری از سازمانها، بهویژه در صنایع تنظیمشده، باید مطمئن شوند سرورها را طبق دستورالعملهای سختگیرانهتر میسازند.
سختسازی برای امنیت imageهای stock سرور معمولاً بستهها و ابزارهای زیادی نصب دارند تا برای طیف گستردهای از موارد مفید باشند. میتوانید imageهای سفارشی را به حداقل عناصر کاهش دهید. سختسازی میتواند شامل غیرفعال یا حذف حسابهای کاربری و سرویسهای سیستم استفادهنشده، غیرفعال کردن همه پورتهای شبکه که برای عملیات لازم نیستند، و قفل کردن مجوزهای filesystem و پوشه باشد.¹
بهینهسازی برای کارایی بسیاری از گامهایی که برای سختسازی imageها برای امنیت برمیدارید — مثل توقف یا حذف سرویسهای سیستم غیرضروری — مصرف CPU و حافظه سرور را هم کاهش میدهد. کوچک کردن اندازه image سرور هم ایجاد نمونه سرور را سریعتر میکند که در سناریوهای scaling و بازیابی مفید است.
نصب بستههای رایج میتوانید مجموعه استانداردی از سرویسها، agentها و ابزارها را روی imageهای سرور نصب کنید تا روی همه نمونهها در دسترس باشند. مثالها شامل agentهای monitoring، حسابهای کاربری سیستم، و ابزارها و اسکریپتهای نگهداری مختص تیم است.
ساخت image برای نقشهای سرور بسیاری از مثالهای این فصل فراتر از ساخت image استاندارد و همهمنظوره میروند. میتوانید imageهای سرور متناسب با هدف خاص بسازید — مثل node کلاستر کانتینر، application server یا agent سرور CI.
چگونه image سرور بسازیم
فصل ۱۱ چند روش مختلف ایجاد نمونه سرور جدید را توضیح داد، از جمله hot-clone نمونه موجود یا استفاده از snapshot از نمونه موجود («Prebuilding Servers» در صفحه ۱۸۳). اما نمونههای ساختهشده از image سرور مدیریتشده بهخوبی تمیزتر و سازگارترند.
دو رویکرد برای ساخت image سرور وجود دارد. رایجترین و سادهترین، ساخت image آنلاین است — نمونه سرور جدید میسازید و پیکربندی میکنید، سپس آن را به image تبدیل میکنید. رویکرد دوم، ساخت image آفلاین است — volume دیسک را mount میکنید، فایلهای لازم را روی آن کپی میکنید، و سپس آن را به image قابل boot تبدیل میکنید.
trade-off اصلی بین ساخت آنلاین و آفلاین سرعت و دشواری است. ساخت image سرور آنلاین آسانتر است، اما boot و پیکربندی نمونه جدید میتواند کند باشد — در حد چند دقیقه یا دهها دقیقه. mount و آمادهسازی دیسک آفلاین معمولاً خیلی سریعتر است، اما کمی کار بیشتری میخواهد.
قبل از بحث نحوه پیادهسازی هر کدام، اشاره به ابزارهای ساخت image سرور ارزش دارد.
ابزارهای ساخت image سرور
ابزارها و سرویسهای ساخت image سرور معمولاً با orchestrate کردن فرایند ایجاد نمونه سرور یا volume دیسک، اجرای ابزار یا اسکریپت پیکربندی سرور برای سفارشیسازی آن، و سپس استفاده از API پلتفرم زیرساخت برای تبدیل نمونه سرور به image کار میکنند. باید بتوانید این فرایند را بهصورت کد تعریف کنید — به همان دلایل معمول. بهزودی مثالهایی از کد ساخت image به اشتراک میگذارم تا رویکردهای آنلاین و آفلاین را نشان دهم.
Netflix پیشگام استفاده سنگین از imageهای سرور بود و ابزار Aminator را که برای این کار ساخته بود open source کرد. Aminator مختص روشهای کاری Netflix است و imageهای CentOS و Red Hat برای AWS EC2 میسازد.²
محبوبترین ابزار ساخت image در زمان نگارش این کتاب، Packer از HashiCorp است. Packer از انواع سیستمعامل و پلتفرمهای زیرساخت پشتیبانی میکند.
برخی پلتفرمهای زیرساخت سرویسهایی برای ساخت imageهای سرور خود ارائه میدهند، از جمله AWS Image Builder و Azure Image Builder.
مثالهای کد ساخت image سرور در این فصل از یک زبان ساخت image ساده و خیالی استفاده میکنند.
فرایند ساخت image آنلاین
روش آنلاین ساخت imageهای سرور شامل boot نمونه سرور جدید و تمیز، پیکربندی آن، و سپس تبدیل آن به قالب image سرور پلتفرم زیرساخت است، همانطور که در شکل ۱۳-۲ نشان داده شده.
شکل ۱۳-۲. فرایند آنلاین ساخت image سرور
فرایند با boot نمونه سرور جدید از image مبدأ شروع میشود، همانطور که در مثال ۱۳-۱ نشان داده شده. برای گزینههای image مبدأ به «Origin Content for a Server Image» در صفحه ۲۱۴ مراجعه کنید. اگر از ابزاری مثل Packer برای ساخت image استفاده کنید، از API پلتفرم برای ایجاد نمونه سرور استفاده میکند.
مثال ۱۳-۱. کد نمونه image builder برای boot از image مبدأ
yaml
image:
name: shopspinner-linux-image
platform: fictional-cloud-service
origin: fci-12345678
region: europe
instance_size: smallاین کد نمونه یک image FCS به نام shopspinner-linux-image میسازد و آن را از FCI موجود با شناسه fci-12345678³ boot میکند. این یک توزیع Linux stock ارائهشده توسط فروشنده cloud است. این کد هیچ action پیکربندی مشخص نمیکند، پس image حاصل تقریباً کپی مستقیم image مبدأ است.
کد همچنین چند ویژگی نمونه سرور برای boot جهت ساخت image را تعریف میکند، از جمله region و نوع instance.
زیرساخت برای نمونه builder
احتمالاً باید منابع زیرساختی برای نمونه ساخت image سرور فراهم کنید — مثلاً بلوک آدرس. مطمئن شوید context امن و ایزوله مناسبی برای این نمونه فراهم میکنید.
اجرای نمونه builder روی زیرساخت موجود ممکن است راحت باشد، اما ممکن است فرایند ساخت image شما را در معرض compromise قرار دهد. ایدهآل این است که زیرساخت disposable برای ساخت image بسازید و بعد از آن نابودش کنید.
مثال ۱۳-۲ شناسه subnet و کلید SSH را به نمونه image builder اضافه میکند.
مثال ۱۳-۲. منابع زیرساخت تخصیصیافته پویا
yaml
image:
name: shopspinner-linux-image
origin: fci-12345678
region: europe
size: small
subnet: ${IMAGE_BUILDER_SUBNET_ID}
ssh_key: ${IMAGE_BUILDER_SSH_KEY}این مقادیر جدید از پارامترها استفاده میکنند که میتوانید بهصورت خودکار تولید و به ابزار image builder پاس دهید. فرایند ساخت image شما ممکن است با ایجاد نمونهای از stack زیرساخت که این چیزها را تعریف میکند شروع شود، سپس پس از اجرای ابزار image builder آنها را نابود کند. این نمونهای از اسکریپت orchestration ابزار زیرساخت است («Using Scripts to Wrap Infrastructure Tools» در صفحه ۳۳۵ را ببینید).
باید منابع و دسترسی provisionشده برای نمونه سرور image builder را به حداقل برسانید. فقط دسترسی inbound برای ابزار provisioning سرور مجاز باشد — و فقط اگر configuration را push میکنید («Pattern: Push Server Configuration» در صفحه ۱۹۸). فقط دسترسی outbound لازم برای دانلود بستهها و پیکربندی مجاز باشد.
پیکربندی نمونه builder
وقتی نمونه سرور در حال اجراست، فرایند شما میتواند پیکربندی سرور را روی آن اعمال کند. بیشتر ابزارهای ساخت image سرور از اجرای ابزارهای رایج پیکربندی سرور پشتیبانی میکنند («Server Configuration Code» در صفحه ۱۷۲)، مشابه ابزارهای مدیریت stack («Applying Server Configuration When Creating a Server» در صفحه ۱۸۹). مثال ۱۳-۳ مثال ۱۳-۲ را گسترش میدهد تا ابزار Servermaker را برای پیکربندی نمونه بهعنوان application server اجرا کند.
مثال ۱۳-۳. استفاده از ابزار Servermaker برای پیکربندی نمونه سرور
yaml
image:
name: shopspinner-linux-image
origin: fci-12345678
region: europe
instance_size: small
subnet: ${IMAGE_BUILDER_SUBNET_ID}
configure:
tool: servermaker
code_repo: servermaker.shopspinner.xyz
server_role: appserverکد یک نقش سرور اعمال میکند، همانطور که در «Server Roles» در صفحه ۱۷۵ — که ممکن است application server و عناصر مرتبط را نصب کند.
استفاده از اسکریپتهای ساده برای ساخت image سرور
وقتی از ابزار پیکربندی سرور برای پیکربندی نمونههای سرور جدید استفاده میکنید، منطقی است همان ابزار — و اغلب همان کد پیکربندی سرور — را هنگام ساخت imageهای سرور بهکار ببرید. این با فرایند baking و frying توضیحدادهشده در «Combining Baking and Frying» در صفحه ۱۸۸ همخوان است.
اما برای تیمهایی که imageهای سرور کاملتری میپزند («Baking Server Images» در صفحه ۱۸۷)، ابزار پیکربندی سرور کامل ممکن است بیش از حد باشد. این ابزارها و زبانهایشان پیچیدگی اضافه میکنند تا بتوانید آنها را مکرراً روی سرورهایی با شرایط شروع ناشناخته و متغیر اعمال کنید.
اما هر بار که image سرور میسازید، معمولاً از منبع مبدأ شناختهشده و سازگار میسازید. پس زبان اسکریپت سادهتر ممکن است مناسبتر باشد — Bash، batch script یا PowerShell مثلاً.
اگر اسکریپت برای پیکربندی imageهای سرور مینویسید، باید اسکریپتهای کوچک و ساده بنویسید، هر کدام متمرکز بر یک کار، بهجای اسکریپتهای بزرگ پیچیده با حلقههای شرطی. دوست دارم اسکریپتها را با عدد پیشوند بزنم تا ترتیب اجرا واضح باشد، همانطور که در مثال ۱۳-۴ نشان داده شده.
مثال ۱۳-۴. نمونه image builder با shell script
yaml
image:
name: shopspinner-linux-image
origin: fci-12345678
configure:
commands:
- 10-install-monitoring-agent.sh
- 20-install-jdk.sh
- 30-install-tomcat.shفرایند ساخت image آفلاین
فرایند boot نمونه سرور، اعمال پیکربندی، و سپس خاموش کردن نمونه برای ایجاد image سرور میتواند کند باشد. جایگزین استفاده از image مبدأیی است که بهعنوان volume دیسک قابل mount باشد — مثلاً AMI مبتنی بر EBS در AWS. میتوانید کپی این image را بهعنوان volume دیسک mount کنید و سپس فایلهای روی آن disk image را پیکربندی کنید، همانطور که در شکل ۱۳-۳ نشان داده شده. وقتی پیکربندی disk image تمام شد، میتوانید آن را unmount و به قالب image سرور پلتفرم تبدیل کنید.
شکل ۱۳-۳. فرایند آفلاین ساخت image سرور
برای ساخت image روی volume دیسک، باید volume را روی نمونه compute که ابزار ساخت image شما روی آن اجرا میشود mount کنید. مثلاً اگر imageها را با pipeline همانطور که بعداً در این فصل توضیح داده میشود میسازید، این میتواند agent ابزار CD باشد.
نیاز دیگر ابزار یا اسکریپتی است که volume دیسک را بهدرستی پیکربندی کند. این میتواند دشوار باشد. ابزارهای پیکربندی سرور کد پیکربندی را روی نمونه سروری که روی آن اجرا میشوند اعمال میکنند. حتی اگر اسکریپت سادهتری مثل shell script بنویسید، آن اسکریپتها اغلب ابزاری مثل installer بسته اجرا میکنند که بهطور پیشفرض فایلها را در filesystem سرور در حال اجرا نصب میکند:
yum install javaبسیاری از ابزارها گزینههای خط فرمان یا پیکربندی دارند که میتوانید برای نصب فایلها در مسیر دیگر تنظیم کنید. میتوانید از این برای نصب بستهها در مسیر دیگر استفاده کنید (مثلاً yum install java --prefix /mnt/image_builder/):
yum install --prefix /mnt/image_builder/ javaاما این کار دشوار و مستعد خطاست. و همه ابزارها چنین گزینهای ندارند.
رویکرد دیگر استفاده از دستور chroot است که دستوری را با root directory متفاوت filesystem اجرا میکند:
chroot /mnt/image_builder/ yum install javaمزیت chroot این است که برای هر ابزار یا دستوری کار میکند. ابزارهای محبوب ساخت image مثل Packer از chroot بهصورت built-in پشتیبانی میکنند.⁴
محتوای مبدأ برای image سرور
چند عنصر برای ساخت imageهای سرور کنار هم میآیند:
کد image builder کدی مینویسید که image را تعریف میکند و ابزار builder شما از آن استفاده میکند. فایل template Packer یک مثال است. این کد عناصر دیگر را که باید در image جمع شوند تعریف میکند.
image مبدأ (Origin source image) در بسیاری موارد، image را با image دیگری شروع میکنید. ممکن است به image مبدأ به قالب پلتفرم خود نیاز داشته باشید، مثل AMI. یا ممکن است image نصب سیستمعامل باشد — چه فیزیکی مثل DVD یا داده مثل image ISO. در بعضی موارد image را از صفر میسازید، مثلاً وقتی installer OS اجرا میکنید. هر کدام بعداً با جزئیات بیشتر توضیح داده میشود.
کد پیکربندی سرور ممکن است از ابزار پیکربندی سرور یا اسکریپت برای سفارشیسازی image استفاده کنید، همانطور که در بخش قبل توضیح داده شد.
عناصر دیگر سرور ممکن است از هر کدام یا همه عناصر و منابع آنها که در «What's on a Server» در صفحه ۱۷۰ توضیح داده شده برای ساخت image سرور استفاده کنید. استفاده از بستههای مخازن عمومی یا داخلی هنگام ساخت image رایج است.
⁴ برای chroot builders Packer برای AWS AMI و Azure server image مراجعه کنید.
این مجموعه عناصر وقتی از pipeline برای خودکارسازی فرایند ساخت image استفاده میکنید نقش دارد، همانطور که بعداً در این فصل توضیح داده میشود. انواع imageهای مبدأ شایان توجه بیشترند.
ساخت از image سرور stock
فروشندگان پلتفرم زیرساخت، فروشندگان سیستمعامل و پروژههای open source اغلب imageهای سرور میسازند و در اختیار کاربران و مشتریان قرار میدهند. همانطور که قبلاً گفته شد، بسیاری تیمها مستقیماً از این imageهای stock استفاده میکنند بهجای ساخت image خودشان. اما وقتی image خودتان را میسازید، این imageها معمولاً نقطه شروع خوبیاند.
یکی از مسائل imageهای stock این است که بسیاری از آنها over-provisioned هستند. سازندگان اغلب ابزارها و بستههای متنوعی نصب میکنند تا فوراً برای بیشترین تعداد کاربر مفید باشند. اما باید آنچه روی imageهای سفارشی سرور نصب میکنید را به حداقل برسانید — هم برای امنیت و هم برای کارایی.
میتوانید محتوای غیرضروری را از image مبدأ در فرایند پیکربندی image سرور حذف کنید یا imageهای مبدأ کوچکتر پیدا کنید. برخی فروشندگان و سازمانها imageهای JEOS (Just Enough Operating System) میسازند. افزودن آنچه نیاز دارید به image پایه حداقلی رویکرد قابلاطمینانتری برای حداقل نگه داشتن imageهاست.
ساخت image سرور از صفر
پلتفرم زیرساخت شما ممکن است imageهای stock ارائه ندهد، بهویژه اگر از cloud داخلی یا پلتفرم مجازیسازی استفاده کنید. یا تیم شما ممکن است ترجیح دهد از image stock استفاده نکند. جایگزین ساخت imageهای سرور سفارشی از صفر است.
image نصب OS نقطه شروع تمیز و سازگار برای ساخت template سرور به شما میدهد. فرایند ساخت template با boot نمونه سرور از image OS و اجرای فرایند نصب اسکریپتشده شروع میشود.⁵
منشأ (Provenance) image سرور و محتوای آن
نگرانی دیگر با imageهای پایه، مانند هر محتوایی از اشخاص ثالث، منشأ و امنیت آنهاست. باید مطمئن شوید میدانید چه کسی image را ارائه میدهد و چه فرایندی برای اطمینان از ساخت ایمن imageها دارد. چیزهایی که باید در نظر بگیرید:
- آیا imageها و بستهها نرمافزار با آسیبپذیریهای شناختهشده دارند؟
- فروشنده چه گامهایی برای اسکن کد برای مشکلات احتمالی — مثل static code analysis — برمیدارد؟
- چگونه میدانید آیا نرمافزار یا ابزارهای گنجاندهشده داده را به روشی جمعآوری میکنند که با سیاستهای سازمانی یا قوانین محلی شما در تضاد است؟
- فروشنده چه فرایندهایی برای تشخیص و جلوگیری از دستکاری غیرمجاز دارد، و آیا باید چیزی در سمت خود پیادهسازی کنید — مثل بررسی امضای بسته؟
نباید کاملاً به محتوایی که از فروشنده یا شخص ثالث میآید اعتماد کنید، پس باید بررسیهای خودتان را پیادهسازی کنید. «Test Stage for a Server Image» در صفحه ۲۲۳ پیشنهاد میدهد چگونه بررسی را در pipeline برای imageهای سرور بگنجانید.
تغییر image سرور
imageهای سرور با گذشت زمان که بستهها و پیکربندیهای بهروز منتشر میشوند کهنه میشوند. اگرچه میتوانید patch و بهروزرسانی را هر بار که سرور جدید میسازید اعمال کنید، این فرایند با گذشت زمان طولانیتر میشود و سود استفاده از image سرور را کاهش میدهد. تازهسازی منظم imageها همه چیز را روان نگه میدارد.
علاوه بر بهروز نگه داشتن imageها با آخرین patchها، اغلب باید پیکربندیهای پایه را بهبود دهید، بستههای استاندارد را اضافه یا حذف کنید، و تغییرات روتین دیگری در imageهای سرور بدهید. هرچه بیشتر در imageهای سرور سفارشی bake کنید بهجای frying در نمونههای سرور هنگام ایجاد، بیشتر باید imageها را با تغییرات بهروز کنید.
بخش بعد توضیح میدهد چگونه از pipeline برای ساخت، تست و تحویل تغییرات در imageهای سرور استفاده کنید. اما چند پیشنیاز قبل از ورود به pipeline وجود دارد. یکی نحوه اعمال بهروزرسانیهاست — استفاده از image سرور موجود بهعنوان پایه برای تغییر یا rebuild image از اصول اول. پیشنیاز دیگر versionگذاری imageهای سرور است.
گرم کردن مجدد یا پخت image تازه
وقتی میخواهید نسخه جدید image سرور بسازید — مثلاً برای بهروزرسانی با آخرین patchهای سیستمعامل — میتوانید همان ابزارها و فرایندهایی را که برای ساخت نسخه اول image استفاده کردید بهکار ببرید.
میتوانید نسخه قبلی image را بهعنوان image مبدأ استفاده کنید — reheating image. این اطمینان میدهد نسخه جدید با نسخه قبلی سازگار است، چون تنها تغییرات همانهاییاند که هنگام اعمال پیکربندی سرور به image جدید صریحاً میدهید.
جایگزین پخت image تازه است — ساخت نسخه جدید image از منابع اصلی. پس اگر نسخه اول image را از صفر ساختید، هر نسخه جدید را هم از صفر میسازید.
در حالی که reheating imageها ممکن است تغییرات بین نسخهها را محدود کند، پخت image تازه برای نسخه جدید باید با توجه به استفاده از همان منابع نتایج یکسان بدهد. ساختهای تازه استدلالاً تمیزتر و قابل تکرارترند چون چیزی که ممکن است از ساختهای قبلی باقی مانده باشد شامل نمیشوند. مثلاً پیکربندی سرور شما ممکن است بستهای نصب کند که بعد تصمیم بگیرید حذفش کنید. آن بسته هنوز روی imageهای سرور جدیدتر یافت میشود اگر از imageهای قدیمیتر reheat کنید. باید کدی اضافه کنید که صریحاً بسته را حذف کند، که کد اضافی برای نگهداری و بعداً پاکسازی به جا میگذارد. اگر در عوض هر بار image تازه bake کنید، بسته ساده روی imageهای سرور جدیدتر وجود نخواهد داشت و نیازی به نوشتن کد حذف نیست.
versionگذاری image سرور
ضروری است همه کسانی که از imageهای سرور و سرورهای ساختهشده از آنها استفاده میکنند بتوانند نسخهها را ردیابی کنند. باید بتوانند بفهمند چه نسخهای برای ایجاد هر نمونه سرور دادهشده استفاده شده، کدام نسخه برای image دادهشده آخرین است، و چه محتوای مبدأ و کد پیکربندی برای ساخت image بهکار رفته است.
همچنین مفید است بتوانید فهرست کنید کدام نسخههای image سرور برای ایجاد نمونههای در حال استفاده بهکار رفتهاند — مثلاً تا نمونههایی که باید هنگام کشف آسیبپذیری امنیتی بهروز شوند شناسایی کنید.
بسیاری تیمها imageهای سرور مختلف استفاده میکنند. مثلاً ممکن است imageهای جدا برای application server، nodeهای host کانتینر و image Linux همهمنظوره بسازید. در این صورت هر image را بهعنوان جزء جدا مدیریت میکنید، هر کدام با تاریخچه version جدا، همانطور که در شکل ۱۳-۴ نشان داده شده.
در این مثال، تیم image application server را برای ارتقای نسخه Tomcat نصبشده روی آن بهروز کرد و آن image را به نسخه ۲ برد، در حالی که بقیه در نسخه ۱ ماندند. سپس تیم همه imageها را با بهروزرسانیهای Linux OS بهروز کرد. این image application server را به نسخه ۳ و imageهای دیگر را به نسخه ۲ برد. در نهایت تیم نسخه نرمافزار کانتینر را روی image host node ارتقا داد و آن را به نسخه ۳ برد.
شکل ۱۳-۴. نمونه تاریخچه version برای چند image سرور
بیشتر پلتفرمهای زیرساخت مستقیماً از شمارهگذاری version برای imageهای سرور پشتیبانی نمیکنند. در بسیاری موارد میتوانید شماره version را در نام image سرور embed کنید. برای مثالهای شکل ۱۳-۴ ممکن است imageهایی به نام appserver-3، basic-linux-2 و container-node-3 داشته باشید.
گزینه دیگر قرار دادن شماره version و نام image در tag است اگر پلتفرم شما پشتیبانی کند. image میتواند tagی به نام Name=appserver و دیگری Version=3 داشته باشد.
از هر مکانیزمی استفاده کنید که جستجو، کشف و گزارشدهی نام و version image را آسانتر کند. بیشتر تیمهایی که با آنها کار کردهام از هر دو روش استفاده میکنند، چون tagها برای جستجو آساناند و نامها برای انسانها قابلمشاهدهترند.
میتوانید schemeهای شمارهگذاری version مختلف استفاده کنید. semantic versioning رویکرد محبوبی است که از فیلدهای مختلف یک شماره version سهبخشی (مثل 1.0.4) برای نشان دادن اهمیت تغییرات بین نسخهها استفاده میکند. دوست دارم timestamp تاریخ و زمان را به version اضافه کنم (مثلاً 1.0.4-20200229_0420) تا ببینم نسخه خاصی چه زمانی ساخته شده.
علاوه بر قرار دادن شماره version روی خود image سرور، میتوانید نمونههای سرور را با نام و version image سرور استفادهشده برای ایجاد آنها tag یا label کنید. سپس میتوانید هر نمونه را به image استفادهشده برای ایجادش map کنید. این توانایی برای rollout نسخههای جدید image مفید است.
بهروزرسانی نمونههای سرور وقتی image تغییر میکند
وقتی نسخه جدید image سرور میسازید، ممکن است همه نمونههای سرور مبتنی بر آن image را جایگزین کنید، یا منتظر بمانید تا بهطور طبیعی با گذشت زمان جایگزین شوند.
سیاست rebuild نمونههای سرور موجود برای جایگزینی versionهای قدیمی image میتواند disruptive و وقتگیر باشد. اما همچنین سازگاری سرورها را تضمین میکند و تابآوری سیستم شما را مداوم تمرین میدهد («Continuous Disaster Recovery» در صفحه ۳۷۹ را هم ببینید). pipeline خوب مدیریت این فرایند را آسانتر میکند و تغییرات zero-downtime («Zero Downtime Changes» در صفحه ۳۷۵) آن را کممزاحمتر میکند. پس این سیاست توسط بسیاری تیمها با اتوماسیون بالغ و گسترده ترجیح داده میشود.
آسانتر است منتظر بمانید تا سرورها با نسخه جدید image جایگزین شوند وقتی به دلایل دیگر rebuild میشوند. این ممکن است وقتی بهروزرسانیهای نرمافزار یا تغییرات دیگر را با rebuild نمونههای سرور deploy میکنید صادق باشد («Pattern: Immutable Server» در صفحه ۱۹۵).
عیب انتظار برای بهروزرسانی سرورها با versionهای جدید image این است که ممکن است مدتی طول بکشد و estate شما را با سرورهای ساختهشده از طیف گستردهای از versionهای image بگذارد.
این وضعیت ناسازگاری ایجاد میکند. مثلاً ممکن است application serverها با versionهای مختلف بهروزرسانی بسته OS و پیکربندی داشته باشند که به رفتار ناسازگار مرموز منجر میشود. در بعضی موارد، versionهای قدیمیتر image و سرورهای ساختهشده از آنها ممکن است آسیبپذیری امنیتی یا مسائل دیگر داشته باشند.
چند استراتژی برای کاهش این مسائل وجود دارد. یکی ردیابی نمونههای در حال اجرا در برابر versionهای image استفادهشده برای ایجاد آنهاست. این میتواند dashboard یا گزارشی مشابه جدول ۱۳-۱ باشد.
جدول ۱۳-۱. نمونه گزارش نمونهها و versionهای image آنها
| Image | Version | تعداد نمونه |
|---|---|---|
| basic-linux | 1 | 4 |
| basic-linux | 2 | 8 |
| appserver | 1 | 2 |
| appserver | 2 | 11 |
| appserver | 3 | 8 |
| container-node | 1 | 2 |
| container-node | 2 | 15 |
| container-node | 3 | 5 |
اگر این اطلاعات بهراحتی در دسترس باشد و بتوانید به فهرست سرورهای خاص drill down کنید، میتوانید نمونههای سروری که فوراً نیاز به rebuild دارند شناسایی کنید. مثلاً از آسیبپذیری امنیتی مطلع میشوید که در آخرین بهروزرسانی توزیع Linux شما رفع شده. patch را در basic-linux-2، appserver-3 و container-node-2 گنجاندهاید. گزارش نشان میدهد باید ۱۹ نمونه سرور rebuild کنید (۴ سرور basic Linux در نسخه ۱، ۱۳ application server در نسخههای ۱ و ۲، و ۲ container node در نسخه ۱).
ممکن است محدودیت سنی هم داشته باشید. مثلاً سیاستی داشته باشید که هر نمونه سرور در حال اجرا ساختهشده از image سرور قدیمیتر از سه ماه را جایگزین کند. گزارش یا dashboard شما باید تعداد نمونههایی که از این تاریخ گذشتهاند نشان دهد.
ارائه و استفاده از image سرور بین تیمها
در بسیاری سازمانها، تیم مرکزی imageهای سرور میسازد و برای تیمهای دیگر در دسترس قرار میدهد. این وضعیت چند پیچیدگی به مدیریت بهروزرسانی image سرور اضافه میکند.
تیمی که از image استفاده میکند باید مطمئن شود آماده استفاده از نسخههای جدید image است. مثلاً تیم برنامه داخلی ممکن است نرمافزار ردیابی باگ را روی image Linux پایه ارائهشده توسط تیم compute نصب کند. تیم compute ممکن است نسخه جدید image Linux پایه با بهروزرسانیهایی تولید کند که ناسازگاری با نرمافزار ردیابی باگ دارد.
ایدهآل این است که imageهای سرور به pipeline زیرساخت هر تیم feed شوند. وقتی تیم مالک image نسخه جدید را از pipeline خود منتشر میکند، pipeline زیرساخت هر تیم آن نسخه را pull میکند و نمونههای سرور را بهروز میکند. pipeline تیم داخلی باید بهطور خودکار تست کند نرمافزار ردیابی باگ با نسخه جدید image کار میکند قبل از rebuild سرورهایی که کاربرانش به آنها وابستهاند.
برخی تیمها رویکرد محافظهکارانهتر میگیرند و شماره version image استفادهشده را pin میکنند. تیم برنامه داخلی میتواند زیرساخت خود را به استفاده از نسخه ۱ image Linux پایه pin کند. وقتی تیم compute نسخه ۲ image را منتشر میکند، تیم برنامه داخلی تا آماده تست و rollout نسخه ۲ به استفاده از نسخه ۱ ادامه میدهد.
بسیاری تیمها وقتی اتوماسیون تست و تحویل تغییرات زیرساخت سرور به بلوغ نرسیده از رویکرد pinning استفاده میکنند. این تیمها برای اطمینان از تغییرات image کار دستی بیشتری نیاز دارند.
حتی با اتوماسیون بالغ، برخی تیمها imageها (و وابستگیهای دیگر) را که تغییراتشان پرریسکتر است pin میکنند. وابستگیها ممکن است شکنندهتر باشند چون نرمافزاری که تیم روی imageها deploy میکند به تغییرات سیستمعامل حساستر است. یا تیم ارائهدهنده image — شاید گروه خارجی — سابقه انتشار versionهای مشکلدار دارد و اعتماد پایین است.
مدیریت تغییرات عمده در image
برخی تغییرات در imageهای سرور مهمترند و احتمالاً نیاز به تلاش دستی بیشتری برای تست و تغییر وابستگیهای downstream دارند. مثلاً نسخه جدید image application server ممکن است ارتقای major نسخه نرمافزار application server را شامل شود.
بهجای treat کردن این بهعنوان بهروزرسانی جزئی image سرور، ممکن است از semantic versioning برای نشان دادن تغییر مهمتر استفاده کنید، یا حتی image سرور کاملاً متفاوتی بسازید.
وقتی از semantic versioning استفاده میکنید، بیشتر تغییرات پایینترین رقم version را افزایش میدهند، مثلاً از 1.2.5 به 1.2.6. تغییر عمده را با افزایش رقم دوم یا اول نشان میدهید. برای بهروزرسانی جزئی نرمافزار application server که نباید مسائل سازگاری برای برنامهها ایجاد کند، ممکن است نسخه 1.2.6 image سرور را به 1.3.0 افزایش دهید. برای تغییر عمده که ممکن است برنامهها را بشکند، بالاترین رقم را افزایش میدهید، پس 1.3.0 با 2.0.0 جایگزین میشود.
در بعضی موارد، بهویژه وقتی انتظار دارید version قدیمیتر image مدتی توسط تیمها استفاده شود، ممکن است image کاملاً جدیدی بسازید. مثلاً اگر image Linux پایه شما از CentOS 9.x استفاده میکند اما میخواهید CentOS 10.x را تست و rollout کنید، بهجای افزایش شماره version image، میتوانید image جدیدی مثل basic-linux10-1.0.0 بسازید. این مهاجرت به نسخه OS جدید را صریحتر از بهروزرسانی روتین image میکند.
استفاده از pipeline برای تست و تحویل image سرور
فصل ۸ استفاده از pipeline برای تست و تحویل تغییرات کد زیرساخت را توضیح میدهد («Infrastructure Delivery Pipelines» در صفحه ۱۱۹). pipelineها راه عالی برای ساخت imageهای سرورند. استفاده از pipeline ساخت نسخههای جدید image را آسان میکند و اطمینان میدهد بهصورت سازگار ساخته میشوند. با pipeline بالغ یکپارچه با pipelineهای بخشهای دیگر سیستم، میتوانید patch و بهروزرسانی سیستمعامل را در estate خود هفتگی یا حتی روزانه بهایمن rollout کنید.
ایده خوبی است imageهای سرور جدید را اغلب بسازید — مثلاً هفتگی — بهجای فاصلههای طولانی مثل هر چند ماه. این با رویه اصلی تست و تحویل مداوم تغییرات همخوان است. هرچه بیشتر برای ساخت image سرور جدید صبر کنید، تغییرات بیشتری شامل میشود که کار تست، یافتن و رفع مشکلات را افزایش میدهد.
یک pipeline پایه image سرور سه مرحله دارد، همانطور که در شکل ۱۳-۵ نشان داده شده.
شکل ۱۳-۵. یک pipeline ساده image سرور
هر کدام از این مراحل ساخت، تست و انتشار image سرور شایان نگاه دقیقترند.
مرحله ساخت برای image سرور
مرحله ساخت pipeline image سرور بهطور خودکار فرایند ساخت image آنلاین («Online Image Building Process» در صفحه ۲۱۰) یا فرایند ساخت image آفلاین («Offline Image Building Process» در صفحه ۲۱۳) را پیادهسازی میکند. مرحله یک image سرور تولید میکند که مراحل بعدی آن را بهعنوان release candidate treat میکنند (شکل ۱۳-۶ را ببینید).
شکل ۱۳-۶. مرحله ساخت image سرور
میتوانید مرحله ساخت image سرور را طوری پیکربندی کنید که بهطور خودکار با تغییر در هر کدام از ورودیهای image فهرستشده در «Origin Content for a Server Image» در صفحه ۲۱۴ اجرا شود. مثلاً:
- کسی تغییری در کد image builder commit میکند، مثل template Packer
- فروشنده نسخه جدید image مبدأ شما را منتشر میکند، مثل AMI ارائهشده توسط فروشنده OS
- تغییراتی در کد پیکربندی سرور استفادهشده برای image سرور میدهید
- نگهدارندگان بسته نسخههای جدید بستههای نصبشده روی image سرور را منتشر میکنند
در عمل، بسیاری تغییرات در عناصر مبدأ مثل بستههای OS را سخت است بهطور خودکار تشخیص داد و برای trigger کردن pipeline استفاده کرد. ممکن است هم نخواهید برای هر بهروزرسانی بسته image سرور جدید بسازید، بهویژه اگر image دهها یا حتی صدها بسته استفاده کند.
پس میتوانید imageهای جدید را فقط برای تغییرات عمده — مثل image سرور مبدأ یا کد image builder — بهطور خودکار trigger کنید. سپس ساختهای زمانبندیشده — مثلاً هفتگی — پیادهسازی کنید تا همه بهروزرسانیهای عناصر مبدأ کوچکتر را جمع کنید.
همانطور که گفته شد، نتیجه مرحله ساخت image سروری است که میتوانید بهعنوان release candidate استفاده کنید. اگر میخواهید image را قبل از در دسترس قرار دادن تست کنید — برای هر use case غیرساده توصیه میشود — نباید image را در این نقطه برای استفاده علامت بزنید. میتوانید image را با شماره version طبق راهنمایی قبلی tag کنید. ممکن است هم tag کنید که نشان دهد release candidate تستنشده است؛ مثلاً Release_Status=Candidate.
مرحله تست برای image سرور
با تأکید بر تست در سراسر این کتاب، احتمالاً ارزش تست خودکار imageهای جدید هنگام ساخت آنها را میفهمید. معمولاً imageهای سرور را با همان ابزارهای تستی که برای تست کد سرور استفاده میکنند تست میکنند، همانطور که در «Testing Server Code» در صفحه ۱۷۶ توضیح داده شده.
اگر imageهای سرور را آنلاین میسازید («Online Image Building Process» در صفحه ۲۱۰)، میتوانید تستهای خودکار را روی نمونه سرور بعد از پیکربندی و قبل از خاموش کردن و تبدیل به image اجرا کنید. اما دو نگرانی وجود دارد. اول، تستهای شما ممکن است image را آلوده کند و فایلهای تست، ورودی log یا باقیمانده دیگر بهعنوان side effect تست بگذارد. حتی ممکن است حساب کاربری یا راههای دیگر دسترسی به سرورهای ساختهشده از image باقی بگذارند.
نگرانی دیگر تست نمونه سرور قبل از تبدیل به image این است که ممکن است بهطور قابلاطمینان نمونههای ساختهشده از image را replicate نکند. فرایند تبدیل نمونه به image ممکن است جنبههای مهم سرور را تغییر دهد، مثل مجوزهای دسترسی کاربر.
قابلاطمینانترین روش تست image سرور ایجاد و تست نمونه جدید از image نهایی است. عیب این کار زمان بیشتر برای دریافت feedback از تستهاست.
پس یک مرحله تست image سرور معمولی، همانطور که در شکل ۱۳-۷ نشان داده شده، شناسه image ساختهشده در مرحله ساخت را میگیرد، از آن برای ایجاد نمونه موقت استفاده میکند و تستهای خودکار را علیه آن اجرا میکند. اگر تستها pass شوند، مرحله image را tag میکند که نشان دهد برای مرحله بعد pipeline آماده است.
شکل ۱۳-۷. مرحله تست image سرور
مراحل تحویل برای image سرور
pipeline image تیم شما ممکن است مراحل اضافی برای فعالیتهای دیگر داشته باشد — مثلاً تست امنیتی. در نهایت، version image که مراحل تستش را pass کند بهعنوان آماده استفاده tag میشود.
در بعضی سیستمها، pipeline که image را میسازد مراحل rebuild سرورها با image جدید را هم شامل میشود (شکل ۱۳-۸ را ببینید). میتواند برای هر محیط تحویل در مسیر به production یک مرحله اجرا کند، شاید trigger کردن مراحل deploy و تست برنامه.
شکل ۱۳-۸. Pipeline که imageها را به محیطها تحویل میدهد
در سیستمهایی که تیمهای مختلف مسئول مدیریت زیرساخت و محیطها هستند، pipeline image ممکن است وقتی image را بهعنوان آماده استفاده علامت زد پایان یابد. pipelineهای تیمهای دیگر versionهای جدید image را بهعنوان ورودی میگیرند، همانطور که در «Providing and Using a Server Image Across Teams» در صفحه ۲۲۰ توضیح داده شده.
استفاده از چند image سرور
برخی تیمها فقط یک image سرور نگه میدارند. این تیمها انواع مختلف سرور مورد نیاز را با اعمال نقشهای پیکربندی سرور («Server Roles» در صفحه ۱۷۵) هنگام ایجاد نمونههای سرور میسازند. تیمهای دیگر اما نگهداری چند image سرور را مفید یا ضروری مییابند.
برای پشتیبانی از چند پلتفرم زیرساخت، چند معماری سختافزار سرور یا چند معماری سختافزار سرور به imageهای متعدد نیاز دارید. و چند image میتواند برای بهینهسازی زمان ایجاد سرور مفید باشد، با استراتژی baking بهجای frying («Baking Server Images» در صفحه ۱۸۷).
بیایید هر کدام از این سناریوها — پشتیبانی از چند پلتفرم و bake کردن نقشها در imageهای سرور — را بررسی کنیم و سپس استراتژیهای نگهداری چند image سرور را بحث کنیم.
imageهای سرور برای پلتفرمهای زیرساخت مختلف
سازمان شما ممکن است بیش از یک پلتفرم زیرساخت بهعنوان بخشی از استراتژی multi-cloud، poly-cloud یا hybrid cloud استفاده کند. باید imageهای سرور جدا برای هر کدام بسازید و نگه دارید.
اغلب میتوانید همان کد پیکربندی سرور را — شاید با تغییراتی که با پارامترها مدیریت میکنید — در همه پلتفرمها استفاده کنید. ممکن است با imageهای مبدأ مختلف در هر پلتفرم شروع کنید، اگرچه در بعضی موارد میتوانید از imageهای فروشنده OS یا شخص ثالث مورد اعتماد که برای هر کدام بهصورت سازگار میسازد استفاده کنید.
هر پلتفرم زیرساخت باید pipeline جدا برای ساخت، تست و تحویل versionهای جدید image داشته باشد. این pipelineها ممکن است کد پیکربندی سرور را بهعنوان ورودی بگیرند. مثلاً اگر پیکربندی سرور application serverها را بهروز کنید، تغییر را به هر pipeline پلتفرم push میکنید و image سرور جدید برای هر کدام میسازید و تست میکنید.
imageهای سرور برای سیستمعاملهای مختلف
اگر چند سیستمعامل یا توزیع — مثل Windows، Red Hat Linux و Ubuntu Linux — پشتیبانی میکنید، باید imageهای جدا برای هر OS نگه دارید. همچنین احتمالاً به image جدا برای هر نسخه major OS که سازمان شما استفاده میکند نیاز دارید. به image مبدأ جدا برای ساخت هر کدام از این imageهای OS نیاز دارید. ممکن است بتوانید کد پیکربندی سرور را در برخی از این imageهای OS reuse کنید.
اما در بسیاری موارد، نوشتن کد پیکربندی سرور برای مدیریت سیستمعاملهای مختلف پیچیدگی اضافه میکند که تست پیچیدهتری میخواهد. pipeline تست باید از نمونه سرور (یا کانتینر) برای هر تغییر استفاده کند. برای بعضی پیکربندیها سادهتر است ماژول کد پیکربندی جدا برای هر OS یا توزیع بنویسید.
imageهای سرور برای معماریهای سختافزاری مختلف
برخی سازمانها نمونه سرور را روی معماریهای CPU مختلف — مثل x86 و ARM — اجرا میکنند. اغلب میتوانید imageهای سرور تقریباً یکسان برای هر معماری با همان کد بسازید. بعضی برنامهها از ویژگیهای سختافزاری خاص بهره میبرند یا به تفاوتهای آنها حساسترند. در این موارد pipelineهای شما باید imageها را در معماریهای مختلف کاملتر تست کنند تا مسائل را تشخیص دهند.
imageهای سرور برای نقشهای مختلف
بسیاری تیمها از image سرور همهمنظوره استفاده میکنند و پیکربندی نقش («Server Roles» در صفحه ۱۷۵) هنگام ایجاد نمونههای سرور اعمال میکنند. اما وقتی پیکربندی سرور برای نقش شامل نصب نرمافزار زیاد — مثل application server — میشود، بهتر است پیکربندی نقش را در image اختصاصی bake کنید.
مثال قبلی در این فصل («Versioning a Server Image» در صفحه ۲۱۷) از imageهای سفارشی برای application server و nodeهای host کانتینر و image Linux همهمنظوره استفاده کرد. این مثال نشان میدهد لزوماً به image جدا برای هر نقش سرور نیاز ندارید.
برای تصمیم درباره ارزش نگهداری image جدا برای نقش خاص، زمان و هزینه داشتن pipeline، تست و فضای ذخیرهسازی را در نظر بگیرید و در برابر عیبهای پیکربندی نمونههای سرور هنگام ایجاد — سرعت، کارایی و وابستگیها — همانطور که در «Frying a Server Instance» در صفحه ۱۸۶ توضیح داده شده بسنجید.
لایهبندی imageهای سرور
تیمهایی که تعداد زیادی image سرور مبتنی بر نقش دارند ممکن است ساخت آنها را به لایهها در نظر بگیرند. مثلاً image پایه OS با بستهها و پیکربندیهای پیشفرضی که میخواهید روی همه سرورها نصب شود بسازید. سپس از این image بهعنوان image مبدأ برای ساخت imageهای نقشمحور خاصتر برای application server، nodeهای کانتینر و غیره استفاده کنید، همانطور که در شکل ۱۳-۹ نشان داده شده.
در این مثال، تیم ShopSpinner از image Linux پایه بهعنوان image مبدأ برای ساخت image application server و image host node کانتینر استفاده میکند. image application server Java و Tomcat از پیش نصب دارد. تیم از این image بهنوبه خود بهعنوان image مبدأ برای ساخت imageهایی با برنامههای خاص از پیش نصبشده استفاده میکند.
شکل ۱۳-۹. لایهبندی imageهای سرور
حاکمیت و imageهای سرور
رویکردهای سنتی حاکمیت اغلب شامل فرایند بررسی و تأیید دستی هر بار که image سرور جدید ساخته میشود هستند. همانطور که «Governance in a Pipeline-based Workflow» در صفحه ۳۵۲ توضیح میدهد، تعریف سرورها بهصورت کد و استفاده از pipeline برای تحویل تغییرات فرصتهایی برای رویکردهای قویتر ایجاد میکند.
بهجای بازرسی imageهای سرور جدید، افراد مسئول حاکمیت میتوانند کدی که آنها را میسازد بازرسی کنند. بهتر از آن، میتوانند با تیمهای زیرساخت و دیگران درگیر همکاری کنند تا بررسیهای خودکار بسازند که در pipeline اجرا شوند و انطباق را تضمین کنند. pipelineهای شما نهتنها میتوانند این بررسیها را هر بار که image جدید ساخته میشود اجرا کنند، بلکه میتوانند علیه نمونههای سرور جدید هم اجرا شوند تا مطمئن شوند اعمال کد پیکربندی سرور آن را «unharden» نکرده است.
برنامه خرید ShopSpinner و سرویس جستجو مکرراً برای مدیریت بار ترافیک متغیر در ساعات مختلف روز scale up و down میشوند. پس مفید است imageها bake و آماده باشند. تیم نمونههای سرور برای برنامهها و سرویسهای دیگر از image application server عمومیتر میسازد چون نمونههای آنها را بهندرت ایجاد میکند.
pipeline جدا هر image سرور را میسازد و وقتی image ورودی تغییر میکند trigger میشود. حلقههای feedback میتوانند خیلی طولانی باشند. وقتی تیم image Linux پایه را تغییر میدهد، pipeline آن کامل میشود و pipelineهای application server و host کانتینر را trigger میکند. pipeline image application server سپس pipelineهای ساخت versionهای جدید imageهای سرور مبتنی بر آن را trigger میکند. اگر هر pipeline ۱۰–۱۵ دقیقه طول بکشد، یعنی تا ۴۵ دقیقه طول میکشد تا تغییرات به همه imageها برسد.
جایگزین استفاده از استراتژی ساخت image کمعمقتر است.
اشتراکگذاری کد بین imageهای سرور
حتی با مدل مبتنی بر ارثبری که نقشهای سرور پیکربندی را از یکدیگر به ارث میبرند، لزوماً نیازی به ساخت imageها در مدل لایهای که توضیح دادیم ندارید. میتوانید در عوض کد پیکربندی سرور را در تعاریف نقش سرور لایهبندی کنید و همه کد را مستقیماً برای ساخت هر image از صفر اعمال کنید، همانطور که در شکل ۱۳-۱۰ نشان داده شده.
شکل ۱۳-۱۰. استفاده از اسکریپت برای لایهبندی نقشها روی imageهای سرور
این استراتژی همان مدل لایهای را پیادهسازی میکند. اما با ترکیب کد پیکربندی مرتبط برای هر نقش و اعمال همه آن یکجا. پس ساخت image application server از image سرور پایه بهعنوان image مبدأ استفاده نمیکند، بلکه همه کد استفادهشده برای image سرور پایه را روی image application server اعمال میکند.
ساخت image اینطور زمان ساخت imageها در پایین سلسلهمراتب را کاهش میدهد. pipeline که image سرویس جستجو را میسازد بلافاصله وقتی کسی تغییری در کد پیکربندی سرور Linux پایه میدهد اجرا میشود.
جمعبندی
میتوانید سرورها را بدون ساخت imageهای سفارشی بسازید و نگه دارید. اما ساخت و نگهداری سیستم خودکار برای ساخت imageهای سرور مزایایی دارد. این مزایا عمدتاً حول بهینهسازی است. میتوانید نمونههای سرور را سریعتر، با پهنای باند شبکه کمتر و وابستگیهای کمتر با pre-bake کردن بیشتر پیکربندی در imageهای سرور ایجاد کنید.
¹ برای اطلاعات بیشتر درباره سختسازی امنیتی، «Proactively Hardening Systems Against Intrusion: Configuration Hardening» در وبسایت Tripwire، «25 Hardening Security Tips for Linux Servers» و «20 Linux Server Hardening Security Tips» را ببینید.
² Netflix رویکرد خود برای ساخت و استفاده از AMI را در یک پست وبلاگ توضیح داد.
³ FCS همان Fictional Cloud Service است، مشابه AWS، Azure و دیگران ذکرشده در «Infrastructure Platforms» در صفحه ۲۵. FSI همان Fictional Server Image است، مشابه AWS AMI یا Azure Managed Image.
⁵ برخی installerهای OS اسکریپتشده شامل Red Hat Kickstart، Solaris JumpStart، Debian Preseed و فایل پاسخ نصب Windows هستند.