پرتاب تاریک در ایستیو: خدمات مخفی

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

و Istio، همراه با OpenShift و Kubernetes، استقرار میکروسرویس ها را واقعا خسته کننده و قابل پیش بینی می کند - و این عالی است. در پست چهارم و آخر سری ایستیو در این مورد و خیلی بیشتر صحبت خواهیم کرد.

وقتی کسالت درست است

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

هنگام استقرار یک نسخه جدید از نرم افزار خود، ارزش آن را دارد که همه گزینه ها را برای به حداقل رساندن خطرات در نظر بگیرید. اجرای موازی یک روش بسیار قدرتمند و اثبات شده برای آزمایش است و ایستیو به شما امکان می دهد از یک "سرویس مخفی" (نسخه مخفی میکروسرویس خود) برای انجام این کار بدون تداخل با سیستم تولید استفاده کنید. حتی یک اصطلاح ویژه برای این وجود دارد - "Dark Launch" که به نوبه خود توسط عملکردی با نام جاسوسی "آینه سازی ترافیک" فعال می شود.

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

سازماندهی بی حوصلگی جالب است

به قانون مسیریابی Istio زیر نگاهی بیندازید، که تمام درخواست‌های HTTP را به توصیه microservice v1 هدایت می‌کند (همه نمونه‌ها از Istio Tutorial مخزن GitHub، در حالی که به طور همزمان آنها را به میکروسرویس توصیه v2 منعکس می کنید:

به برچسب توجه کنید mirror: در پایین صفحه - این است که آینه سازی ترافیک را تنظیم می کند. بله، به همین سادگی است!

نتیجه این قانون این خواهد بود که سیستم تولید شما (v1) به پردازش درخواست‌های دریافتی ادامه می‌دهد، اما خود درخواست‌ها به صورت ناهمزمان به v2 منعکس می‌شوند، یعنی نسخه‌های تکراری کامل آنها به آنجا می‌رود. به این ترتیب می توانید v2 را در شرایط واقعی - روی داده ها و ترافیک واقعی - بدون دخالت در عملکرد سیستم تولید آزمایش کنید. آیا این سازماندهی آزمون را خسته کننده می کند؟ بله قطعا. اما به روش جالبی انجام شده است.

بیایید درام را اضافه کنیم

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

یک نکته مهم را تکرار می کنیم

راه‌اندازی مخفی با آینه‌سازی ترافیک (راه‌اندازی تاریک/ درخواست آینه‌سازی) را می‌توان بدون تأثیرگذاری بر روی کد انجام داد.

غذای فکر

اگر مکانی که درخواست‌ها در آن انعکاس می‌شوند، برخی از آنها را نه به v1، بلکه به v2 ارسال کند، چه؟ به عنوان مثال، یک درصد از تمام درخواست ها یا فقط درخواست های گروه خاصی از کاربران. و سپس، از قبل به نحوه عملکرد نسخه 2 نگاه می کنید، به تدریج تمام درخواست ها را به نسخه جدید منتقل کنید. یا برعکس، اگر مشکلی با v1 پیش آمد، همه چیز را به v2 برگردانید. فکر کنم اسمش Canary Deployment باشه. به معدن برمی گرددو اگر اصالتا روسی بود، احتمالاً اشاره ای به آن داشت گربه ها) و اکنون با جزئیات بیشتری به این موضوع خواهیم پرداخت.

استقرار قناری در ایستیو: ساده سازی راه اندازی

با دقت و به تدریج

ماهیت مدل استقرار Canary Deployment بسیار ساده است: هنگامی که نسخه جدیدی از نرم افزار خود را راه اندازی می کنید (در مورد ما، یک میکروسرویس)، ابتدا دسترسی به آن را به گروه کوچکی از کاربران می دهید. اگر همه چیز خوب پیش رفت، به آرامی این گروه را افزایش می دهید تا نسخه جدید شروع به کار کند، یا - اگر نشد - در نهایت همه کاربران را به آن منتقل می کنید. با معرفی متفکرانه و تدریجی نسخه جدید و تغییر کاربران به صورت کنترل شده، می توانید خطرات را کاهش دهید و بازخورد را به حداکثر برسانید.

البته ایستیو با ارائه چندین گزینه خوب برای مسیریابی درخواست هوشمند، استقرار Canary را ساده می کند. و بله، همه اینها را می توان بدون دست زدن به کد منبع شما به هیچ وجه انجام داد.

فیلتر کردن مرورگر

یکی از ساده ترین معیارهای مسیریابی، تغییر مسیر مبتنی بر مرورگر است. فرض کنید می خواهید فقط درخواست هایی از مرورگرهای سافاری برای رفتن به نسخه 2 داشته باشید. در اینجا نحوه انجام آن آمده است:

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

ترافیک v2 کجاست؟ از آنجایی که در مثال ما، تمام درخواست‌ها فقط از خط فرمان خود ما می‌آمدند، به سادگی وجود ندارد. اما به نکات اصلی در صفحه بالا توجه کنید: این واکنشی است به این واقعیت که ما یک درخواست از مرورگر Safari را اجرا کردیم که به نوبه خود این را ایجاد کرد:

قدرت نامحدود

قبلاً نوشته ایم که عبارات منظم قابلیت های بسیار قدرتمندی را برای درخواست های مسیریابی ارائه می دهند. به مثال زیر نگاهی بیندازید (ما فکر می کنیم متوجه خواهید شد که چه کاری انجام می دهد):

احتمالاً تا به حال ایده ای دارید که عبارات منظم چه کاری می توانند انجام دهند.

هوشمندانه عمل کنید

مسیریابی هوشمند، به ویژه پردازش هدر بسته ها با استفاده از عبارات منظم، به شما امکان می دهد ترافیک را به روشی که می خواهید مدیریت کنید. و این اجرای کد جدید را بسیار ساده می کند - ساده است، نیازی به تغییر خود کد ندارد و در صورت لزوم، همه چیز را می توان به سرعت همانطور که بود برگرداند.

علاقه مند؟

آیا مشتاق هستید که Istio، Kubernetes و OpenShift را در رایانه خود آزمایش کنید؟ تیم تیم توسعه دهنده Red Hat عالی تهیه کرد کتاب درسی در مورد این موضوع و همه فایل های همراه را در دسترس عموم قرار داد. پس ادامه بده و چیزی از خودت دریغ نکن.
 

Istio Egress: از فروشگاه سوغاتی خارج شوید

با استفاده از Istio به همراه Red Hat OpenShift و Kubernetes، می توانید زندگی خود را با میکروسرویس ها بسیار آسان تر کنید. مش سرویس ایستیو درون پادهای Kubernetes پنهان است و کد شما (بیشتر) به صورت مجزا اجرا می شود. عملکرد، سهولت تغییر، ردیابی و غیره - همه اینها به لطف استفاده از ظروف کناری قابل استفاده است. اما اگر میکروسرویس شما نیاز به برقراری ارتباط با سرویس‌های دیگری داشته باشد که خارج از سیستم OpenShift-Kubernetes شما قرار دارند، چه؟

اینجاست که Istio Egress به کمک می آید. به طور خلاصه، به سادگی به شما امکان می دهد به منابعی (بخوانید: "سرویس ها") دسترسی داشته باشید که بخشی از سیستم Kubernetes pods شما نیستند. اگر پیکربندی اضافی را انجام ندهید، در محیط Istio Egress ترافیک فقط در یک خوشه از pods و بین چنین خوشه‌هایی بر اساس جداول IP داخلی هدایت می‌شود. و چنین شفیره ای تا زمانی که نیازی به دسترسی به خدمات از خارج نداشته باشید عالی عمل می کند.

Egress به شما این امکان را می دهد که جداول IP بالا را بر اساس قوانین Egress یا بر اساس طیف وسیعی از آدرس های IP دور بزنید.

فرض کنید یک برنامه جاوا داریم که درخواست GET را به httpbin.org/headers می دهد.

(httpbin.org فقط یک منبع مناسب برای آزمایش درخواست های سرویس خروجی است.)

اگر در خط فرمان وارد کنید curl http://httpbin.org/headers، موارد زیر را مشاهده خواهیم کرد:

یا می توانید همان آدرس را در مرورگر باز کنید:

همانطور که می بینید، سرویسی که در آنجا قرار دارد به سادگی هدرهای ارسال شده به آن را برمی گرداند.

ما در حال جایگزینی واردات هستیم

حالا بیایید کد جاوا این سرویس را خارج از سیستم خود بگیریم و آن را به تنهایی اجرا کنیم، جایی که، به یاد بیاورید، Istio نصب شده است. (شما می توانید این کار را خودتان با تماس انجام دهید آموزش ایستیو ما.) پس از ساختن تصویر مناسب و راه اندازی آن بر روی پلتفرم OpenShift، این سرویس را با دستور فراخوانی خواهیم کرد. curl egresshttpbin-istioegress.$(minishift ip).nip.io، پس از آن این را روی صفحه مشاهده خواهیم کرد:

اوه، چی شد؟ همه چیز فقط کار کرد. یافت نشد به چه معناست؟ ما فقط برای او این کار را کردیم curl.

گسترش جداول IP به کل اینترنت

ایستیو را باید به خاطر این موضوع سرزنش (یا تشکر کرد). از این گذشته، ایستیو فقط کانتینرهای کناری است که وظیفه شناسایی و مسیریابی را بر عهده دارند (و خیلی چیزهای دیگر که قبلاً در مورد آنها صحبت کردیم). به همین دلیل، جداول IP فقط می دانند که چه چیزی در سیستم خوشه ای شما وجود دارد. و httpbin.org در خارج قرار دارد و بنابراین غیرقابل دسترسی است. و اینجاست که Istio Egress به کمک می آید - بدون کوچکترین تغییری در کد منبع شما.

قانون Egress زیر، Istio را مجبور می‌کند (در صورت لزوم، در کل اینترنت) سرویس مورد نیاز، در این مورد، httpbin.org را جستجو کند. همانطور که از این فایل (egress_httpbin.yml) می بینید، عملکرد در اینجا بسیار ساده است:

تنها چیزی که باقی می ماند اعمال این قانون است:

istioctl create -f egress_httpbin.yml -n istioegress

می توانید قوانین Egress را با دستور مشاهده کنید istioctl get egressrules:

و در نهایت دستور را دوباره اجرا می کنیم حلقه - و می بینیم که همه چیز کار می کند:

ما آشکارا فکر می کنیم

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

این آخرین پست این مجموعه در ایستیو بود. با ما همراه باشید - چیزهای جالب زیادی در پیش است!

منبع: www.habr.com