سیس ادمین سادهی ساده
چرا کوبرنتیز این شکلی طراحی شده؟ - قسمت سوم
مقدمه
در این سری نوشتهها قصد داریم ببینیم اصول طراحی کوبرنتیز چی هستن. در قسمت اول و دوم دو تا اصل رو بررسی کردیم و حالا وقتشه بریم سراغ سومی. در این قسمت ابتدا یکی از ویژگیهای ایدهآل یک نرمافزار رو معرفی میکنیم و بعد بحث میکنیم چجوری با کوبرنتیز میشه این ویژگی رو پیاده کرد. جا داره دوباره اشاره کنم این مطالب از یک ارائه در kubecon 2018 گرفته شدن.
اگه در حوزهی زیرساخت هستید و با کوبرنتیز کار میکنید این نوشته میتونه به شما دید خوبی بده تا علاوه بر ساختار کوبرنتیز علتش رو هم بدونید و عمیقتر با کوبرنتیز آشنا بشید. تو این نوشته فرض شده شما با کوبرنتیز آشنایی ابتدایی دارید. اگر هم تجربهی عملی داشته باشید که چه بهتر.
متدولوژی Twelve-Factor App در نوشتن نرمافزار
قبل از رسیدن به اصل سوم بذارید یه کم مقدمهچینی کنم. احتمالا در مورد متدولوژی Twelve-Factor App یا ۱۲ فاکتور شنیدید. در این متدولوژی ۱۲ ویژگی ایدهآل برای نرمافزار شمرده شده که با رعایت اونها میتونیم فرایند بهتری برای توسعهی نرمافزار داشته باشیم. یکی از ویژگیهای شمرده شده در این متدولوژی این هست که کانفیگ نرمافزار باید در محیطی که دیپلوی میشه باشه نه داخل کد به شکل هاردکد شده. منظور از کانفیگ هر چیزی هست که بین محیطهای مختلف (مثل staging و production) عوض میشه؛ مثلا یک نرمافزار موقع اجرا میخواد بدونه برای اتصال به دیتابیس باید به چه آدرسی وصل بشه. برای دادن چنین چیزی نباید اون رو داخل کد قرار بدیم. بلکه باید از یک فایل یا متغیر محیطی بخونیم. در این لینک میتونید بیشتر در موردش بخونید.
حالا که در مورد این ویژگی حرف زدیم، باید ببینیم آیا کوبرنتیز چنین امکانی به ما میده؟ و اگر جواب مثبته چطوری؟
معرفی ConfigMap و Secret
دو تا از آبجکتهایی که در کوبرنتیز میشه ساخت و داخل اونها کانفیگهای نرمافزار رو قرار داد، ConfigMap و Secret هستن. یه نمونه از هر کدوم رو ببینیم. اولی یک ConfigMap هست:
و دومی Secret:
در ConfigMap تنظیمات غیرحساس رو میذارن. مثلا اینجا اطلاعات اتصال به دیتابیس گذاشته شدهان و در نیماسپیس staging هست. در مورد Secret باید توجه کنیم که اطلاعات فقط base64 میشن و عملا به شکل مستقیم در دسترس هستن. توی این مثال نام کاربر و رمز دیتابیس رو گذاشتم. میشه دسترسی به Secretها رو در کلاستر محدود کرد یا از روشهای امنتری برای نگهداری Secret استفاده کرد که بحث ما اینجا نیست. هدف اینه که این دو تا آبجکت رو بشناسیم.
خب حالا اینها رو در یه فایل میذاریم و با زدن این دو دستور آبجکتها رو میسازیم:
kubectl apply -f secret.yaml
kubectl apply -f configmap.yaml
چجوری در نرمافزار استفادهاش کنیم؟ یک راهی که به ذهن میرسه این هست که خود برنامه بیاد به API Server درخواست بده و این آبجکتها رو بخونه. اما این کار اصلا خوب نیست چون نمیخوایم برنامه وابسته به زیرساختی که توش هست باشه؛ چون ممکنه من بخوام توی سیستم خودم برای تست با داکر اجراش کنم. اونجا دیگه API Serverی در کار نیست. علاوه بر این، برای این کار باید کد رو تغییر بدیم تا از API Server کانفیگ رو بخونه که باعث میشه هزینهی زمانی بیشتری برای استفاده از کوبرنتیز بدیم. پس این کار رو نمیکنیم. اینجاست که به اصل سوم میرسیم؛ یعنی قابلیت جابجایی کاربر در محیطهای مختلف.
اصل سوم: قابلیت جابجایی در محیطهای مختلف
نمیدونم ترجمهی خوبی هست یا نه ولی در ارائه این اصل رو
"meet the users where they are"
عنوان کرده. منظورش اینه که ما کافیه ویژگی گفته شده در متدولوژی ۱۲ فاکتور رو رعایت کنیم و کانفیگ رو از محیط (فایل یا متغیر محیطی) بگیریم. وقتی از روی کد ما ایمیج ساخته ميشه و در تعریف پاد میاریمش، همونجا میتونیم این فایلهای کانفیگ یا متغیرهای محیطی رو تعیین کنیم. مثلا فرض کنید برنامهای که نوشتم از مسیر
/app/config/.env
اطلاعات دیتابیس به غیر از نام کاربر و رمز رو میخونه. میتونم پادم رو این شکلی تعریف کنم و از ConfigMap ساخته شده در قسمت قبل استفاده کنم:
اینجا قصد آموزش ندارم. فقط خلاصه بگم که یک volume تعریف کردم که از ConfigMap استفاده میکنه و در کانتینر مربوطه فایل رو در مسیر مناسب قرار دادم. به شکل مشابه میشه از Secret هم استفاده کرد.
راههای دیگهای برای دادن کانفیگ به پاد هست که بهش نمیپردازیم. هدفم این بود که ببینیم کوبرنتیز چنین قابلیتهایی داره.
با توجه به این اصل کوبرنتیز من میتونم ایمیجی که ساختم و تعریف پاد متناظرش رو به راحتی بین کلاستر یا نیماسپیسهای مختلف جابجا کنم. تنها چیزی که بین محیطها تغییر میکنه اون ConfigMap یا Secret هست که رفتار نرمافزار رو متناسب با محیط تغییر میده. مثلا در تعریفشون نیماسپیس رو به جای staging میذاریم production و مقادیر رو به شکل مناسب تغییر میدیم. این شکلی میشه ازشون در پادهای production استفاده کرد. علاوه بر این برنامه هیچ اطلاعی نخواهد داشت که روی کوبرنتیز هست یا نه.
جمعبندی
در این مطلب ابتدا در مورد متدولوژی ۱۲ فاکتور صحبت کردیم و یکی از ویژگیهای مهمی که نرمافزارها باید داشته باشن (گرفتن کانفیگ از محیط) رو بررسی کردیم. در ادامه دیدیم چجوری میشه از قابلیتهای کوبرنتیز استفاده کرد تا بشه نرمافزاری رو که این ویژگی رو داره در محیطهای مختلف دیپلوی کنیم. به این شکل دیگه لازم نیست کد رو تغییر بدیم و میشه به راحتی کانفیگ نرمافزار رو در جای مناسب قرار داد. بدون این که نرمافزار بدونه در کوبرنتیز اجرا میشه.
امیدوارم این مطلب براتون مفید بوده باشه. اگر سوال یا نظری دارید این پایین بنویسید.
مطلبی دیگر از این انتشارات
داکر برای برنامهنویسها: قسمت سوم - دستورات ابتدایی در داکر
مطلبی دیگر از این انتشارات
لینوکسی بشیم: تغییر محتویات فایل
مطلبی دیگر از این انتشارات
لینوکسی بشیم: کنترل خروجی و ورودی دستورها در شل