سلام به همه! نام من پاول آگالتسکی است. من به عنوان سرپرست تیم در تیمی کار می کنم که سیستم تحویل Lamoda را توسعه می دهد. در سال 2018، در کنفرانس HighLoad++ صحبت کردم و امروز می‌خواهم متن گزارش خود را ارائه کنم.

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

استقرار برنامه ها در VM

بیایید با این واقعیت شروع کنیم که 3 سال پیش تمام سیستم ها و خدمات این شرکت بر روی سرورهای مجازی معمولی مستقر شدند. از نظر فنی، به گونه ای سازماندهی شده بود که تمام کدهای سیستم های ما با استفاده از ابزارهای مونتاژ خودکار و با استفاده از جنکین ها ذخیره و مونتاژ می شد. با استفاده از Ansible، از سیستم کنترل نسخه ما به سرورهای مجازی منتقل شد. علاوه بر این، هر سیستمی که شرکت ما داشت حداقل بر روی 2 سرور مستقر شد: یکی از آنها روی سر، دومی در دم. این دو سیستم در تمام تنظیمات، قدرت، پیکربندی و غیره کاملاً با یکدیگر یکسان بودند. تنها تفاوت بین آنها این بود که head ترافیک کاربر را دریافت می کند، در حالی که tail هرگز ترافیک کاربر را دریافت نمی کند.

این برای چه بود؟

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

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

چه مزیت هایی در این همه دیدیم؟

1. اول از همه کافی است فقط کار می کند همه می دانند که چگونه چنین طرح استقراری کار می کند، زیرا اکثر مردم تا کنون در سرورهای مجازی معمولی مستقر شده اند.
2. این کافی است بطرزی قابل اعتماد، از آنجایی که فناوری استقرار ساده است، توسط هزاران شرکت آزمایش شده است. میلیون ها سرور از این طریق مستقر شده اند. شکستن چیزی سخت است.
3. و بالاخره توانستیم به دست بیاوریم استقرارهای اتمی. استقرارهایی که به طور همزمان برای کاربران اتفاق می‌افتد، بدون اینکه مرحله قابل توجهی از جابجایی بین نسخه قدیمی و جدید وجود داشته باشد.

اما در تمام این موارد کاستی های متعددی نیز دیدیم:

1. علاوه بر محیط تولید، محیط توسعه، محیط های دیگری نیز وجود دارد. مثلا ق و پیش تولید. در آن زمان ما سرورهای زیادی و حدود 60 سرویس داشتیم. به همین دلیل لازم بود برای هر سرویس، آخرین نسخه را برای آن نگهداری کنید ماشین مجازی. علاوه بر این، اگر می خواهید کتابخانه ها را به روز کنید یا وابستگی های جدید نصب کنید، باید این کار را در همه محیط ها انجام دهید. همچنین لازم بود زمانی که می‌خواهید نسخه جدید بعدی برنامه خود را اجرا کنید، با زمانی که devops تنظیمات لازم محیط را انجام می‌دهد، همگام‌سازی کنید. در این صورت به راحتی می توان وارد شرایطی شد که محیط ما در همه محیط ها به یکباره تا حدودی متفاوت باشد. به عنوان مثال، در یک محیط QA نسخه هایی از کتابخانه ها وجود خواهد داشت و در یک محیط تولیدی نسخه های مختلفی وجود خواهد داشت که منجر به مشکلاتی می شود.
2. مشکل در به روز رسانی وابستگی ها درخواست شما این به شما بستگی ندارد، بلکه به تیم دیگر بستگی دارد. یعنی از تیم devops که سرورها را نگهداری می کند. شما باید به آنها یک وظیفه مناسب و شرح کاری که می خواهید انجام دهید بدهید.
3. در آن زمان، ما همچنین می خواستیم یکپارچه های بزرگ بزرگی را که در اختیار داشتیم به سرویس های کوچک جداگانه تقسیم کنیم، زیرا می فهمیدیم که تعداد آنها بیشتر و بیشتر خواهد شد. در آن زمان ما بیش از 100 عدد از آنها را داشتیم، برای هر سرویس جدید، نیاز به ایجاد یک ماشین مجازی جدید جداگانه بود که همچنین نیاز به نگهداری و استقرار داشت. علاوه بر این، شما نه یک ماشین، بلکه حداقل دو ماشین نیاز دارید. به همه اینها محیط QA اضافه شده است. این باعث ایجاد مشکلاتی می شود و ساخت و اجرای سیستم های جدید را برای شما دشوارتر می کند. فرآیند پیچیده، پرهزینه و طولانی

بنابراین، ما تصمیم گرفتیم که راحت‌تر از استقرار ماشین‌های مجازی معمولی به استقرار برنامه‌هایمان در یک کانتینر داکر برویم. اگر داکر دارید، به سیستمی نیاز دارید که بتواند برنامه را در یک کلاستر اجرا کند، زیرا نمی توانید فقط یک ظرف را بالا بیاورید. معمولاً می خواهید تعداد کانتینرهایی که بلند شده اند را پیگیری کنید تا به طور خودکار بلند شوند. به همین دلیل، ما نیاز به انتخاب یک سیستم کنترل داشتیم.

مدت زیادی فکر کردیم که کدام یک را می توانیم انتخاب کنیم. واقعیت این است که در آن زمان این پشته استقرار در سرورهای مجازی معمولی تا حدودی منسوخ شده بود، زیرا آنها آخرین نسخه های سیستم عامل را نداشتند. در برخی موارد، حتی FreeBSD وجود داشت که پشتیبانی از آن چندان راحت نبود. ما فهمیدیم که باید در اسرع وقت به داکر مهاجرت کنیم. توسعه دهندگان ما به تجربه موجود خود با راه حل های مختلف نگاه کردند و سیستمی مانند Nomad را انتخاب کردند.

به Nomad بروید

Nomad محصول شرکت HashiCorp است. آنها همچنین برای راه حل های دیگر خود شناخته شده اند:

"کنسول" ابزاری برای کشف خدمات است.

"ترافورم" - سیستمی برای مدیریت سرورها که به شما امکان می دهد آنها را از طریق پیکربندی، به اصطلاح زیرساخت به عنوان کد، پیکربندی کنید.

"ولگرد" به شما امکان می دهد ماشین های مجازی را به صورت محلی یا در فضای ابری از طریق فایل های پیکربندی خاص مستقر کنید.

Nomad در آن زمان یک راه حل نسبتاً ساده به نظر می رسید که می توان به سرعت بدون تغییر کل زیرساخت به آن تغییر داد. علاوه بر این، یادگیری آن بسیار آسان است. به همین دلیل آن را به عنوان سیستم فیلتراسیون ظرف خود انتخاب کردیم.

برای استقرار سیستم خود در Nomad به چه چیزی نیاز دارید؟

1. اول از همه شما نیاز دارید تصویر داکر درخواست شما شما باید آن را بسازید و در مخزن تصویر docker قرار دهید. در مورد ما، این یک مصنوع است - سیستمی که به شما امکان می دهد مصنوعات مختلف از انواع مختلف را درون آن فشار دهید. این می تواند آرشیوها، تصاویر داکر، بسته های PHP آهنگساز، بسته های NPM و غیره را ذخیره کند.
2. همچنین مورد نیاز است فایل پیکربندی، که به Nomad می گوید که چه چیزی، کجا و در چه مقداری می خواهید مستقر کنید.

وقتی در مورد Nomad صحبت می کنیم، از زبان HCL به عنوان فرمت فایل اطلاعاتی خود استفاده می کند که مخفف آن است زبان پیکربندی HashiCorp. این مجموعه ای از Yaml است که به شما امکان می دهد خدمات خود را در اصطلاح Nomad توصیف کنید.

این به شما امکان می‌دهد بگویید چند کانتینر را می‌خواهید مستقر کنید، از کدام تصاویر می‌توانید پارامترهای مختلف را در حین استقرار به آنها ارسال کنید. بنابراین، شما این فایل را به Nomad می‌دهید و طبق آن، کانتینرها را وارد تولید می‌کنید.

در مورد ما، متوجه شدیم که نوشتن فایل‌های HCL کاملاً یکسان برای هر سرویس چندان راحت نخواهد بود، زیرا خدمات زیادی وجود دارد و گاهی اوقات می‌خواهید آنها را به‌روزرسانی کنید. این اتفاق می افتد که یک سرویس نه در یک نمونه، بلکه در انواع مختلف مستقر می شود. به عنوان مثال یکی از سیستم هایی که ما در تولید داریم بیش از 100 نمونه در تولید دارد. آنها از تصاویر یکسان اجرا می شوند، اما در تنظیمات پیکربندی و فایل های پیکربندی متفاوت هستند.

بنابراین، ما تصمیم گرفتیم که برای ما راحت باشد که تمام فایل های پیکربندی خود را برای استقرار در یک مخزن مشترک ذخیره کنیم. به این ترتیب آنها قابل مشاهده بودند: نگهداری از آنها آسان بود و ما می توانستیم ببینیم چه سیستم هایی داریم. در صورت لزوم، به روز رسانی یا تغییر چیزی نیز آسان است. افزودن یک سیستم جدید نیز دشوار نیست - فقط باید یک فایل پیکربندی در دایرکتوری جدید ایجاد کنید. در داخل آن فایل‌های زیر وجود دارد: service.hcl، که حاوی توضیحاتی از سرویس ما است، و برخی از فایل‌های env که اجازه می‌دهند این سرویس، که در تولید مستقر است، پیکربندی شود.

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

علاوه بر این، ما یک اسکریپت استقرار مشترک برای همه پروژه‌ها را در مخزن قرار داده‌ایم که به شما امکان می‌دهد سرویس خود را به تولید، در محیط مورد نظر، در هدف مورد نظر راه‌اندازی و اجرا کنید. در موردی که پیکربندی HCL خود را به یک الگو تبدیل کردیم، سپس فایل HCL که قبلاً یک پیکربندی معمولی Nomad بود، در این مورد کمی متفاوت به نظر می رسید.

یعنی برخی از متغیرهای مکان پیکربندی را با متغیرهای درج شده جایگزین کردیم که از فایل‌های env یا منابع دیگر گرفته شده‌اند. علاوه بر این، ما این فرصت را به دست آوردیم که فایل های HCL را به صورت پویا جمع آوری کنیم، یعنی می توانیم نه تنها از درج های متغیر معمولی استفاده کنیم. از آنجایی که jinja از حلقه‌ها و شرایط پشتیبانی می‌کند، می‌توانید فایل‌های پیکربندی را نیز در آنجا ایجاد کنید، که بسته به اینکه دقیقاً کجا برنامه‌های خود را اجرا می‌کنید، تغییر می‌کنند.

به عنوان مثال، شما می خواهید سرویس خود را در پیش تولید و تولید مستقر کنید. فرض کنید در مرحله پیش تولید نمی خواهید اسکریپت های cron را اجرا کنید، بلکه فقط می خواهید سرویس را در یک دامنه جداگانه ببینید تا مطمئن شوید که کار می کند. برای هر کسی که این سرویس را مستقر می کند، این روند بسیار ساده و شفاف به نظر می رسد. تنها کاری که باید انجام دهید این است که فایل deploy.sh را اجرا کنید، مشخص کنید که کدام سرویس را می خواهید مستقر کنید و به کدام هدف. به عنوان مثال، شما می خواهید یک سیستم خاص را در روسیه، بلاروس یا قزاقستان مستقر کنید. برای این کار کافی است یکی از پارامترها را تغییر دهید و فایل پیکربندی صحیح را خواهید داشت.

هنگامی که سرویس Nomad قبلاً در کلاستر شما مستقر شده است، به نظر می رسد.

ابتدا به نوعی متعادل کننده در خارج نیاز دارید که تمام ترافیک کاربر را دریافت کند. این سرویس با کنسول کار می کند و از آن می یابد که یک سرویس خاص که مربوط به یک نام دامنه خاص است، در کجا، در چه گرهی، در چه آدرس IP قرار دارد. خدمات در Consul از خود Nomad ارائه می شود. از آنجایی که اینها محصولات یک شرکت هستند، کاملاً به یکدیگر مرتبط هستند. می توان گفت Nomad خارج از جعبه می تواند تمام خدمات راه اندازی شده در آن را در داخل کنسول ثبت کند.

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

این انتقال از نظر منابع انسانی چقدر برای ما هزینه داشت؟

انتقال کل شرکت به Nomad تقریباً 5-6 ماه طول کشید. ما به صورت سرویس به سرویس حرکت کردیم، اما با سرعت نسبتاً سریع. هر تیم باید کانتینرهای مخصوص به خود را برای خدمات ایجاد می کرد.

ما چنین رویکردی را اتخاذ کرده ایم که هر تیم به طور مستقل مسئول تصاویر داکر سیستم های خود است. DevOps زیرساخت کلی لازم برای استقرار را فراهم می کند، یعنی پشتیبانی از خود خوشه، پشتیبانی از سیستم CI و غیره. و در آن زمان بیش از 60 سامانه جابجا شده به نومد داشتیم که حدود 2 هزار کانتینر بود.

Devops مسئول زیرساخت کلی همه چیز مربوط به استقرار و سرورها است. و هر تیم توسعه به نوبه خود مسئول پیاده سازی کانتینرها برای سیستم خاص خود است، زیرا این تیم است که می داند به طور کلی در یک کانتینر به چه چیزی نیاز دارد.

دلایل ترک Nomad

با تغییر به استقرار با استفاده از Nomad و docker و سایر موارد چه مزایایی به دست آوردیم؟

1. ما شرایط مساوی را فراهم کرد برای همه محیط ها در توسعه، محیط QA، پیش تولید، تولید، تصاویر ظرف یکسان، با همان وابستگی ها استفاده می شود. بر این اساس، شما عملاً هیچ شانسی ندارید که آنچه در نهایت به تولید می رسد، همان چیزی نباشد که قبلاً به صورت محلی یا در محیط آزمایشی خود آزمایش کرده اید.
2. ما هم متوجه شدیم که کافی است آسان برای اضافه کردن یک سرویس جدید. از نقطه نظر استقرار، هر سیستم جدید بسیار ساده راه اندازی می شود. کافیست به مخزنی که تنظیمات را ذخیره می کند بروید، پیکربندی دیگری را برای سیستم خود در آنجا اضافه کنید، و همه چیز آماده است. شما می توانید سیستم خود را بدون هیچ گونه تلاش اضافی از طرف devops برای تولید مستقر کنید.
3. همه فایل های پیکربندی در یک مخزن مشترک معلوم شد در دست بررسی است. در زمانی که سیستم‌های خود را با استفاده از سرورهای مجازی مستقر می‌کردیم، از Ansible استفاده می‌کردیم که در آن تنظیمات در یک مخزن قرار داشتند. با این حال، برای اکثر توسعه دهندگان کار با این کار کمی دشوارتر بود. در اینجا حجم تنظیمات و کدهایی که برای استقرار سرویس باید اضافه کنید بسیار کمتر شده است. به علاوه، تعمیر یا تغییر آن برای توسعه دهندگان بسیار آسان است. در صورت انتقال، به عنوان مثال، به نسخه جدید Nomad، آنها می توانند تمام فایل های عامل واقع در همان مکان را برداشته و انبوه به روز کنند.

اما ما با چندین معایب نیز مواجه شدیم:

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

با برخی برخورد کردیم توسط باتلاق ها. مهم ترین اشکال این است که Nomad اگر سیستم ها و کانتینرهای زیادی دارید، به خوبی با یک خوشه بزرگ مدیریت نمی کند. وقتی می خواهید یکی از سرورهایی را که در کلاستر Nomad قرار دارد را برای نگهداری خارج کنید، احتمال نسبتاً زیادی وجود دارد که خوشه احساس خوبی نداشته باشد و از هم بپاشد. برای مثال ممکن است برخی از کانتینرها سقوط کنند و بلند نشوند - اگر همه سیستم‌های تولید شما در یک خوشه تحت مدیریت Nomad قرار داشته باشند، بعداً هزینه زیادی برای شما خواهد داشت.

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

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

انتقال به Kubernetes

من کمی در مورد مفاهیم اولیه Kubernetes و تفاوت آنها با Nomad به شما خواهم گفت.

اول از همه، اساسی ترین مفهوم در Kubernetes، مفهوم pod است. غلاف گروهی از یک یا چند کانتینر است که همیشه با هم کار می کنند. و همیشه طوری کار می کنند که گویی دقیقاً روی یک ماشین مجازی کار می کنند. آنها از طریق IP 127.0.0.1 در پورت های مختلف به یکدیگر دسترسی دارند.

بیایید فرض کنیم که شما یک برنامه PHP دارید که از nginx و php-fpm تشکیل شده است - طرح کلاسیک. به احتمال زیاد، شما می خواهید هر دو کانتینر nginx و php-fpm را همیشه در کنار هم نگه دارید. Kubernetes به شما اجازه می دهد تا با توصیف آنها به عنوان یک غلاف مشترک به این هدف دست یابید. این دقیقاً همان چیزی است که ما نتوانستیم با Nomad بدست آوریم.

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

مفهوم سوم این است سرویس. سرویس شما در واقع سیستم شماست که مقداری ترافیک دریافت می کند و سپس آن را به یک یا چند پاد مربوط به سرویس شما ارسال می کند. یعنی به شما این امکان را می دهد که بگویید تمام ترافیک ورودی به فلان سرویس با فلان نام باید به این پادهای خاص ارسال شود. و در عین حال تعادل ترافیک را برای شما فراهم می کند. یعنی می توانید دو پاد از اپلیکیشن خود را راه اندازی کنید و تمامی ترافیک ورودی به طور یکنواخت بین پادهای مربوط به این سرویس متعادل می شود.

و چهارمین مفهوم اساسی این است ورود. این سرویسی است که بر روی یک خوشه Kubernetes اجرا می شود. این به عنوان یک متعادل کننده بار خارجی عمل می کند که تمام درخواست ها را بر عهده می گیرد. با استفاده از Kubernetes API، Ingress می تواند تعیین کند که این درخواست ها باید کجا ارسال شوند. علاوه بر این، او این کار را بسیار انعطاف پذیر انجام می دهد. می توان گفت تمام درخواست های این هاست و آدرس فلان به این سرویس ارسال می شود. و این درخواست هایی که به این هاست و به URL دیگری می آیند به سرویس دیگری ارسال می شوند.

جالب ترین چیز از دیدگاه شخصی که یک برنامه را توسعه می دهد این است که شما می توانید همه آن را خودتان مدیریت کنید. با تنظیم پیکربندی Ingress، می‌توانید تمام ترافیکی که به فلان API وارد می‌شود را به کانتینرهای جداگانه‌ای که مثلاً در Go نوشته شده‌اند، ارسال کنید. اما این ترافیک که به یک دامنه می آید، اما به یک URL متفاوت، باید به کانتینرهایی که با PHP نوشته شده اند ارسال شود، جایی که منطق زیادی وجود دارد، اما سرعت آنها زیاد نیست.

اگر همه این مفاهیم را با Nomad مقایسه کنیم، می توان گفت که سه مفهوم اول همه با هم Service هستند. و آخرین مفهوم در خود Nomad وجود ندارد. ما از یک متعادل کننده خارجی به عنوان آن استفاده کردیم: می تواند هاپروکسی، nginx، nginx+ و غیره باشد. در مورد مکعب، لازم نیست این مفهوم اضافی را جداگانه معرفی کنید. با این حال، اگر به درون Ingress نگاه کنید، یا nginx، هاپروکسی یا traefik است، اما به نوعی در Kubernetes تعبیه شده است.

تمام مفاهیمی که توضیح دادم، در واقع منابعی هستند که در یک خوشه Kubernetes وجود دارند. برای توصیف آنها در مکعب از فرمت yaml استفاده شده است که در مورد Nomad از فایل های HCL خوانا و آشناتر است. اما از نظر ساختاری همان چیزی را در مورد مثلاً pod توصیف می کنند. آنها می گویند - من می خواهم فلان غلاف را در آنجا مستقر کنم، با عکس های فلان، به فلان مقدار.

علاوه بر این، متوجه شدیم که نمی‌خواهیم هر منبع فردی را با دست ایجاد کنیم: استقرار، خدمات، Ingress و غیره. در عوض، ما می‌خواستیم هر یک از سیستم‌های خود را بر حسب Kubernetes در حین استقرار توصیف کنیم، به طوری که مجبور نباشیم به صورت دستی همه وابستگی‌های منابع لازم را به ترتیب درست بازسازی کنیم. Helm به عنوان سیستمی انتخاب شد که به ما اجازه انجام این کار را داد.

مفاهیم اساسی در Helm

هلم است مدیر بسته برای Kubernetes این بسیار شبیه به نحوه کار مدیران بسته در زبان های برنامه نویسی است. آنها به شما این امکان را می دهند که سرویسی متشکل از، به عنوان مثال، استقرار nginx، استقرار php-fpm، پیکربندی برای Ingress، configmaps (این موجودی است که به شما امکان می دهد env و پارامترهای دیگر را برای سیستم خود تنظیم کنید) را به شکل زیر ذخیره کنید. نمودار نامیده می شود. در عین حال هلم در بالای Kubernetes اجرا می شود. یعنی این سیستمی نیست که کنار گذاشته شود، بلکه فقط سرویس دیگری است که در داخل مکعب راه اندازی شده است. شما از طریق API آن از طریق یک فرمان کنسول با آن تعامل دارید. راحتی و زیبایی آن این است که حتی اگر فرمان شکسته شود یا آن را از خوشه حذف کنید، خدمات شما ناپدید نمی شوند، زیرا فرمان اساساً فقط برای راه اندازی سیستم عمل می کند. سپس خود Kubernetes مسئول عملکرد و وضعیت خدمات است.

ما هم متوجه شدیم قالب سازیکه قبلاً مجبور بودیم خودمان با وارد کردن jinja در تنظیمات خود انجام دهیم، یکی از ویژگی های اصلی هل است. تمام تنظیماتی که برای سیستم‌های خود ایجاد می‌کنید در قالب به شکل قالب‌ها ذخیره می‌شوند، کمی شبیه به jinja، اما در واقع با استفاده از قالب زبان Go که در آن helm نوشته شده است، مانند Kubernetes.

هلم چند مفهوم دیگر را برای ما اضافه می کند.

چارت سازمانی - این شرح خدمات شما است. در سایر مدیران بسته به آن بسته، بسته یا چیزی مشابه می‌گویند. در اینجا نمودار نامیده می شود.

ارزش‌ها متغیرهایی هستند که می خواهید برای ساختن تنظیمات خود از قالب ها استفاده کنید.

آزاد. هر بار که سرویسی که با استفاده از فرمان مستقر می شود، نسخه افزایشی انتشار را دریافت می کند. Helm به یاد می آورد که پیکربندی سرویس در نسخه قبلی، نسخه قبل از آن و غیره چه بود. بنابراین، در صورت نیاز به بازگشت، کافیست فرمان فرمان callback را اجرا کنید و آن را به نسخه قبلی اشاره کنید. حتی اگر پیکربندی مربوطه در مخزن شما در زمان بازگشت در دسترس نباشد، helm همچنان آنچه بوده را به خاطر می‌آورد و سیستم شما را به حالتی که در نسخه قبلی بود برمی‌گرداند.

در مواردی که از helm استفاده می کنیم، تنظیمات منظم برای Kubernetes نیز به قالب هایی تبدیل می شوند که در آنها می توان از متغیرها، توابع و اعمال دستورات شرطی استفاده کرد. به این ترتیب می توانید پیکربندی سرویس خود را بسته به محیط جمع آوری کنید.

در عمل تصمیم گرفتیم کارها را کمی متفاوت از Nomad انجام دهیم. اگر در Nomad هر دو پیکربندی استقرار و n متغیری که برای استقرار سرویس ما نیاز بود در یک مخزن ذخیره می شدند، در اینجا تصمیم گرفتیم آنها را به دو مخزن جداگانه تقسیم کنیم. مخزن "deploy" فقط n متغیر مورد نیاز برای استقرار را ذخیره می کند و مخزن "helm" پیکربندی ها یا نمودارها را ذخیره می کند.

این چه چیزی به ما داد؟

با وجود این واقعیت که ما هیچ داده واقعا حساسی را در خود فایل های پیکربندی ذخیره نمی کنیم. به عنوان مثال، پسوردهای پایگاه داده. آنها به عنوان اسرار در Kubernetes ذخیره می شوند، اما با این وجود، هنوز چیزهای خاصی وجود دارد که ما نمی خواهیم به همه اجازه دسترسی به آنها را بدهیم. بنابراین، دسترسی به مخزن "deploy" محدودتر است و مخزن "helm" به سادگی حاوی توضیحاتی از سرویس است. به همین دلیل، طیف وسیع تری از افراد می توانند با خیال راحت به آن دسترسی داشته باشند.

از آنجایی که ما نه تنها تولید، بلکه سایر محیط‌ها را نیز داریم، به لطف این جداسازی، می‌توانیم از نمودارهای فرمان خود برای استقرار خدمات نه تنها در تولید، بلکه برای مثال در محیط QA نیز استفاده کنیم. حتی برای استقرار آنها به صورت محلی با استفاده از مینی کوب - این برای اجرای محلی Kubernetes است.

در داخل هر مخزن، ما یک بخش را به دایرکتوری های جداگانه برای هر سرویس گذاشتیم. یعنی در داخل هر دایرکتوری الگوهایی وجود دارد که مربوط به نمودار مربوطه است و منابعی را که باید برای راه‌اندازی سیستم ما مستقر شوند، شرح می‌دهند. ما فقط env ها را در مخزن "deploy" گذاشتیم. در این مورد، ما از قالب با استفاده از jinja استفاده نکردیم، زیرا خود helm قالب را خارج از جعبه ارائه می دهد - این یکی از عملکردهای اصلی آن است.

ما یک اسکریپت استقرار - deploy.sh را گذاشتیم که راه‌اندازی را برای استقرار با استفاده از helm ساده و استاندارد می‌کند. بنابراین، برای هر کسی که می‌خواهد استقرار کند، رابط استقرار دقیقاً همان چیزی است که هنگام استقرار از طریق Nomad انجام می‌شود. همان deploy.sh، نام سرویس شما و جایی که می خواهید آن را مستقر کنید. این باعث می شود که هل به صورت داخلی راه اندازی شود. به نوبه خود، پیکربندی‌ها را از قالب‌ها جمع‌آوری می‌کند، فایل‌های مقادیر لازم را در آنها وارد می‌کند، سپس آنها را مستقر می‌کند و آنها را در Kubernetes راه‌اندازی می‌کند.

یافته ها

به نظر می رسد سرویس Kubernetes پیچیده تر از Nomad باشد.

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

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

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

اولین استقرار ما در Kubernetes در مارس 2018 بود. و در این مدت هیچ مشکلی با آن تجربه نکردیم. کاملاً پایدار و بدون اشکالات قابل توجه کار می کند. علاوه بر این، ما می توانیم آن را بیشتر گسترش دهیم. امروز ما به اندازه کافی از قابلیت های آن برخورداریم و سرعت توسعه Kubernetes را واقعا دوست داریم. در حال حاضر بیش از 3000 کانتینر در Kubernetes هستند. این خوشه چندین گره را اشغال می کند. در عین حال، قابل سرویس، پایدار و بسیار قابل کنترل است.

منبع: www.habr.com