کنفرانس DEVOXX انگلستان. یک چارچوب را انتخاب کنید: Docker Swarm، Kubernetes یا Mesos. قسمت 3

Docker Swarm، Kubernetes و Mesos محبوب ترین فریم ورک های ارکستراسیون کانتینر هستند. آرون گوپتا در سخنرانی خود جنبه های زیر Docker، Swarm و Kubernetes را با هم مقایسه می کند:

• توسعه محلی.
• توابع استقرار
• کاربردهای چند کانتینری
• کشف خدمات
• مقیاس پذیری سرویس
• وظایف یکبار اجرا
• ادغام با Maven.
• به روز رسانی "Rolling".
• ایجاد یک خوشه پایگاه داده Couchbase.

در نتیجه، درک واضحی از آنچه هر ابزار ارکستراسیون ارائه می دهد به دست خواهید آورد و نحوه استفاده موثر از این پلتفرم ها را یاد خواهید گرفت.

آرون گوپتا، فن‌شناس ارشد محصولات منبع باز در خدمات وب آمازون است که بیش از 10 سال است که جوامع توسعه دهندگان Sun، Oracle، Red Hat و Couchbase را توسعه داده است. دارای تجربه گسترده کار در تیم های متقابل پیشرو در توسعه و اجرای استراتژی برای کمپین ها و برنامه های بازاریابی. او تیم هایی از مهندسان Sun را رهبری کرد، یکی از بنیانگذاران تیم Java EE و خالق شعبه ایالات متحده Devoxx4Kids است. آرون گوپتا نویسنده بیش از 2 هزار پست در وبلاگ های فناوری اطلاعات است و در بیش از 40 کشور جهان سخنرانی کرده است.

کنفرانس DEVOXX انگلستان. یک چارچوب را انتخاب کنید: Docker Swarm، Kubernetes یا Mesos. قسمت 1
کنفرانس DEVOXX انگلستان. یک چارچوب را انتخاب کنید: Docker Swarm، Kubernetes یا Mesos. قسمت 2

خط 55 حاوی یک COUCHBASE_URI است که به این سرویس پایگاه داده اشاره می کند، که همچنین با استفاده از فایل پیکربندی Kubernetes ایجاد شده است. اگر به خط 2 نگاه کنید، می توانید نوع را ببینید: Service سرویسی است که من ایجاد می کنم به نام couchbase-service، و همین نام در خط 4 ذکر شده است. در زیر برخی از پورت ها وجود دارد.

خطوط کلیدی 6 و 7 هستند. در سرویس می گویم، "هی، اینها برچسب هایی هستند که من به دنبال آنها هستم!"، و این برچسب ها چیزی بیش از نام جفت متغیر نیستند، و خط 7 به couchbase-rs-pod من اشاره می کند. کاربرد. در زیر پورت هایی هستند که دسترسی به همین برچسب ها را فراهم می کنند.

در خط 19 یک نوع ReplicaSet جدید ایجاد می کنم، خط 31 حاوی نام تصویر است و خطوط 24-27 به ابرداده مرتبط با غلاف من اشاره می کند. این دقیقاً همان چیزی است که سرویس به دنبال آن است و باید اتصال به آن برقرار شود. در انتهای فایل نوعی ارتباط بین خطوط 55-56 و 4 وجود دارد که می گوید: "از این سرویس استفاده کن!"

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

در نتیجه، من یک غلاف WildFly دارم که از طریق سرویس Couchbase با پایگاه داده ارتباط برقرار می کند. من می توانم از فرانت اند با چندین پاد WildFly استفاده کنم که از طریق سرویس couchbase نیز با backend couchbase ارتباط برقرار می کند.

بعداً به نحوه ارتباط سرویسی که در خارج از خوشه قرار دارد، از طریق آدرس IP خود با عناصری که در داخل خوشه قرار دارند و یک آدرس IP داخلی دارند، ارتباط برقرار می کند، خواهیم دید.

بنابراین، ظروف بدون حالت عالی هستند، اما استفاده از کانتینرهای دارای وضعیت چقدر خوب است؟ بیایید به تنظیمات سیستم برای کانتینرهای حالت دار یا ماندگار نگاه کنیم. در داکر 4 رویکرد مختلف برای چیدمان ذخیره سازی داده ها وجود دارد که باید به آنها توجه کنید. اولین مورد Implicit Per-Container است، به این معنی که هنگام استفاده از کانتینرهای satateful couchbase، MySQL یا MyDB، همه آنها با Sandbox پیش فرض شروع می شوند. یعنی هر چیزی که در پایگاه داده ذخیره می شود در خود ظرف ذخیره می شود. اگر ظرف ناپدید شود، داده ها نیز همراه با آن ناپدید می شوند.

دومی Explicit Per-Container است، زمانی که یک فضای ذخیره‌سازی خاص با دستور ایجاد docker volume ایجاد می‌کنید و داده‌ها را در آن ذخیره می‌کنید. سومین رویکرد Per-Host با نگاشت ذخیره سازی مرتبط است، زمانی که همه چیز ذخیره شده در کانتینر به طور همزمان در میزبان کپی می شود. اگر کانتینر خراب شود، داده ها روی هاست باقی می مانند. مورد دوم استفاده از چندین میزبان چند میزبان است که در مرحله تولید راه حل های مختلف توصیه می شود. فرض کنید کانتینرهای شما با برنامه های شما در هاست اجرا می شوند، اما می خواهید داده های خود را در جایی در اینترنت ذخیره کنید و برای این کار از نقشه برداری خودکار برای سیستم های توزیع شده استفاده می کنید.

هر یک از این روش ها از محل ذخیره سازی خاصی استفاده می کنند. ضمنی و صریح در هر کانتینر داده ها را روی میزبان در /var/lib/docker/volumes ذخیره می کند. هنگام استفاده از روش Per-Host، ذخیره سازی در داخل کانتینر نصب می شود و خود ظرف روی هاست نصب می شود. برای مولتی هاست ها می توان از راه حل هایی مانند Ceph، ClusterFS، NFS و ... استفاده کرد.

اگر یک کانتینر دائمی از کار بیفتد، دایرکتوری ذخیره سازی در دو مورد اول غیر قابل دسترس می شود، اما در دو مورد آخر دسترسی حفظ می شود. با این حال، در حالت اول، می‌توانید از طریق یک میزبان Docker که روی یک ماشین مجازی اجرا می‌شود، به مخزن دسترسی پیدا کنید. در حالت دوم، داده ها نیز از بین نمی روند، زیرا شما یک ذخیره سازی Explicit ایجاد کرده اید.

اگر هاست از کار بیفتد، دایرکتوری ذخیره سازی در سه مورد اول در دسترس نیست، در مورد آخر، ارتباط با ذخیره سازی قطع نمی شود. در نهایت، تابع اشتراک گذاری شده برای ذخیره سازی در حالت اول کاملاً حذف شده و در بقیه موارد امکان پذیر است. در حالت دوم، بسته به اینکه پایگاه داده شما از ذخیره سازی توزیع شده پشتیبانی می کند یا خیر، می توانید فضای ذخیره سازی را به اشتراک بگذارید. در مورد Per-Host، توزیع داده تنها بر روی یک میزبان معین امکان پذیر است، و برای یک مولتی هاست با گسترش خوشه ای ارائه می شود.

این باید هنگام ایجاد کانتینرهای حالت دار در نظر گرفته شود. یکی دیگر از ابزارهای مفید Docker، افزونه Volume است که بر اساس اصل «باتری‌ها موجود هستند، اما باید تعویض شوند» کار می‌کند. هنگامی که یک کانتینر Docker را راه اندازی می کنید، می گوید: "هی، هنگامی که یک کانتینر را با پایگاه داده راه اندازی کردید، می توانید داده های خود را در این کانتینر ذخیره کنید!" این ویژگی پیش فرض است، اما می توانید آن را تغییر دهید. این افزونه به شما امکان می دهد به جای پایگاه داده کانتینر از یک درایو شبکه یا چیزی مشابه استفاده کنید. این شامل یک درایور پیش‌فرض برای ذخیره‌سازی مبتنی بر میزبان است و امکان ادغام کانتینر با سیستم‌های ذخیره‌سازی خارجی مانند Amazon EBS، Azure Storage و دیسک‌های GCE Persistent را فراهم می‌کند.

اسلاید بعدی معماری افزونه Docker Volume را نشان می دهد.

رنگ آبی نشان دهنده سرویس گیرنده Docker مرتبط با میزبان آبی Docker است که دارای یک موتور ذخیره سازی محلی است که کانتینرهایی برای ذخیره داده در اختیار شما قرار می دهد. سبز نشان دهنده Plugin Client و Plugin Daemon است که به هاست نیز متصل هستند. آنها فرصتی را برای ذخیره داده ها در فضای ذخیره سازی شبکه از نوع Storage Backend مورد نیاز شما فراهم می کنند.

افزونه Docker Volume را می توان با ذخیره سازی Portworx استفاده کرد. ماژول PX-Dev در واقع کانتینری است که شما اجرا می کنید و به هاست Docker شما متصل می شود و به شما امکان می دهد داده ها را به راحتی در Amazon EBS ذخیره کنید.

کلاینت Portworx به شما امکان می دهد وضعیت ظروف ذخیره سازی مختلفی را که به هاست شما متصل هستند، نظارت کنید. اگر از وبلاگ من بازدید می کنید، می توانید نحوه استفاده حداکثری از Portworx با Docker را بخوانید.

مفهوم ذخیره سازی در Kubernetes شبیه Docker است و توسط دایرکتوری هایی که برای کانتینر شما در یک pod قابل دسترسی هستند نشان داده می شود. آنها مستقل از طول عمر هر ظرفی هستند. رایج ترین انواع ذخیره سازی موجود عبارتند از: hostPath، nfs، awsElasticBlockStore و gsePersistentDisk. بیایید نگاهی به نحوه کار این فروشگاه ها در Kubernetes بیندازیم. به طور معمول، روند اتصال آنها شامل 3 مرحله است.

اولین مورد این است که شخصی در سمت شبکه، معمولاً یک مدیر، فضای ذخیره سازی دائمی را در اختیار شما قرار می دهد. یک فایل پیکربندی PersistentVolume مربوطه برای این وجود دارد. سپس، توسعه‌دهنده برنامه یک فایل پیکربندی به نام PersistentVolumeClaim یا یک درخواست ذخیره‌سازی PVC می‌نویسد، که می‌گوید: «من 50 گیگابایت فضای ذخیره‌سازی توزیع شده دارم، اما برای اینکه افراد دیگر نیز از ظرفیت آن استفاده کنند، به این PVC می‌گویم که در حال حاضر فقط به 10 گیگابایت نیاز دارید. در نهایت، مرحله سوم این است که درخواست شما به عنوان ذخیره سازی نصب می شود و برنامه ای که دارای پاد، یا replica set یا چیزی مشابه است، شروع به استفاده از آن می کند. لازم به یادآوری است که این فرآیند از 3 مرحله ذکر شده تشکیل شده و مقیاس پذیر است.

اسلاید بعدی کانتینر پایداری Kubernetes از معماری AWS را نشان می دهد.

در داخل مستطیل قهوه ای که نشان دهنده خوشه Kubernetes است، یک گره اصلی و دو گره کارگر وجود دارد که با رنگ زرد نشان داده شده اند. یکی از گره‌های کارگر شامل یک غلاف نارنجی، ذخیره‌سازی، یک کنترل‌کننده ماکت و یک ظرف سبز رنگ Docker Couchbase است. در داخل خوشه، بالای گره ها، یک مستطیل بنفش نشان دهنده سرویس قابل دسترسی از بیرون است. این معماری برای ذخیره داده ها در خود دستگاه توصیه می شود. در صورت لزوم، همانطور که در اسلاید بعدی نشان داده شده است، می توانم داده های خود را در EBS خارج از خوشه ذخیره کنم. این یک مدل معمولی برای مقیاس‌بندی است، اما یک جنبه مالی وجود دارد که باید در هنگام استفاده از آن در نظر گرفت - ذخیره داده‌ها در جایی در شبکه می‌تواند گران‌تر از یک میزبان باشد. هنگام انتخاب راه حل های کانتینری، این یکی از استدلال های سنگین است.

درست مانند Docker، می توانید از ظروف Kubernetes دائمی با Portworx استفاده کنید.

این همان چیزی است که در اصطلاحات فعلی Kubernetes 1.6 "StatefulSet" نامیده می شود - راهی برای کار با برنامه های Stateful که رویدادهای مربوط به توقف Pod و اجرای Graceful Shutdown را پردازش می کند. در مورد ما، چنین برنامه هایی پایگاه داده هستند. در وبلاگ من می توانید نحوه ایجاد StatefulSet در Kubernetes با استفاده از Portworx را بخوانید.
بیایید در مورد جنبه توسعه صحبت کنیم. همانطور که گفتم Docker دارای 2 نسخه CE و EE است، در مورد اول ما در مورد نسخه پایدار Community Edition صحبت می کنیم که برخلاف نسخه به روز شده ماهانه EE هر 3 ماه یک بار به روز می شود. می توانید Docker را برای مک، لینوکس یا ویندوز دانلود کنید. پس از نصب، Docker به طور خودکار به روز می شود و شروع به کار بسیار آسان است.

برای Kubernetes، من نسخه Minikube را ترجیح می دهم - این راه خوبی برای شروع کار با پلتفرم با ایجاد یک خوشه در یک گره است. برای ایجاد خوشه هایی از چندین گره، انتخاب نسخه ها گسترده تر است: اینها kops، kube-aws (CoreOS+AWS)، kube-up (منسوخ شده) هستند. اگر به دنبال استفاده از Kubernetes مبتنی بر AWS هستید، توصیه می‌کنم به AWS SIG بپیوندید، که هر جمعه به‌صورت آنلاین گرد هم می‌آید و انواع مختلفی از مطالب جالب را در مورد کار با AWS Kubernetes منتشر می‌کند.

بیایید به نحوه انجام Rolling Update در این پلتفرم ها نگاه کنیم. اگر خوشه ای از چندین گره وجود داشته باشد، از یک نسخه خاص از تصویر استفاده می کند، به عنوان مثال، WildFly:1. به روز رسانی رول به این معنی است که نسخه تصویر به طور متوالی با یک نسخه جدید در هر گره، یکی پس از دیگری جایگزین می شود.

برای این کار از دستور docker service update (نام سرویس) استفاده می کنم که در آن نسخه جدید تصویر WildFly:2 و روش به روز رسانی update-parallelism 2 را مشخص می کنم. عدد 2 به این معنی است که سیستم 2 تصویر برنامه را به روز می کند. به طور همزمان، سپس یک تاخیر 10 ثانیه ای به روز رسانی 10 ثانیه، پس از آن 2 تصویر بعدی در 2 گره دیگر و غیره به روز می شوند. این مکانیزم به‌روزرسانی ساده به عنوان بخشی از Docker در اختیار شما قرار می‌گیرد.

در Kubernetes، یک به روز رسانی چرخشی مانند این کار می کند. کنترل‌کننده Replication rc مجموعه‌ای از کپی‌های همان نسخه را ایجاد می‌کند و هر pod در این webapp-rc با یک برچسب واقع در etcd ارائه می‌شود. وقتی به یک پاد نیاز دارم، از Application Service برای دسترسی به مخزن etcd استفاده می‌کنم که با استفاده از برچسب مشخص شده، پاد را در اختیار من قرار می‌دهد.

در این مورد، ما 3 پاد در کنترلر Replication داریم که برنامه WildFly نسخه 1 را اجرا می کنند. هنگام به روز رسانی در پس زمینه، یک کنترلر تکرار دیگری با همان نام و شاخص در انتها ایجاد می شود - - xxxxx، که x اعداد تصادفی هستند، و با همان برچسب ها اکنون Application Service دارای سه پاد با نسخه قدیمی برنامه و سه پاد با نسخه جدید در کنترلر Replication جدید است. پس از این، غلاف های قدیمی حذف می شوند، کنترل کننده تکرار با غلاف های جدید تغییر نام داده و راه اندازی می شود.

بریم سراغ نظارت. Docker دارای بسیاری از دستورات نظارتی داخلی است. به عنوان مثال، رابط خط فرمان docker container stats به شما امکان می دهد هر ثانیه اطلاعاتی در مورد وضعیت کانتینرها به کنسول نمایش دهید - استفاده از پردازنده، استفاده از دیسک، بارگذاری شبکه. ابزار Docker Remote API داده هایی در مورد نحوه ارتباط کلاینت با سرور ارائه می دهد. از دستورات ساده استفاده می کند، اما مبتنی بر Docker REST API است. در این مورد، کلمات REST، Flash، Remote به همین معنی است. وقتی با میزبان ارتباط برقرار می کنید، یک REST API است. Docker Remote API به شما امکان می دهد اطلاعات بیشتری در مورد کانتینرهای در حال اجرا به دست آورید. وبلاگ من جزئیات استفاده از این مانیتورینگ با ویندوز سرور را تشریح می کند.

نظارت بر رویدادهای سیستم داکر هنگام اجرای یک خوشه چند میزبان، به دست آوردن اطلاعات مربوط به خرابی میزبان یا خرابی کانتینر در یک میزبان خاص، خدمات مقیاس‌بندی و موارد مشابه را ممکن می‌سازد. با شروع Docker 1.20، شامل Prometheus می شود که نقاط پایانی را در برنامه های موجود جاسازی می کند. این به شما امکان می دهد معیارها را از طریق HTTP دریافت کنید و آنها را در داشبورد نمایش دهید.

یکی دیگر از ویژگی های نظارت، cAdvisor (مخفف مشاور کانتینر) است. این داده‌های استفاده از منابع و عملکرد را از کانتینرهای در حال اجرا تجزیه و تحلیل و ارائه می‌کند و معیارهای Prometheus را مستقیماً از جعبه ارائه می‌کند. نکته خاص در مورد این ابزار این است که فقط داده های 60 ثانیه گذشته را ارائه می دهد. بنابراین، شما باید بتوانید این داده ها را جمع آوری کرده و در یک پایگاه داده قرار دهید تا بتوانید یک فرآیند طولانی مدت را نظارت کنید. همچنین می توان از آن برای نمایش معیارهای داشبورد به صورت گرافیکی با استفاده از Grafana یا Kibana استفاده کرد. وبلاگ من شرح مفصلی در مورد نحوه استفاده از cAdvisor برای نظارت بر کانتینرها با استفاده از داشبورد Kibana دارد.

اسلاید بعدی نشان می دهد که خروجی نقطه پایانی Prometheus چگونه است و معیارهای موجود برای نمایش چگونه است.

در پایین سمت چپ معیارهایی برای درخواست‌ها، پاسخ‌ها و غیره HTTP مشاهده می‌کنید، در سمت راست نمایشگر گرافیکی آن‌ها دیده می‌شود.

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

هر یک از گره های کاری حاوی یک cAdvisor است که به طور خودکار راه اندازی می شود. علاوه بر این، Heapster، یک سیستم نظارت بر عملکرد و جمع‌آوری معیارهای سازگار با Kubernetes نسخه 1.0.6 و بالاتر وجود دارد. Heapster به شما امکان می دهد نه تنها معیارهای عملکرد بارهای کاری، غلاف ها و کانتینرها، بلکه رویدادها و سایر سیگنال های تولید شده توسط کل خوشه را نیز جمع آوری کنید. برای جمع‌آوری داده‌ها، با Kubelet هر پاد صحبت می‌کند، به طور خودکار اطلاعات را در پایگاه داده InfluxDB ذخیره می‌کند و آن‌ها را به‌عنوان معیارهایی به داشبورد Grafana ارسال می‌کند. با این حال، به خاطر داشته باشید که اگر از miniKube استفاده می کنید، این ویژگی به طور پیش فرض در دسترس نیست، بنابراین باید از افزونه ها برای نظارت استفاده کنید. بنابراین همه چیز به این بستگی دارد که کانتینرها را کجا اجرا می کنید و از کدام ابزارهای نظارتی می توانید به طور پیش فرض استفاده کنید و باید به عنوان افزونه های جداگانه نصب کنید.

اسلاید بعدی داشبوردهای Grafana را نشان می دهد که وضعیت کارکرد کانتینرهای من را نشان می دهد. در اینجا داده های بسیار جالبی وجود دارد. البته بسیاری از ابزارهای تجاری Docker و Kubernetes برای نظارت بر فرآیند وجود دارد، مانند SysDig، DataDog، NewRelic. برخی از آنها یک دوره آزمایشی رایگان 30 ساله دارند، بنابراین می توانید سعی کنید موردی را که مناسب شماست پیدا کنید. من شخصا ترجیح می دهم از SysDig و NewRelic استفاده کنم که به خوبی با Kubernetes ادغام می شوند. ابزارهایی وجود دارند که به خوبی با پلتفرم های Docker و Kubernetes ادغام می شوند.

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV از 199 دلار در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com