مفهوم Pod در kubernetes چیست و چطور کار می کند

مفهوم Pod در kubernetes چیست و چطور کار می کند

What is pod on kubernetes and how it works

 

درک مفهوم Pod ها

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

یک Pod ، یک مخزن application ( و در برخی موارد چندین مخزن ) ، منابع ذخیره ساز ، یک آدرس IP منحصر به فرد و گزینه هایی که مشخص می کنند مخزن ها چطور اجرا شوند را ، کپسوله می کند. یک Pod نشان دهنده یک قسمت از توسعه است : یک نمونه کوچک از یک برنامه Kubernetes که یا حاوی یک مخزن است و یا شامل چند مخزن وابسته به یکدیگر است و این منابع به اشتراک گذاشته می شود.

Pod ها از تمامی مخازن زمان اجرا به خوبی پشتیبانی می کنند و Docker که محبوب ترین مخزن زمان اجرا است نیز از Kubernetes Pods استفاده می کند.

از Pod ها در کلاسترینگ Kubernetes به دو روش استفاده می شود :

  1. Pod های شامل یک مخزن : “one-container-per-Pod” محبوب ترین حالت مورد استفاده دز Kubernetes است. در این حالت فرض کنید که یک مخزن بسته بندی شده است و Kubernetes به جای استفاده مستقیم از مخزن از Pod استفاده می کند.
  2. Pod های شامل چند مخزن که برای کار کردن به یکدیگر نیاز دارند : یک Pod می تواند شامل یک برنامه چند مخزن مورد نیاز به صورت محلی باشد که این مخزن ها به شدت به یکدیگر وابسته هستند ، و همه این ها در یک Pod به اشتراک گذاشته شده اند. این مخزن هایی که به صورت محلی بسته بندی شده اند به صورت یک واحد یکپارچه مانند یک مخزن از فایل های منابع به اشتراک گذاشته شده به صورت عمومی سرویس دهی می کنند ، در حالی که یک مخزن جداگانه این فایل ها را به روز رسانی و مجدد بازخوانی می کند. Pod این مخازن و ذخیره ساز های به اشتراک گذاشته شده را بسته بندی کرده و یک موجودیت جدید با قابلیت مدیریت ارائه می کند.

هر Pod به معنای اجرای یک نمونه برنامه تعیین شده است. اگر می خواهید چندین برنامه را به صورت موازی و همزمان اجرا کنید ، باید برای هرکدام یک Pod را اجرا کنید. در Kubernetes به این کار replication گفته می شود. Replicates Pod ها معمولا به صورت گروهی و به وسیله مفهومی به نام Controller ایجاد و مدیریت می شوند. برای اطلاعات  بیشتر Pod ها و Controller ها را مطالعه کنید.

چطور Pod ها چندین مخزن را کنترل می کنند

Pod ها برای تبدیل چندین پردازش وابسته به یکدیگر ( مانند مخازن ) و ارائه آنها به صورت یک سرویس یکپارچه طراحی شده است. مخازن موجود در Pod به صورت خودکار و به صورت محلی و زمان بندی شده بر روی یک ماشین مجازی یا کلاستر کار می کنند. این مخزن ها منابع و پیش نیازهایشان را به اشتراک می گذارند و با یکدیگر در ارتباط هستند و به صورت هماهنگ با یکدیگر تا خاتمه کار همکاری دارند.

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

Kubernetes Pod Diagram

نمودار Pod :

Pod ها دو منبع مشترک را برای مخزن های تشکیل دهنده آن ارائه می کند : شبکه و ذخیره ساز.

شبکه

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

ذخیره ساز

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

کار کردن با Pod ها

Pod ها برای اهداف و مصارف نسبتا کوتاه مدت طراحی شده اند و به همین دلیل به ندرت پیش می آید که Pod های تکی در Kubernetes ایجاد کنید. هنگامی که یک Pod ایجاد می شود ( چه مستقیما توسط خودتان یا غیر مستقیم توسط Controller ) برنامه ریزی می شود تا در یک گره یا Node در کلاستر اجرا شود و در همان Node تا زمان اتمام پردازش ، حذف شدن Pod ، خارج کردن Pod از گره به علت کمبود منابع و یا بروز خطا در گره ، باقی می ماند.

نکته : راه اندازی مجدد یک مخزن داخل Pod نباید با راه اندازی مجدد خود Pod اشتباه گرفته شود. یک Pod خودش اجرا نمی شود ولی یک زیرساختی را فراهم می کند که مخزن ها تا زمانی که حذف نشده اند در آن اجرا می شوند.

Pod ها حالت خود درمانی یا خود ترمیمی ندارند و اگر وقتی زمان بندی شده اند که در یک گره کار کنند ، دچار مشکل شوند ، Pod ها حذف می شوند. به همین ترتیب اگر گره ای دچار مشکل کمبود منابع شود و یا برای رفع مشکل در حالت تعمیرات قرار گیرد ، Pod ها حذف خواهند شد. Kubernetes از کی مفهموم سطح بالایی به نام Controller استفاده می کند که تا حدودی کارهایی که Pod ها باید انجام دهند را مدیریت می کنند. این حالت استفاده Kubernetes از Controller ها برای مدیریت Pod ها بسیار رایج است.

Pod ها و Controller  ها

یک Controller می تواند چندین Pod را ایجاد و مدیریت کند ، مدیریت Replication ها و برنامه ریزی ها و حالت خود تعمیری در کلاستر. برای مثال اگر یک گره دچار خطا شود ، به صورت خودکار یک گره یکسان دیگر را جایگزین می کند.

قالب های Pod

قالب های Pod ها مشخصات فنی آن ها هستند و شامل عناصر دیگر مانند Replication Controllers, Jobs, و DaemonSets می شوند. Controller ها با استفاده از قالب ها Pod ها رو ایجاد می کنند. در زیر یک مثال روشن از یک Pod آورده شده که شامل یک مخزن است که یک پیغام را چاپ می کند :

قالب Pod ها علاوه بر مشخص کردن وضعیت فعلی از همه حالت ها ، مانند یک قالب کیک عمل می کنند. قالب کیک یک کیک را شکل می دهد و هیچ رابطه ای با آن کیک ندارد. تغییرات بعدی قالب حتی انتقال به یک قالب جدید، روی Pod هایی که تا الان ایجاد شده اند تاثیر مستقیمی ندارند. به بیان ساده تر Pod ها توسط یک replication controller ها که متعاقبا به روز رسانی خواهند شد ، ایجاد می شوند و مشخص کردن وضعیت فعلی همه مخزن های متعلق به Pod ها یک عملکرد منطقی است.  

آموزش نصب کلاسترینگ Kubernetes با Kubeadm در اوبونتو ۱۶٫۰۴

آموزش نصب کلاسترینگ کوبرنیتیس Kubernetes 1.10 با Kubeadm در اوبونتو ۱۶٫۰۴

How To Setup a Kubernetes 1.10 Cluster Using Kubeadm on Ubuntu 16.04

معرفی Kubernetes 

در این آموزش به مبحث نصب و راه اندازی کلاسترینگ Kubernetes در سیستم عامل Ubuntu می پردازیم. کوبرنیتیس Kubernetes یک سیستم مدیریت مخازن و به صورت متن باز و رایگان می باشد که توسط گوگل و بر اساس تجربیات اجرای مخازن در محصولات ایجاد شده است.

از Kubeadm برای نصب ، پیکربندی و خودکارسازی اجزای Kubernetes مانند API های سرور  ، Controller Manager و Kube DNS استفاده می شود. این برنامه کارهایی مثل ایجاد کاربر یا مدیریت مراحل نصب سیستم عامل و تنظیمات آن ها را انجام نمی دهد و برای این کار ها ممکن از ابزارهای مدیریت پیکربندی مانند Ansible یا SaltStack استفاده شود. از ابزار Kubeadm ایجاد کلاستر ها یا بازسازی آنها به سادگی و با کمترین خطا استفاده می شود.

اهداف

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

  • یک سرور برای Master Node

این سرور مسئول مدیریت وضعیت کلاستر را دارد. در این سرور  Etcd اجرا می شود که اطلاعات کلاستر مربوط به تقسیم بار کاری بین سرور ها را ذخیره می کند.

  • دو سرور Worker Node

سرور هایی هستند که تقسیم بار بر روی آنها انجام می شود( مانند برنامه ها و سرویس های مخازن ها ). یک سرور worker وظیفه ای که به آن داده شده را تا زمانی که master زمان بندی کرده است انجام می دهد. با اضافه کردن سرور های worker می توان ظرفیت کلاستر را افزایش داد.

بعد از اتمام این آموزش شما یک کلاستر برای اجرای برنامه های مخازن دارید که منابع RAM و CPU مورد نیاز برای اجرای برنامه های شما را با سرور های متعدد تامین می کند. تقریبا تمامی برنامه ها یونیکس مانند برنامه های تحت وب ، پایگاه داده ، سرویس ها و ابزارهای دستورات خط فرمان تحت کلاستر قابل اجرا هستند. خود کلاستر نیز حدود ۵۰۰-۳۰۰ MB حافظه و ۱۰ درصد از CPU را مصرف می کند.

وقتی کلاستر راه اندازی شد ، یک وب سرور Nginx را نصب می کنیم تا از مطمئن شویم که همه چیز درست است.

پیش نیاز ها

  • کلید SSH که بر روی هر دو سرور محلی تنظیم شده است. اگر تا الان با کلید های SSH کار نکرده اید از این آموزش می توانید استفاده کنید.
  • سه سرور Ubuntu16.04 با حداقل یک گیگ رم که تنظیمات SSH با کلید روی آن انجام شده باشد.
  • برنامه Ansible بر روی سرورهای مجازی محلی نصب شده باشد. روش این کار در مرحله اول این آموزش نصب Ansible آورده شده است.
  • آشنایی با کتاب های آموزشی Ansible.
  • دانش راه اندازی یک مخزن با داکر Docker. مرحله پنجم از آموزش نصب داکر در اوبونتو را مرور کنید.

مرحله اول – تنظیم دایرکتوری فضای کار و فایل فهرست Ansible

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

یکی از این سه سرور ، سرور master شما هست که IP آن با master_ip نمایش داده می شود. آدرس IP دو سرور دیگر که به عنوان worker هستند ، به عنوان worker_1_ip و worker_2_ip نمایش داده می شوند.

یک دایرکتوری با نام ~/kube-cluster در مسیر home ایجاد کنید و وارد آن شوید :

این دایرکتوری ، فضای کاری شما در این آموزش خواهد بود و شامل playbook های Ansible خواهد بود و تمام دستورات خط فرمان را مربوط به این سرور را در این دایرکتوری وارد می کنید.

ایجاد یک فایل با نام kube-cluster/hosts/~ با ابزار nano یا ویرایشگر متن مورد نظرتان :

خطوط زیر را در این فایل وارد کنید و مقادیر مشخص شده را با مقادیر مناسب جایگزین کنید :

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

در گروه masters ، یک سرور وجود دارد که با نام master مشخص شده و آدرس IP و نام کاربر از راه دوری که Ansible باید دستورات خود را اجرا کند با کاربر root مشخص شده است.

به همین ترتیب ، در گروه workers ، دو سرور worker با آدرس های worker_1_ip و worker_2_ip و کاربر ansible_user مشخص شده اند.

در خط آخر نیز برای مدیریت عملیات ها از راه دور مشخص شده است که برنامه Ansible از مترجم Python 3 در سرور ها استفاده کند.

در انتها نیز بعد از ویرایش فایل و اطمینان از صحت اطلاعات آن ، فایل را ذخیره کرده و خارج شوید.

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

مرحله دوم – ایجاد کاربر در سرور ها متصل 

در این قسمت بر روی سرور ها یک کاربر عادی بدون دسترسی ریشه non-root user ایجاد می کنیم ولی این کاربر ها باید عضو گروه sudo باشند تا بتوان بوسیله این کاربر ها از طریق اتصال SSH با سرور ارتباط برقرار کرد. این کار برای زمان هایی که می خواهید اطلاعات سیستم را با دستوراتی مانند top/htop مشاهده کنید و لیستی از منابع در حال اجرا را مشاهده کنید یا تغییراتی را در تنظیمات فایل هایی که مالک آن root است را تغییر دهید بسیار مفید است. هر چند که این کارها را به صورت مرتب در طول نگهداری کلاستر انجام خواهید داد ، و استفاده از یک کاربر عادی non-root ریسک عملیات هایی مانند ویرایش یا حذف فایل ها و عملیات هایی که ناخواسته انجام می شود را کاهش می دهد.

یک فایل با نام  kube-cluster/initial.yml/~ در فضای کاری ایجاد کنید :

در ادامه متن زیر را که play نامیده می شود، در فایل قرار دهید تا کاربر مورد نظر در تمام سرور ها ایجاد شود. یک play در Ansible مجموعه ای از مراحلی است که مشخصات سرور ها و گروه های مشخصی را تهیه می کند. Play زیر یک کاربر non-root ایجاد می کند :

توضیحات اینکه این play چکار می کند :

  • ایجاد یک کاربر non-root با نام ubuntu
  • تنظیم فایل sudoers برای اجازه اجرای دستورات sudo بدون درخواست رمز عبور برای کاربر ubuntu
  • اضافه کردن کلید عمومی ماشین محلی به لیست کلید های مجاز کاربر ریموت ubuntu. با این کار اجازه اتصال SSH به هر سروری داده می شود.

این فایل را ذخیره کرده و خارج شوید.

در ادامه این playbook را اجرا می کنیم :

این دستور بین دو تا ۵ دقیقه اجرا می شود ، و پس از کامل اجرا شدن دستور خروجی مشابه زیر نمایش داده می شود :

تا اینجا تنظیمات مقدماتی انجام شده و می توانید به نصب پیش نیاز های کوبرنیتیس بپردازید.

مرحله سوم – نصب پیش نیاز های kubernetes

در این قسمت شما باید پکیج های مورد نیاز سیستم عامل را برای پیش نیاز Kubernetes هستند بوسیله ابزار مدیریت بسته های Ubuntu نصب کنید. این پکیج ها به صورت زیر هستند :

  • Doker – یک مخزن زمان اجرا می باشد، که شامل اجزای مورد نیاز مخازن شما می باشد. همچنین از مخازن دیگر مانند rkt را پشتیبانی می کند.
  • kubeadm – یک ابزار خط فرمان برای نصب و پیکربندی اجزای مختلف کلاستر به صورت استاندارد می باشد.
  • kubelet – یک برنامه سیستمی و یک سرویس است که برای مدیریت گره ها Nodes و عملیات ها می باشد.
  • kubectl – یک ابزار خط فرمان برای ارسال دستورات به کلاستر ها از طریق API Server می باشد.

یک فایل با نام kube-cluster/kube-dependencies.yml/~ در مسیر فضای کاری ایجاد کنید :

سپس play زیر را برای نصب پکیج ها در سرور ها وارد کنید :

این play به صورت زیر کار می کند :

  • نصب داکر
  • نصب apt-transport-https ، اضافه کردن منابع HTTPS خارجی به لیست منابع APT
  • اضافه کردن apt-key برای تایید کلید منابع Kubernetes APT
  • نصب kubelet و kubeadm

دومین play فقط یک وظیفه را انجام می دهد و آن هم نصب kubectl بر روی سرور master می باشد.

بعد از اتمام کار فایل را ذخیره کرده و خارج شوید و Playbook را اجرا کنید :

بعد از اتمام اجرای این فایل خروجی مشابه زیر را مشاهده می کنید :

بعد از نصب داکر ، kubeadm و kubelet بر روی سرور ها ، برای اجرای kubectl چیز خاصی مورد نیاز نیست و فقط باید دستورات کلاستر را اجرا کنید. این مسئله خیلی مهم و حساس است ، که kubectl فقط بر روی سرور master نصب شده باشد و دستورات kubectl فقط از سرور master داده شود.به این نکته دقت کنید که kubectl بر روی هر ماشین مجازی که در کلاستر باشد می تواند نصب شود و دستورات کلاستر را اجرا کند.

خوب تا اینجا پیش نیاز ها نصب شده اند و در ادامه به سراغ نصب و تنظیم سرور master و راه اندازی اولیه کلاستر می رویم.

مرحله چهارم – تنظیم سرور Master

در این قسمت سرور master را تنظیم می کنیم. قبل از شروع تنظیمات و ایجاد playbook های جدید کمی درباره برخی اصطلاحات مانند Pods و Pods Networking Plugins صحبت می کنیم.

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

این کار توسط پلاگین شبکه pod انجام می شود. در این آموزش از Flannel استفاده می کنیم که یک گزینه پایدار و مناسب است.

یک Ansible playbook با نام master.yml ایجاد کنید :

متن play زیر را برای نصب Flannel و مقدار دهی اولیه کلاستر وارد کنید :

توضیحاتی درباره این play :

  • اولین کاری که انجام می شود ، مقدار دهی اولیه کلاستر بوسیله kubeadm init است. تنظیم پارامتر –pod-network-cidr=10.244.0.0/16 ، که شبکه اختصاصی را برای pod مشخص می کند.
  • دومین کاری که انجام می شود، ایجاد دایرکتوری .kube در home/ubuntu/ است. در این دایرکتوری اطلاعات پیکربندی از قبیل فایل های کلید ادمین که برای اتصال کلاستر ها هستند و آدرس IP کلاستر ها نگهداری می شود.
  • سومین کاری که انجام می شود، کپی فایل etc/kubernetes/admin.conf/ که ubeadm init این فایل را با کاربر non-root در home ایجاد کرده است. این کار برای اجازه دسترسی kubectl به کلاستر های جدید ایجاد شده می باشد.
  • آخرین کار نیز اجرای kubectl apply برای نصب Flannel می باشد. مقدار [kubectl apply -f descriptor.[yml|json به kubectl اعلام می کند که یک شئ جدید که در فایل [descriptor.[yml|json توضیح داده شده است را ایجاد کند. فایل kube-flannel.yml شامل جزئیات شئ مورد نیاز برای تنظیم Flannel در کلاستر می باشد.

در انتها فایل را ذخیره کرده و خارج شوید.

فایل playbook را به صورت محلی اجرا کنید :

خروجی این دستور مشابه زیر است :

برای بررسی وضعیت سرور master از طریق ssh با دستور زیر به سرور متصل شوید :

پس از وارد شدن به سرور دستور زیر را اجرا کنید :

باید خروجی مشابه زیر را مشاهده کنید :

در سرور master تمامی تنظیمات و مقداردهی های اولیه انجام شده و وضعیت سرور در حالت ready و آماده برای شروع اتصال به سرور های worker و ارسال وظایف به API Server می باشد. اکنون می توانید سرور های worker را اضافه کنید.

مرحله پنجم – تنظیمات سرور های Worker

برای اضافه کردن گره worker یک دستور را باید اجرا کنید که شامل جزئیات مورد نیاز کلاستر از قبیل آدرس IP و پورت API سرور master می باشد و یک توکن امنیتی می باشد. فقط سروری که توکن را قبول می کند می تواند به کلاستر متصل شود.

به مسیر فضای کاری بروید و یک playbook به نام workers.yml ایجاد کنید :

متن زیر را در فایل قرار دهید :

توضیحات این playbook :

  • در ابتدا دستور اتصال اجرا می شود که باید در سرور worker وارد شود و قالب دستور به این صورت است : kubeadm join –token <token> <master-ip>:<master-port> –discovery-token-ca-cert-hash sha256:<hash>. این دستور با قرار دادن مقادیر token و hash تکمیل می شود.
  • قسمت دوم فقط دستور اتصال به گره ها یا سرور های worker را اجرا می کند که پس از تکمیل شدن این دستور هر دو سرور ، قسمتی از کلاستر خواهند بود.

فایل را ذخیره کرده و خارج شوید.

فایل playbook را اجرا کنید :

خروجی این اجرا مشابه زیر است :

با اضافه شدن سرور های worker کلاستر شما به صورت کامل تنظیم شده و آماده بهره برداری است و worker ها آماده اجرای بارهای کاری ارسالی هستند. قبل از زمان بندی برنامه ، اجازه دهید تا بررسی کنیم که کلاستر همانطور که می خواهیم کار می کند یا خیر.

مرحله ششم – بررسی کلاستر

ممکن است به دلیل از دسترسی خارج شدن یک سرور worker یا خرابی ارتباط بین سرور های master و worker ، راه اندازی کلاستر با مشکل مواجه شود. در این قسمت بررسی می کنیم که کلاستر و سرور ها به درستی کار کنند.

در ابتدا وضعیت گره ها یا سرور های متصل به سرور master را در سرور master را بررسی می کنیم. در ابتدا به سرور master متصل می شویم :

سپس دستور زیر را برای بررسی وضعیت سرور اجرا کنید :

خروجی باید مشابه زیر باشد :

اگر وضعیت STATUS سرور ها در حالت ready بود ، به این معنی است که این قسمت از سرور به درستی کار می کند و آماده انجام کارها می باشند.

و اگر هر وضعیت STATUS هر سروری در حالت NotReady باشد به این معنی است که تنظیمات آن سرور هنوز تمام نشده است. حدود ۵ تا ۱۰ دقیقه قبل از اجرای مجدد دستور kubectl get node صبر کنید ، سپس مجددا خروجی را بررسی کنید. اگر هنوز وضعیت سرور ها NotReady بود ، باید دستورات مراحل قبل را مجددا بررسی و اجرا کنید.

پس از اطمینان از صحت عملکرد کلاستر ، برنامه Nginx را به عنوان یک نمونه زمان بندی می کنیم.

مرحله هفتم – اجرای یک برنامه در کلاستر

اکنون می توانید هر برنامه ای که نیاز به مخزن دارد را اجرا کنید. برای نمونه برنامه Nginx را بر روی کلاستر اجرا می کنیم. از دستوراتی که در ادامه آورده می شوند می توانید برای اجرای هر برنامه دیگری استفاده کنید.

همچنان در سرور master دستور زیر را برای ایجاد یک deployment از  nginx وارد کنید :

deployment یک نو از شئ Kubernetes می باشد که وجود همیشگی تعدادی pod در حال اجرا را در یک قالب تعریف شده تضمین می کند ، حتی اگر در زمان اجرای کلاستر pod از دسترس خارج شود. قبل از deployment یک pod با یک کانتینر از داکر موجود در Ngingx Docker Image ایجاد می شود.

سپس برای ایجاد یک سرویس با نام nginx برای در اختیار عموم قرار دادن این برنامه ، دستور زیر را وارد کنید. این کار از طریق NodePort انجام می شود ، به این صورت که یک پورت دلخواه را برای اتصال به یک pod در یک سرور دیگر باز می کند :

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

دستور زیر را اجرا کنید :

خروجی این دستور مانند زیر است :

همانطور که در خروجی مشاهده می کنید Nginx بر روی پورت ۸۰ کار می کند. Kubernetes یک پورت تصادفی بالاتر از ۳۰۰۰۰ که مطمئن است به سرویس دیگری تعلق نگرفته است را به این برنامه می دهد.

برای بررسی صحت عملکرد آدرس http://worker_1_ip:nginx_port یا http://worker_2_ip:nginx_port را در مرورگر سرور محلی خود وارد کنید. باید بتوانید صفحه Nginx را مشاهده کنید.

برای حذف برنامه Nginx ابتدا سرویس Nginx را از سرور master حذف کنید :

دستور زیر را وارد کنید تا از حذف شدن برنامه مطمئن شوید :

خروجی باید مشابه زیر باشد :

سپس deployment را حذف کنید :

پایان

در این آموزش شما توانستید یک کلاستر مخازن Kubernetes در Ubuntu 16.04 بوسیله Kubeadm راه اندازی کنید ، و در مراحل بعدی باید بتوانید برنامه ها و سرویس ها بیشتری را در کلاستر deploy کنید. در ادامه چند لینک برای راهنمایی و آموزش بیشتر شما قرار داده ایم :

  • Dockerizing applications – لیستی از مثال هایی برای آموزش استفاده از مخازن داکر.
  • Pod Overview – توضیحات بیشتر درباره pod ها و ارتباط آن ها با اجزا دیگر Kubernetes. این pod ها در همه جای Kubernetes هستند و فهم بهتر آن ها به شما کمک زیادی می کند.
  • Deployments Overview – مرور بر مفهوم deployment است. خیلی مهم است که بدانید deployments ها چطور مانند کارها را کنترل می کنند.
  • Services Overview – سرویس های دیگری را که توسط اجزا Kubernetes استفاده می شوند را بررسی می کند. درک انواع سرویس ها و گزینه هایی که برای اجرای هر دو برنامه های stateless و statefull هستند ، ضروری است.

مفاهیم مهم دیگر  Volumes, Ingresses و  Secrets .هستند که برای deploy برنامه ها در Kubernetes بسیار مفید هستند. Kubernetes ، امکانات و ویژگی های زیادی دارد که در مستندات رسمی Kubernetes بهترین منبع برای مطالعه می باشد.

آموزش مدیریت پیکربندی و نوشتن Playbook های Ansible

آموزش مدیریت پیکربندی و نوشتن Playbook های Ansible
Configuration Management – Writing Ansible Playbooks

 

معرفی Ansible 

به صورت خلاصه مدیریت پیکربندی سرور ( در اینجا منظور خودکار سازی مدیریت IT است ) ، یک راه حل برای تبدیل مدیریت زیر ساخت به صورت بر مبنای کد Codebase است ، و برای انجام این کار نیاز به استقرار یک سرور برای تهیه اسکریپت هایی با قابلیت نسخه بندی و استفاده مجدد است. با این کار می توان زیرساخت همه سرور ها را به صورت جامع بهبود بخشید.در این آموزش درباره نحوه خودکار سازی مدیریت سرور ها بوسیله Ansible و طریقه نوشتن آن ها صحبت می کنیم. برنامه Ansible یک ابزار برای خودکار سازی مدیریت پیکربندی است که چهار چوب های کامل و قابلیت تنظیمات را با هدف ساده سازی و خلاصه کردن تنظیمات در اختیار ما قرار می دهد. در این آموزش بر روی نوشتن نحوه دستوری ، اصطلاحات و ویژگی های مورد نیاز برای ایجاد یک نمونه ساده روند خودکار سازی ساده و توسعه آن بر روی سرور Ubuntu 14.04 و با وب سرور Apache تمرکز می کنیم.

در زیر لیست مراحلی که باید برای رسیدن به هدف خودکار سازی تنظیمات سرور ها را انجام دهیم آورده ایم :

  1. به روز رسانی مخزن apt
  2. نصب Apache
  3. ساخت root directory سفارشی
  4. قرار دادن index.html در root directory سفارشی
  5. اعمال یک قالب برای راه اندازی یک هاست مجازی
  6. راه اندازی مجدد Apache

با نگاهی به ویژگی های اصلی زبانی که برای نوشتن Playbook ها استفاده می شود ،کار را با بررسی اصطلاحات استفاده شده در Ansible شروع می کنیم. در انتهای این آموزش مثال های کاملی را با شما به اشتراک می گذاریم تا خودتان آن ها را امتحان کنید.

نکته : این آموزش آماده شده تا زبان Ansible و نحوه نوشتن Playbook ها برای خودکار سازی تنظیمات سرور ها را به شما معرفی کند. برای مشاهده مقدمات بیشتر درباره Ansible و مراحل مورد نیاز برای نصب و شروع کار با آن آموزش نصب و راه اندازی Ansible بر روی Ubuntu 14.04 را مطالعه کنید.

شروع

قبل از شروع اصطلاحات Ansible به صورت کلی مرور می کنیم ، آشنایی با اصطلاحات و مفاهیم Ansible بسیار مهم است :

اصطلاحات Ansible

  • Controller Machine : ماشین یا سروری است که Ansible بر روی آن نصب شده و مسئولیت اجرای سرویس دهی به سرور هایی است که می خواهید آن ها را مدیریت کنید.
  • Inventory : یک فایل INI  که شامل اطلاعات سرور هایی است که می خواهید آن ها را مدیریت کنید.
  • Playbook : نقطه شروع تنظیمات و مقررات Ansible ، که وظایف خودکار سازی در آن با قالب بندی YAML تعریف شده است.
  • Task : یک بلاک که یک روش را برای اجرا شدن تعریف می کند ، مانند نصب یک بسته.
  • Module : یک ماژول معمولا وظایف یا کارهای سیستم را خلاصه می کند ، مانند برخورد با بسته ها یا ایجاد و تغییر فایل ها.
  • Role : به Playbook های از پیش تعیین شده و سازماندهی شده می گویند که به راحتی به برای استفاده مجدد به اشتراک گذاشته می شوند.
  • Play : کارهایی که از شروع تا پایان انجام می شوند را یک play می گویند.
  • Facts : متغیرهای عمومی که شامل اطلاعات سیستم مانند رابط های شبکه یا سیستم عامل می باشند.
  • Handlers : برای تغییر وضعیت یک سرویس استفاده می شود مانند راه اندازی یا متوقف کردن یک سرویس می باشد.

مقررات و تنظیمات Ansible با YAML که یک زبان ساده برای مرتب سازی داده ها است استفاده می شود.

وظایف – Tasks

یک وظیفه یا Task یک کاری را تعریف می کند که باعث اجرای یک مرحله از موارد مورد نیاز می شود. این وظایف معمولا شامل استفاده از یک ماژول یا یک دستور ساده می شود ( ماژول ها نیز  دستوراتی را تولید می کنند که در انتها این دستورات اجرا می شوند). در اینجا یک وظیفه یا Task را می بینیم :

مقدار name معمولا اختیاری است ولی برای اینکه در خروجی اجرای وظایف بتوانید نام آن را مشاهده کنید پیشنهاد می شود که از آن استفاده کنید. Apt نیز یک ماژول توکار Ansible است که ابزار مدیریت بسته در توزیع های مبتنی بر دبیان است. این وظیفه به Ansible می گوید که وضعیت بسته vim باید به latest تغییر کند، با این دستور اگر تاکنون بسته vim نصب نشده باشد آن بسته نصب و به روز می شود.

قالب بندی Playbook

Playbook ها نقطه اصلی تنظیمات Ansible می باشد. آن ها شامل اطلاعات سیستم هایی هستند که باید مدیریت شوند ، همچنین دستورالعمل ها و مراحلی که باید اجرا شوند. در زیر یک نمونه Playbook آورده شده که دو کار را انجام می دهد : به روز رسانی apt سپس نصب vim.

 

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

نوشتن Playbook ها

کار با متغیر ها

روش های مختلفی برای تعریف متغیر در Ansible وجود دارد. ساده ترین روش استفاده از قسمت vars در playbook می باشد. در مثال زیر متغیر package تعریف شده است که قبلا در وظایف از آن استفاده کردیم :

متغیر package در همه سرور ها قابل دسترس است که شامل فایل ها و قالب ها است.

استفاده از Loop

حلقه ها یا Loop ها برای تکرار یک وظیفه یا Task با استفاده مقادیر متفاوت است. برای نمونه به جای ایجاد کردن ۱۰ وظیفه برای نصب ۱۰ بسته ، یک وظیفه ایجاد می کنیم و با استفاده از Loop آن وظیفه را با بسته های مورد نظرتان برای نصب تکرار می کنیم.

برای ساخت حلقه با یک وظیفه از with_items با آرایه ای از مقادیر استفاده می کنیم. برای دسترسی به محتوا نیز از طریق متغیر item به مقادیر دسترسی داشته باشد ، مانند مثال زیر :

همچنین از متغیر آرایه برای تعریف مقادیر نیز می توانید استفاده کنید :

استفاده از شرط ها

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

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

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

در مثال زیر دو وظیفه آورده شده است که برای اجرا شدن به خروجی دستور php -v نیاز دارند. همانطور که می دانید اگر PHP بر روی سرور نصب نباشد اجرای این دستور با خطا مواجه خواهد شد ، پس برای بررسی شرط خروجی این دستور ، وضعیت اجرای دستور را بررسی می کنیم. قسمت ignore_errors بخش مهمی از یک وظیفه است و برای ادامه فعالیت یک وظیفه نسبت به خروجی دستور نقش مهمی را دارد.

 

ماژول Debug که در اینجا استفاده کردیم یکی ماژول بسیار کاربردی برای نمایش مقدار متغیر ها و تحلیل پیام هاست. این ماژول می تواند یک رشته را چاپ کند ( زمانی که از آرگومان msg استفاده شود ) یا اینکه محتوای یک متغیر را چاپ کنید ( زمانی که از آرگومان var استفاده شود ).

کار با قالب ها

قالب ها معمولا برای فایل های تنظیمات پیکربندی استفاده می شوند که با استفاده از متغیر ها یا ویژگی های مورد نظرمان می توانیم از این فایل ها برای مقاصد دیگر نیز استفاده کنیم. Ansible از قالب موتور Jinja2 استفاده می کند.

در مثال زیر یک قالب برای تنظیم یک هاست Apache آورده شده است که از یک متغیر برای تعیین مسیر ریشه هاست استفاده می کنیم :

ماژول توکار template برای اعمال قالب می باشد که به صورت یک وظیفه عمل می کند. اگر نام قالب که در بالا تعریف کردیم را vhost.tpl گذاشته باشید و در همان مسیری باشد که Playbook شما قرار داشته باشد ، با صورتی که در زیر آورده شده می توانید قالب را با قالب پیش فرض تعیین هاست Apache جایگزین و اعمال کنید :

تعریف و راه اندازی کنترل کننده ها –  Handlers

از کنترل کننده ها یا همان Handler ها به عنوان تغییر دهنده وضعیت یک سرویس ، مانند متوقف کردن یا راه اندازی مجدد استفاده می شود. کنترل کننده ها رفتاری شبیه به وظیفه ها دارند و دستور تعریف شده را اجرا می کنند ، با این تفاوت که برای اجرا باید notify در آن وظیفه تعریف شده باشد. کنترل کننده ها معمولا از قبل در یک آرایه در قسمت handlers از playbook تعریف شده اند.

برای نمونه نگاهی به مثال قبل که از یک قالب نمونه برای ایجاد هاست مجازی Apache استفاده کردیم می اندازیم. اگر بخواهیم که Apache بعد از تغییرات هاست مجازی مجددا راه اندازی شود ، باید یک کنترل کننده برای سرویس Apache بنویسم. به صورت زیر یک کنترل کننده یا Handler برای Playbook می نویسیم :

در اینجا قسمت name بسیار مهم است ، زیرا تعیین کننده یک نام واحد و Unique برای کنترل کننده یا Hnadler است. برای اجرا شدن این کنترل کننده در یک وظیفه باید از گزینه notify استفاده کنید :

یک نمونه Playbook

اکنون به Playbook ای که در این آموزش برای خودکار سازی نصب Apache بر روی سرور Ubuntu 14.04 نوشتیم ، نگاه دقیق تری می کنیم. این یک مثال کامل است که شامل قالب و راه اندازی Apache و یک فایل HTML است که توسط وب سرور نمایش داده می شود که از اینجا می توانید این فایل را بدست آورید. همچنین این پوشه حاوی Vagrantfile است که از آن برای بررسی و تست ساده Playbook با ماشین مجازی مدیریت شده با Vagrant مدیریت می شود ، می توانید استفاده کنید.

در زیر Playbook به صورت کامل آورده شده :

توضیحات Playbook

hosts: all

فایل Playbook با اظهار اینکه تنظیمات باید به تمامی هاست ها ( host: all ) اعمال شوند ، شروع می شود. این مقدار می تواند به هاست های بخصوص یا گروهی از هاست ها تغییر کند.

become: true

این قسمت به Ansible می گوید که از افزایش دسترسی (sudo) برای اجرای تمامی دستورات استفاده کند. این گزینه می تواند برای هر وظیفه ای و بازنویسی شود.

vars

تعریف متغیر doc_root ، که قبلا در وظیفه Task از آن استفاده کردیم. در این قسمت می توان متغیر های متفاوت دیگری را نیز تعریف کرد.

tasks

در این قسمت خود وظیفه یا Task تعریف می شود. ابتدا بسته apt را به روز می کند و در وظیفه بعدی بسته apache2 را نصب می کند.

وظیفه سوم از ماژول file برای ساخت دایرکتوری در مسیر ریشه ای که برای سرویس دهی استفاده می کنیم ، ایجاد می کند. از این ماژول برای مدیریت فایل و دایرکتوری استفاده می شود.

چهارمین وظیفه از ماژول copy برای کپی کردن فایل سیستم محلی به سرور استفاده می کند. یک فایل HTML ساده را برای سرویس دهی وب  Apache کپی می کنیم.

handlers

در انتهای نیز قسمت handlers را داریم که سرویس ها در آن معرفی شدند. یک کنترل کننده restart apache تعریف کردیم تا تغییرات Apache اعمال شوند.

آموزش نصب و پیکربندی Ansible در Ubuntu 16.04

آموزش نصب و پیکربندی Ansible در Ubuntu 16.04

How to Install and Configure Ansible on Ubuntu 16.04

 

 

معرفی Ansible 

سیستم های مدیریت پیکربندی و تنظیمات به منظور سادگی بیشتر مدیران و تیم های عملیاتی برای کنترل سرورهای زیاد طراحی شده اند و با کمک این سیستم های مدیریتی می توانید سیستمهای متفاوتی را از یک مکان مرکزی کنترل کنید.

هم اکنون سیستم های مدیریت پیکربندی محبوب برای سیستم های لینوکس مانند Chef و Puppet وجود دارند ولی اغلب این برنامه ها پیچیده تر از چیزی هستند که مردم می‌خواهند و به این نیاز دارند. Ansible بهترین جایگزین برای این کار است زیرا کمترین سربار را هنگام راه اندازی دارد.

در این آموزش روش نصب Ansible را بر روی سرور Ubuntu 16.04 را مطرح می کنیم و روش های ابتدایی کار با این برنامه را می گوییم.

Ansible چگونه کار می کند ؟

Ansible از یک کامپیوتر که اجزای Ansible بر روی آن نصب است ماشین های کاربران را تنظیم و پیکربندی می کند. همچنین از کانال های SSH عادی برای ارتباط با ماشین ها از راه دور برای دریافت اطلاعات ، دستورالعمل ها و کپی فایل ها استفاده می کند.

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

هر کامپیوتری که از طریق SSH می توانید به آن وصل شوید را می توانید از طریق Ansible مدیریت کنید.

برنامه Ansible به صورت ماژولار کار می کند که این امر باعث می شود که ویژگی های مورد نیازتان برای سناریو های متفاوت را به سیستم اصلی اضافه کنید و از آن استفاده کنید. ماژول ها با هر زبان برنامه نویسی می توانند طراحی شده باشند که باید با استاندارد JSON با یکدیگر ارتباط برقرار کنند.

فایل پیکربندی اصلی با قالب استاندارد YAML نوشته شده است که باعث می شود کاملا واضح و خوانا باشد و شبیه به زبان های نشانه گذاری محبوب باشد. برنامه Ansible از طریق هر ابزار خط فرمان یا اسکریپت های پیکربندی که به آن ها Playbook گفته می شود با کاربران در ارتباط باشد.

پیش نیاز ها

در این آموزش به یک سرور Ubuntu 16.04 با دسترسی کاربر non-root با مجوز sudo و ارتباط SSH نیاز دارید.

مرحله اول – نصب Ansible

کار با Ansible به معنی مدیریت سرور های مختلف است که برای این کار باید Ansible را حداقل بر روی یک سرور مجازی نصب کنید. در اینجا برای نصب برنامه از یک سرور Ubuntu 16.04 استفاده می کنیم.

بهترین روش نصب برای Ansible ، اضافه کردن آن به PPA ( Personal Package System ( که همان منبع مخازن سیستم می باشد ، است. برای اضافه کردن به PPA می توانید از دستور زیر استفاده کنید :

برای تایید پیام های اضافی PPA دکمه Enter را بزنید.

در ادامه باید برای سیستم مدیریت بسته های از بسته های جدید مطلع شود آن را مجددا راه اندازی کنیم ، سپس برنامه را نصب کنیم :

همانطور که گفتیم در درجه اول Ansible از طریق SSH با کامپیوتر کاربر ارتباط برقرار می کند. در حالی که قابلیت مدیریت با سیستم احراز هویت بر اساس رمز عبور را دارد ، از کلید SSH نیز می تواند برای راحتی کار استفاده کند.

تا اینجا همه برنامه های مورد نیاز را برای مدیریت سرورهای مان از طریق برنامه Ansible را داریم.


مرحله دوم – پیکربندی میزبان های Ansible

برنامه Ansible سرور هایی که در فایل hosts  تعریف شده اند را بررسی می کند ، پس برای برقراری ارتباط با کامپیوتر های دیگر باید این فایل را تنظیم کنیم. این فایل را با دسترسی root باز کنید :

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

فایل hosts نسبتا قابل انعطاف است و راه های مختلفی برای تنظیم این فایل وجود دارد. روش و قالبی که ما از آن برای پیکربندی استفاده می کنیم به صورت زیر است :

مقدار group_name برای دسته بندی سرور هاست که باید از یک کلمه استفاده کنید.

مقدار alias نیز فقط یک نام است که به سرور اشاره می کند.

 

در سناریو ما فرض بر این است که سه سرور قرار است که بوسیله Ansible کنترل شوند. این سرور های باید با دستور زیر از سرور Ansible در دسترس باشند :

اگر تنظیمات را به درستی انجام داده باشید نباید پیغام رمز عبور را مشاهده کنید و این به این معنی است که باید کلید SSH سرور را به درستی تنظیم کرده باشید. آدرس های IP که به سرور ها اختصاص دادیم ۱۹۲٫۰٫۲٫۱ ، ۱۹۲٫۰٫۲٫۲ و ۱۹۲٫۰٫۲٫۳ می باشند و نام های host1 ، host2 و host3 را با نام گروه servers به آنها اختصاص داده ایم.

برای انجام این کار باید بلاک زیر را به فایل hosts اضافه کنید :

هاست ها می توانند در گروه های متفاوتی باشند و هر گروه می تواند تنظیمات جداگانه ای برای اعضای خودش داشته باشد. بعدا این مسئله را امتحان کنید.

با تنظیماتی که تا الان انجام شده اگر بخواهیم از طریق Ansible به سرور های هاست ها متصل شویم با خطا مواجه خواهیم شد ( با فرض اینکه کاربر root نباشید ). به این دلیل که کلید SSH برای کاربر root تعریف شده است و Ansible به صورت پیش فرض برای اتصال از کاربر فعلی شما استفاده می کند. اگر اقدام به اتصال کنید خطای زیر را مشاهده خواهید کرد :

در سرور Ansible از کاربری به نام demo استفاده می کنیم و Ansible تلاش می کند که با این دستور به همه سرور ها متصل شود ssh demo@server ، و اگر این کاربر بر روی سیستم راه دور تعریف نشده باشد ، این دستور کار نمی کند. برای رفع مشکل یک فایل ایجاد می کنیم تا همه سرور های عضو گروه server با کاربر root متصل شوند.

برای این کار یک دایرکتوری در ساختار پیکربندی Ansible با نام group_vars ایجاد می کنیم. در این پوشه برای هر گروهی که می خواهیم تنظیم کنیم یک فایل با فرمت استاندارد YAML ایجاد می کنیم :

تنظیمات را در این فایل قرار می دهیم. فایل های YAML با “—” شروع می شوند ، پس فراموش نکنید که در ابتدای فایل آن را اضافه کنید :

در انتها فایل را ذخیره کرده و خارج شوید.

اگر میخواهید تنظیمات خاصی را برای همه سرور های بدون در نظر گرفتن گروه آنها انجام دهید ، این تنظیمات را در فایل etc/ansible/group_vars/all/ قرار دهید. برای اعمال تنظیمات خاص برای هاست های نیز می توانید در مسیر etc/ansible/host_vars/ فایل های پیکربندی را ایجاد کنید.

مرحله سوم – دستورات ساده Ansible

تا اینجا سرور های هاست ها را تنظیم کردیم و پیکربندی کافی برای اتصال به سرور های هاست ها را انجام دادیم و اکنون می توانیم دستورات اولیه را اجرا کنیم.

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

این یک تست ساده برای بررسی اتصال Ansible با سرور های هاست های تعریف شده بود. در اینجا کلمه “all” برای همه هاست استفاده می شود ، اگر می خواهید که از گروه خاصی تست ping بگیرید از دستور زیر استفاده کنید :

همچنین می توانید یک هاست خاص را تعیین کنید :

همچنین چند هاست خاص که آنها را با کولون : از یکدیگر جدا می کنیم :

مقدار m ping- در دستور گفته شده برای استفاده از ماژول “ping” در ساختار Ansible است. این ها دستورات پایه ای هستند که می توانید بر روی سرور ها هاست ها از راه دور اجرا کنید. ماژول ping در بیشتر موارد مانند ابزار ping لینوکس  عمل می کند ولی در Ansible ارتباطات را بررسی می کند.

ماژول ping هیچ آرگومانی را نمی گیرد ولی می توانیم دستور دیگری را امتحان کنیم تا از صحت عملکرد آن مطمئن شویم. می توانیم آرگومان a- را ارسال کنیم. ماژول shell این امکان را برای ما فراهم می کند که دستورات خط فرمان را از راه دور بر روی سرور های هاست ها اجرا کنید و نتیجه را دریافت کنیم. برای مثال از دستور زیر برای پیدا کردن مقدار فضای استفاده شده حافظه رم از سرور host1 استفاده می کنیم :

پایان

تا اینجا باید توانسته باشید که سرور Ansible را پیکربندی کرده باشید و سرور هایی را که می خواهید تنظیم کنید با موفقیت به Ansible متصل کرده باشید.

تا اینجا سرور Ansible را برای اتصال به سرور هایی که می خواهیم آنها را مدیریت کنیم پیکربندی کرده و به سرور های هاست ها متصل کردیم. در ادامه بررسی صحت اتصال به سرور های هاست ها را بررسی کردیم و دستورات ساده ansible را از راه دور اجرا کردیم.

سعی کردیم مطالب مفید و کاربردی را در این مطلب بیان کنیم ولی مطالب عنوان شده بسیار ساده و ابتدایی هستند و به ویژگی های پرقدرت Ansible پرداخته نشده است ، مانند Playbook ها.

آموزش راه اندازی کلاسترینگ پایگاه داده Cassandra با چندین سرور یا گره در Ubuntu 14.04

آموزش راه اندازی کلاسترینگ پایگاه داده Cassandra با چندین سرور یا گره در Ubuntu 14.04

ow To Run a Multi-Node Cluster Database with Cassandra on Ubuntu 14.04

 

 

معرفی Cassandra 

Cassandra یا Apache Cassandra یک پایگاه داده متن باز بر اساس سیستم NoSQL می باشد که بسیار مقیاس پذیر و قابل انعطاف می باشد و کارایی بسیار بالایی در کلاسترینگ با چندین سرور را دارد. قبلا به بررسی نصب و راه اندازی Cassandra با یک گره Node پرداختیم ، و در این آموزش Cassandra را با چندین گره بر روی سرور Ubuntu 14.04 راه اندازی می کنیم.

پیش نیاز ها

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

در این آموزش به موارد زیر نیاز داریم :

  • حداقل دو سرور Ubuntu 14.04 که تنظیمات راه اندازی اولیه روی آنها انجام شده باشد.
  • تنظیمات دیواره آتش هر سرور باید انجام شده باشد.
  • بر روی هر سرور برنامه Cassandra مطابق آموزش راه اندازی Cassandra که قبلا داده شده نصب شده باشد.

مرحله اول – حذف داده های پیش فرض

سرور ها در کلاستر Cassandra به عنوان گره Node شناخته می شوند. تا الان هر چیزی که روی سرور داریم یک کلاستر Cassandra در یک سرور و به صورت تک گره Single-Node است و در این آموزش کلاسترینگ Cassandra را به صورت چندین گره Multi-Node بر روی چند سرور راه اندازی می کنیم.

تمام دستورات در این مرحله و مراحل بعد باید در تمامی گره ها و سرور ها وارد شود و باید مطمئن باشید که ترمینال های زیادی را در سرور های می توانید اجرا کنید.

اولین دستوری که در سرور ها باید وارد کنید برای متوقف کردن سرویس Cassandra daemon می باشد :

سپس مجموعه داده های Cassandra را حذف می کنیم :

مرحله دوم – پیکربندی کلاستر

فایل پیکربندی Cassandra در مسیر etc/cassandra/ قرار دارد. فایل cassandra.yaml شامل قسمتها و دستورات زیادی است ، که در این مرحله آن را برای راه اندازی کلاستر پیکربندی می کنیم.

برای راه اندازی کلاسترینگ با چندین گره ، فقط خطوط زیر را تغییر می دهیم :

cluster_name : تعیین نام دلخواه برای کلاستر

seed : برای تعیین لیست آدرس های IP سرور های می باشد که باید با کاما از یکدیگر جدا کنید

listen-address : آدرس IP سروری که بقیه گره ها باید به این گره متصل شوند. به صورت پیش فرض مقدار آن localhost است که باید مقدار آدرس IP سرور را قرار دهید.

rpc-address : تعیین آدرس IP برای دسترسی سرویس ها و پردازش های دیگر سرور ها به این سرور است که به صورت پیش فرض روی ocalhost قرار دارد. اگر نام دامنه ای برای سرور انتخاب و به درستی تنظیم شده است آن را رها کنید در غیر اینصورت مقدار آدرس IP سرور را با مقدار ۱۲۷٫۰٫۰٫۱ جایگزین کنید.

endpoint-snitch : انتخاب یک نام برای معرفی شبکه به Cassandra که به اصطلاح آن را خرگوش snitch می نامیم. این مقدار به Cassandra می گوید که دنبال چه شبکه ای باید بگردد. در اینجا مقدار پیش فرض SimpleSnitch است که برای شبکه هایی است که در یک دیتاسنتر هستند ولی ما در اینجا مقدار آن را GossipingPropertyFileSnitch قرار می دهیم که این مقدار برای محصولات و تنظیمات تجاری پیشنهاد می شود.

auto-bootstrap : این خط در فایل پیکربندی وجود ندارد ، پس باید آن را اضافه کنید و مقدار آن را false قرار دهید. این گزینه باعث می شود که گره های جدید به درستی از داده های استفاده کنند. در حالتی که می خواهید گره جدید به کلاستر اضافه کنید این گزینه اختیاری است ولی اگر کلاسترینگ تازه راه اندازی می کنید این گزینه اجباری است و به این معنی است که این گره تنها و بدون داده است.

فایل پیکربندی را با nano یا یک ویرایشگر متن دلخواه باز کنید :

خطوط زیر را در این فایل پیدا کنید و همانطور که در زیر نشان داده شده آن ها را تغییر دهید. مقدار your_server_ip را با مقدار آدرس IP سروری که الان به آن متصل هستید جایگزین کنید. مقدار seeds –  باید در همه سرور ها یکسان باشد و شامل آدرس IP همه سرور ها است که با کاما از یکدیگر جدا شده اند.

در انتهای فایل خط auto_bootstrap را نیز اضافه کنید :

پس از اتمام تغییرات فایل پیکربندی ، آن را ذخیره کرده و خارج شوید. این تنظیمات را نیز در تمامی سرور هایی که می خواهید عضو گره های کلاستر باشند ، انجام دهید.

مرحله سوم – تنظیمات فایروال

تا اینجا کلاستر Cassandra را پیکربندی کردیم ولی سرور های نمی توانند با یکدیگر ارتباط داشته باشند و برای رفع این مشکل باید دیواره آتش را پیکر بندی کنیم.

در ابتدا سرویس Cassandra را در هر سرور مجددا راه اندازی می کنیم :

اگر وضعیت کلاستر را بررسی کنید می بینید که فقط یک گره محلی local فعال است و به این دلیل است که سرور های توانایی ارتباط با یکدیگر را ندارند.

 

برای برقراری ارتباط در شبکه باید پورت های زیر را در هر سرور باز کنید :

  • ۷۰۰۰ : که پورت TCP و برای دستورات و داده ها هست
  • ۹۰۴۲ : که پورت TCP و برای ارتبط محلی سرور ها است. Cqlsh که ابزار خط فرمان Cassandra است ، از طریق این پورت ارتباط برقرار می کند.

برای تغییرات در فایروال ، فایل رول های مربوط به IPv4 را باز کنید :

برای اجازه به ترافیک ورودی پورت های گفته شده ، خط زیر را در زنجیره INPUT وارد کنید. اگر برای تنظیم فایروال از فایل rules.v4 استفاده می کنید ، کافیست خط زیر را قبل از خط توضیح Reject anything that’s fallen through to this point # قرار دهید.

آدرس IP مشخص شده با s- باید آدرس گره یا سرور دیگر در کلاستر باشد. مثلا اگر دو سرور با آدرس های ۱۱۱٫۱۱۱٫۱۱۱٫۱۱۱ و ۲۲۲٫۲۲۲٫۲۲٫۲۲۲ دارید ، با در سرور ۱۱۱٫۱۱۱٫۱۱۱٫۱۱۱ باید در خط زیر از آدرس ۲۲۲٫۲۲۲٫۲۲۲٫۲۲۲ استفاده کنید.

پس از اضافه کردن نقش مورد نظر ، فایل را ذخیره کرده و خارج شوید و سپس iptables را مجددا راه اندازی کنید.

مرحله چهارم – بررسی وضعیت کلاستر

تا اینجا همه کارهایی که باید برای راه اندازی کلاستر با چندین گره را باید انجام می دادیم را انجام دادیم. اکنون باید وضعیت ارتباطات بین همه گره ها را بررسی کنیم.

 

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

همچنین اگر امکان اتصال با دستور calsh را دارید ، به این روش نیز می توانید آن را بررسی کنید. دقت کنید که برای استفاده از این دستور به آدرس IP هر گره در کلاستر نیاز دارید.

اگر متصل باشد خروجی زیر را مشاهده می کنید :

 

پایان

شما توانستید که کلاسترینگ Cassandra را با چندین گره راه اندازی کنید. برای کسب اطلاعات بیشتر می توانید سایت پروژه Cassandra را مطالعه کنید. اگر نیاز به رفع مشکل کلاستر داشتید ، ابتدا به دنبال یک سرنخ در گزارش ها در مسیر var/log/cassandra/ بگردید.

آموزش نصب Cassandra و کلاستر با یک سرور در Ubuntu 14.04

آموزش نصب Cassandra و راه اندازی کلاستر با یک سرور در Ubuntu 14.04

How To Install Cassandra and Run a Single-Node Cluster on Ubuntu 14.04

معرفی

Cassandra یا Apache Cassandra یک پایگاه داده متن باز بر اساس سیستم NoSQL می باشد که بسیار مقیاس پذیر و قابل انعطاف می باشد و کارایی بسیار بالایی در کلاسترینگ با چندین سرور را دارد. در این آموزش خواهید آموخت که چطور این پایگاه داده را به صورت تک گره Node را بر روی سرور Ubuntu 14.04 نصب و استفاده کنید.

پیش نیاز ها

در این آموزش به موارد زیر نیاز دارید :

  • یک سرور Ubuntu 14.04
  • دسترسی یک کاربر non-root با مجوز sudo برای اجرای دستورات

مرحله اول – نصب Oracle Java Virtual Machine

برای اجرای Cassandra نیاز است که Oracle Java SE Runtime Environment (JRE) روی سرور نصب باشد. پس در این مرحله JRE را نصب می کنیم و بررسی می کنیم که به صورت پیش فرض فعال باشد.

برای فعال کردن بسته های Oracle JRE باید با استفاده از دستور زیر Personal Package Archives (PPA)  را به سیستم اضافه کنید :

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

سپس Oracle JRE را نصب می کنیم. همراه با نصب بسته ، برنامه JRE به صورت پیش فرض سیستم قرار می گیرد. در ادامه نصب باید مجوز را تایید کنید :

بعد از نصب با دستور زیر ، بررسی می کنیم که نصب با موفقیت انجام شده یا خیر :

باید خروجی مشابه زیر را مشاهده کنید :پ

مرحله دوم – نصب Cassandra

در ادامه برنامه Cassandra را از منابع رسمی نرم افزار های Apache نصب می کنیم ، و برای این کار باید منابع مورد نیاز را به منابع موجود سیستم اضافه کنیم. در زمان تهیه این آموزش آخرین نسخه Cassandra ، شماره ۲٫۲٫۲ می باشد اگر هنگام نصب نسخه جدیدتری ارائه شده ، شماره نسخه را به صورت ۲۲x جایگزین کنید. مثلا اگر نسخه ۲٫۳ را می خواهید نصب کنید مقدار ۲۳x را قرار دهید.

آدرس منبع را اضافه می کنیم :

برای رفع مشکل خطای تایید بسته ها هنگام نصب ، باید این سه کلید را از Apache Software Foundation که مربوط به مخازن بسته ها است را اضافه کنید.

کلید ها را یکی یکی به صورت جداگانه نصب کنید و برای نصب هر کدام از دو دستور داده شده استفاده کنید :

دومین کلید :

سومین کلید :

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

در انتها Cassandra را نصب کنید :

مرحله سوم – عیب یابی و اجرای Cassandra

به طور معمول بعد از نصب Cassandra به صورت خودکار اجرا می شود ، ولی اگر به دلیل بروز مشکلی برنامه اجرا نشد ، برای بررسی وضعیت برنامه دستور زیر را وارد کنید :

اگر برنامه اجرا نشده باشد ، خروجی زیر نمایش داده می شود :

این یک مشکل شناخته شده و قابل رفع برای آخرین نسخه Cassandra در سیستم عامل Ubuntu می باشد. برای رفع مشکل ابتدا اسکریپت init مربوط به Cassandra را ویرایش می کنیم. مقداری که باید تغییر دهیم در خط شماره ۶۰ قرار دارد. ابتدا فایل را با یک ویرایشگر متنی باز می کنیم :

این خط را پیدا کنید :

و به این صورت تغییر دهید :

فایل را ذخیره کنید و خارج شوید ، سپس سرور را ریبوت کنید :

یا

بعد از راه اندازی مجدد سرور ، سرویس Cassandra باید اجرا شده باشد ، برای بررسی این موضوع دستور زیر را وارد کنید :

خروجی باید به صورت زیر باشد :

مرحله چهارم – اتصال به کلاستر

اگر توانستید با موفقیت Cassandra را اجرا کنید ، برای بررسی وضعیت کلاستر دستور زیر را وارد کنید :

در خروجی کلمه UN به این معنی است که سرویس بالا Up و در حالا عادی Normal است :

سپس با استفاده از خط فرمان مختص به cassandra به عنوان یک رابط استفاده کنید و به آن متصل شوید :

خواهید دید که اتصال برقرار است :

برای خروج دستور exit را وارد کنید :

پایان

تبریک میگم ، شما توانستید کلاستر Cassandra را با یک گره Node بر روی سرور Ubuntu 14.04 راه اندازی کنید. اطلاعات بیشتر در مورد Cassandra در وب سایت این پروژه موجود است.

آموزش نصب Docker و استفاده از Image و Container در Ubuntu 18.04

آموزش نصب Docker و استفاده از Image و Container در Ubuntu18.04

How To Install Docker and Use Image and Container on Ubuntu 18.04

معرفی

داکر Docker یک برنامه کاربردی است که فرآیند مدیریت پردازش های برنامه ها را توسط مخزن ها Containers راحت تر می کند. مخزن ها منابع ایزوله شده ای هستند که اجازه می دهند پردازش برنامه های شما در آن محیط ها انجام شوند. آن ها بسیار شبیه به ماشین ها مجازی هستند ، اما مخزن ها قابل حمل (Portable) هستند و همچنین منابع سازگار بیشتری دارند وبه سیستم عامل میزبان وابسته هستند. در این آموزش نسخه عمومی Docker Community Edition (CE)  را نصب و استفاده می کنیم. خودتان Docker را نصب می کنید و با مخزن ها Containers و منبع ها Images کار می کنید ، و یک منبع image را به منابع Docker اضافه می کنید.

برای درک بهتر از اجزای متفاوت مخزن Docker این مطلب را مطالعه کنید :

The Docker Ecosystem: An Introduction to Common Components

پیش نیاز ها

در این آموزش به موارد زیر نیاز دارید :

  • یک سرور مجازی Ubuntu 18..04 با دسترسی یک کاربر غیر ریشه non-root و عضو sudoer همراه با یک دیوار آتش Firewall.  
  • یک حساب کاربری در Docker Hube ، البته اگر می خواهید که یک image برای خودتان بسازید و طبق راهنمای مرحله ۷ و ۸ آن را در Docker Hub قرار دهید.

مرحله اول – نصب Docker

بسته (package) نصب داکر در منابع رسمی اوبونتو موجو می باشد ولی ممکن است که آخرین نسخه در این منابع موجود نباشد برای همین آخرین نسخه را از منابع رسمی Docker نصب می کنیم. برای این کار منبع بسته (package source) جدید را به سیستم اضافه می کنیم و برای اطمینان از معتبر بودن دانلود بسته کلید GPG را اضافه می کنیم ، سپس بسته را نصب می کنیم.

ابتدا لیست بسته های موجود را نصب می کنیم :

سپس ، تعدادی از بسته های پیش نیاز را با apt نصب می کنیم :

سپس کلید GPG مربوط به منابع Docker را به سیستم اضافه می کنیم :

منابع Docker را به منبع APT اضافه می کنیم :

سپس دیتابیس بسته ها را منابع جدید Docker که اضافه کردیم را به روز رسانی می کنیم :

در ادامه باید از اینکه نصب از منابع Docker به جای منابع پیش فرض Ubuntu  انجام می شود مطمئن شویم :

خروجی باید شبیه به این باشد ، ولی ممکن است که نسخه Docker متفاوت باشد :

دقت کنید که docker-ce هنوز نصب نشده ولی برای نصب از منبع Docker بر روی Ubuntu 18.04 (bionic) انتخاب شده است.

در نهایت ، با دستور زیر Docker را نصب می کنیم :

اکنون Docker باید بر روی سیستم شما نصب شده باشد ، سرویس daemon آن اجرا شده باشد و هنگام راه اندازی مجدد سیستم (reboot) برای اجرای خودکار ، فعال (enable) شده باشد.

خروجی این دستور باید مشابه زیر و نشان دهد که سرویس Docker در حال اجرا و فعال است :

نصب کردن Docker فقط سرویس آن را در اخیتار شما قرار نمی دهد بلکه ابزار خط فرمان docker یا Docker Client نیز در اختیار شما هستند. بعدا در این آموزش درباره خط فرمان docker توضیح خواهیم داد.

مرحله دوم – اجرای دستور Docker بدون Sudo ( اختیاری )

به صورت پیش فرض دستور docker فقط با کاربر root در گروه docker که به صورت خودکار هنگام فرآیند نصب Docker ایجاد شده ، اجرا می شود. اگر بخواهید که دستور docker را بدون استفاده از sudo یا گروه docker اجرا کنید خروجی مشابه به این را مشاهده خواهید کرد :

اگر به هر دلیلی می خواهید که هنگام اجرای دستور docker از sudo استفاده نکنید ، باید نام کاربریتان را به گروه docker اضافه کنید :

برای اعمال تغییرات برای عضو جدید گروه ، یک بار از سرور خارج شوید (logout) و مجددا وارد شوید و دستور زیر را وارد کنید :

در ادامه کار از شما خواسته خواهد شد که رمز عبور این کاربر را وارد کنید.

با دستور زیر مشاهده می کنید که نام کاربریتان در گروه docker اضافه شده است :

اگر می خواهید کاربری را که با آن وارد سیستم نشده اید به گروه docker اضافه کنید ، با دستور زیر کاربر را به صورت مستقیم عضو گروه کنید :

در ادامه آموزش فرض می کنیم که شما دستور docker را با یک کاربر عضو گروه docker اجرا می کنید اگر به هر دلیل نمی خواهید این کار را انجام دهید از sudo استفاده کنید.

در ادامه به توضیح دستور docker می پردازیم.

 

مرحله سوم – استفاده از دستور docker

دستور docker شامل زنجیره ای از گزینه ها (options) و دستوراتی است که دارای آرگومان و ورودی می باشد. قالب دستوری آن به این صورت می باشد :

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

در Docker 18 لیست کامل دستورات زیر مجموعه به این صورت است :

 

برای مشاهده گزینه های (options) قابل استفاده برای یک دستور زیر مجموعه ، دستور زیر را وارد کنید :

برای مشاهده اطلاعات کاملی از Docker ، دستور زیر را استفاده کنید :

در ادامه برخی از این دستورات را بررسی می کنیم. برای شروع از کار کردن با منبع (image) شروع می کنیم.

 

مرحله چهارم – کارکردن با Docker Images

مخزن های  Docker containers از منبع های داکر Docker images ساخته شده اند و به صورت پیش فرض ، Docker این image ها را از Docker Hub دریافت می کند ، که توسط شرکت Docker که تامین کننده آن نیز هست ، مدیریت می شود. هر کسی می تواند Docker images های خود را در Docker Hub قرار دهد ، بنابراین image بیشتر برنامه ها و توزیع های لینوکس که به آن نیاز دارید در آنجا وجود خواهند داشت.

برای بررسی امکان دسترسی و دانلود از Docker Hub ، دستور زیر را وارد کنید :

این خروجی نشان می دهد که Docker به درستی کار می کند :

در ابتدا Docker قادر به پیدا کردن hello-world به صورت محلی (locally) نبوده ، سپس این image را که یک مخزن (container)پیش فرض است را از Docker Hub دانلود می کند. Docker به محض دانلود کردن image ، یک مخزن از آن ایجاد می کند و برنامه اجرا شده داخل مخزن ، پیغامی را نمایش می دهد.

با استفاده زیر دستور search با دستور docker می توانید image های قابل دسترس در Docker Hub را پیدا کنید. برای مثال برای پیدا کردن Ubuntu image ، دستور زیر را وارد کنید :

این اسکریپت Docker Hub را جستجو کرده و لیستی از image های موجود را که نام آن ها با رشته ای که وارد کرده اید ، مطابقت داشته را نمایش می دهد. در این جا خروجی شما باید مشابه به این باشد :

 

در ستون OFFICIAL ، مقدار OK نشان دهنده این است که این image توسط شرکت تامین کننده آن پشتیبانی می شود. هر زمان image ای را که دوست داشتید پیدا کردید برای دانلود آن بر روی سیستم خودتان از زیر دستور pull استفاده کنید.

با استفاده از دستور زیر image رسمی ubuntu را بر کامپیوتر خود دانلود کنید :

خروجی مشابه این را خواهید دید :

بعد از دانلود image ، می توانید مخزن (container) را با استفاده از image دانلود شده و با زیر دستور run اجرا کنید. البته همانطور که در مثال hello-world دیدیم ، زمانی که دستور docker را با زیر دستور run اجرا شود و image مورد نظر دانلود نشده باشد ، Docker client آن را ابتدا دانلود کرده و سپس اجرا می کند.

برای مشاهده image های دانلود شده در کامپیوترتان دستور زیر را وارد کنید :

خروجی این دستور مشابه زیر است :

همانطور که در ادامه این آموزش خواهیم دید ، می توانید image هایی که در مخزن ها (containers) اجرا کردید را ویرایش کرده و image جدید تولید کنید و آن ها را در Docker Hub آپلود کنید.

در ادامه چگونگی اجرای مخزن ها را بیشتر بررسی می کنیم.

 

مرحله پنجم – اجرا کردن یک Docker Container

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

به عنوان مثال یک مخزن را با Ubuntu image اجرا می کنیم. استفاده از ترکیب گزینه های i- و t- دسترسی به پوسته (shell) در مخزن را به شما می دهد :

خط فرمان شما تغییر می کند و این نشانگر این است که در محیط خط فرمان مخزن هستید و شکل آن شبیه به این است :

در خط فرمان جدید شماره id مخزن (container) نمایش داده می شود که در این مثال d9b100f2f636 است. بعدا اگر لازم بود که این مخزن را حذف کنید به این شماره نیاز دارید.

اکنون هر دستوری را می توانید در مخزن اجرا کنید. برای مثال دیتابیس بسته های درون مخزن را به روز رسانی می کنیم. برای اجرای هیچکدام از دستورات نیاز نیست که از پیشوند sudo استفاده کنید ، زیرا شما در مخزن به عنوان کاربر root هستید.

سپس می توانید هر برنامه ای را که بخواهید در مخزن نصب کنید. برای مثال Node.js را نصب می کنیم :

نصب Node.js از منابع رسمی Ubuntu انجام می شود. پس از نصب ، صحت نصب برنامه را بررسی می کنیم :

نسخه برنامه نصب شده نمایش داده می شود :

هر تغییری که در داخل مخزن (container) انجام دهید بر روی مخزن اعمال می شود.

برای خروج دستور exit را وارد کنید.

در ادامه به بررسی مدیریت مخازن موجود در سیستم می پردازیم.

 

مرحله ششم – مدیریت مخازن داکر – Managing Docker Containers

پس از مدتی استفاده از Docker ، مخزن های زیادی را به صورت فعال و غیر فعال در سیستم خود خواهید داشت. برای دیدن مخزن ها فعال از دستور زیر استفاده کنید :

خروجی مشابه به این را مشاهده می کنید :

تا اینجا در این آموزش از دو مخزن (container) استفاده کردیم که یکی از  hello-world image و دیگری از ubuntu image استفاده می کنند. هر دو این مخزن ها الان روی سیستم شما فعال نیستند ولی در سیستم وجود دارند.

برای دیدن همه مخزن های فعال و غیر فعال دستور docker ps را با گزینه a- وارد کنید :

خروج شبیه به این را مشاهده می کنید :

برای دیدن آخرین مخزن ای که ایجاد کردید از l- استفاده کنید :

برای اجرای یک مخزن (container) ای که متوقف شده است از docker start با شماره id مخزن مورد نظر یا نام مخزن استفاده کنید. در اینجا مخزن Ubuntu-base را با شماره ID آن d9b100f2f636 اجرا می کنیم :

مخزن مورد نظر مجددا اجرا شده و با دستور docker ps  می توانید وضعیت آن را مشاهده کنید :

برای متوقف کردن یک مخزن (container) از دستور docker stop با شماره ID آن مخزن یا نام آن مخزن استفاده کنید. در اینجا از نام sharp_volhard که Docker به مخزن داده است استفاده می کنیم :

هر زمان که به یک مخزن نیاز نداشتید می توانید آن را با دستور docker rm حذف کنید ، و در اینجا هم از نام یا شماره ID مخزن استفاده کنید. از دستور docker ps -a برای پیدا کردن شماره ID یا نام اختصاص داده شده به مخزنی که از  hello-world image ایجاد شده ، استفاده می کنیم و آن را حذف می کنیم.

می توانید با استفاده از گزینه name– با اجرا کردن مخزن جدید نام آن را مشاهده کنید. همچنین با استفاده از گزینه rm– مخزن جدید را اجرا کنید ، که بعد از متوقف کردن مخزن ، به صورت خودکار حذف می شود. با استفاده از دستور docker run help لیست کامل گزینه های موجود را به همراه توضیحات می توانید مطالعه کنید.

می توانید container ها را به image تبدیل کرده و container جدیدی را با استفاده از آن image اجرا کنید. در ادامه به توضیح این کار می پردازیم.

 

مرحله هفتم – اعمال تغییرات یک Container به یک Docker Image

وقتی که یک docker image را اجرا می کنید ، مانند یک ماشین مجازی می توانید فایل هایی را ایجاد ، حذف یا تغییر دهید. همه تغییراتی که انجام می دهید بر روی مخزن (container) اعمال می شود و همچنین می توانید آن را متوقف و اجرا کنید ، ولی با حذف مخزن با استفاده از دستور docker rm همه چیز از بین خواهد رفت.

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

این دستور تغییرات مخزن را به یک image جدید اعمال می کند :

گزینه m- توضیحی را ثبت می کند که خودتان و دیگران بدانید که چه تغییراتی را انجام داده اید ، و a- برای مشخص کردن نویسنده می باشد.container_id را نیز به تازگی در آموزش توضیح دادیم که هنگام شروع کار با docker ، چطور آن را به دست آورید. مگر اینکه مخزن اضافی در Docker Hub ساخته باشد که در اینصورت repository معمولا نام کاربر شما در Docker Hub می باشد.

برای مثال برای کاربر sammy با شماره مخزن d9b100f2f636 ، دستور صحیح به شکل زیر است :

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

اگر مجددا image های موجود را بررسی کنید ، image جدید و image  قدیم را که از آن گرفته شده است را مشاهده خواهید کرد :

خروجی شبیه این است :

در این مثال ubuntu-nodejs یک image جدید است که از ubuntu image متعلق به Docker Hub گرفته شده است. تفاوت اندازه نیز این مطلب را تایید می کند. و در اینجا تغییرات Node.js نیز نصب شده است. بنابراین اگر مجددا نیاز داشتید که از Ubuntu همراه با NodeJS استفاده کنید ، فقط کافی است که از این image استفاده کنید.

همچنین با استفاده از Dockerfile می توانید به صورت خودکار نرم افزار را در یک image جدید نصب کنید. که در این آموزش به این مطلب نمی پردازیم.

در ادامه image جدید را با دیگران به اشتراک می گذاریم تا آنها نیز بتوانند از آن یک مخزن (container) ایجاد کنند.

 

مرحله هشتم – قرار دادن Docker Image در منابع Docker

اقدام منطقی بعد از ایجاد image جدید این است که این image را با برخی از دوستان خود یا در کل جهان با Docker Hub و یا Docker های دیگر که به آنها دسترسی دارید ، به اشتراک بگذارید. برای قرار دادن image در Docker Hub یا هر Docker دیگر باید یک حساب کاربر در آن جا داشته باشید.

در این جا یک image را در Docker Hub قرار می دهیم. برای اینکه یک Docker اختصاصی برای خودتان ایجاد کنید این مطلب را مطالعه کنید :

How To Set Up a Private Docker Registry on Ubuntu 14.04

برای قرار دادن image ابتدا وارد Docker Hub شوید :

برای احراز هویت رمز عبور از شما درخواست می شود که باید رمز عبور Docker Hub را وارد کنید. بعد از وارد کردن رمز صحیح و هویت شما تایید می شود.

نکته : اگر نام کاربری Docker شما با نام کاربری سیستم محلی شما که با آن image جدید را ایجاد کردید متفاوت است ، باید برچسب (tag) با نام کاربری ثبت شده در Docker بزنید. برای آخرین مثالی که زدیم به این صورت باید عمل کنید :

سپس می توانید image خود را قرار دهید :

شکل دستوری برای قرار دادن ubuntu-nodejs image  به صورت زیر خواهد بود :

ممکن است که روند آپلود image کمی زمانبر باشد ، ولی بعد از اتمام آپلود خروجی مشابه به زیر خواهد بود :

بعد از قرار دادن یک image ، باید در داشبورد حساب کاربری شما مثل تصویر زیر نمایش داده شود.

docker dashboard

اگر با خطایی مشابه خطایی که در زیر نمایش داده شده مواجه شدید ، به این معنی است که شما به درستی وارد نشده اید :

مجددا با docker login وارد شوید و عملیات قرار دادن image را تکرار کنید. سپس بررسی کنید که image در صفحه منابع Docker Hub موجود باشد.

اکنون می توانید از docker pull sammy/ubuntu-nodejs برای قرار دادن image در ماشین جدید استفاده کنید و با آن یک مخزن (container) جدید ایجاد کنید.

 

پایان

در این آموزش Docker را نصب کردیم و با image ها و container ها کار کردیم و image ای که در آن تغییراتی داده بودیم را در Docker Hub قرار دادیم. در این مطلب مفاهیم پایه مربوطه به Docker را انجام دادیم. 

How To Use Traefik as a Reverse Proxy for Docker Containers on

آموزش نصب و پیکربندی پراکسی معکوس برای مخازن داکر Docker در Ubunutu 18.04

How To Use Traefik as a Reverse Proxy for Docker Containers on Ubuntu 18.04

معرفی

داکر Docker می تواند یک روش موثر برای تولید برنامه ها باشد ، اما آیا می توانید چندین برنامه را بر روی یک میزبان داکر اجرا کنید. از آنجایی که پورت های ۸۰ و ۴۴۳ به همه دنیا ارائه شده است ، برای این کار نیاز به تنظیم یک پراکسی معکوس دارید.برنامه Treafik یک ابزار پراکسی معکوس Reverse Proxy برای مخازن Docker است که دارای یک داشبورد مانیتورینگ مختص به خود است. در این آموزش از Treafik برای ارسال درخواست ها به دو سرویس دهنده وب ، که یکی شامل مخازن وردپرس و دیگری مخازن Adminer است و هرکدام به پایگاه داده MySQL متصل هستند ، استفاده می کنیم. همچنین پیکربندی Treafik به شکلی انجام می شود که تمام سرویس ها در بستر HTTPS با استفاده از  Let’s Encrypt ارائه می شوند.

پیش نیاز ها

در این آموزش به موارد زیر نیاز خواهید داشت :

مرحله اول – پیکربندی و اجرای Traefik

پروژه Traefik در Docker image رسمی وجود دارد ، بنابراین از مخازن داکر برای اجرای Traefik استفاده می کنیم.

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

برای تولید این رمز از ابزار htpasswd استفاده می کنیم. در ابتدا این ابزار را که در پکیج های apache2-utils موجود می باشد ، نصب می کنیم.

برای تولید رمز عبور با htpasswd مقدار secure_password را در دستور زیر با رمز دلخواه خود برای دسترسی به کاربر مدیر admin ، جایگزین کنید :

خروجی باید شبیه به این باشد :

از این خروجی باید در فایل پیکربندی Traefik برای تنظیم احراز هویت پایه HTTP جهت دسترسی برای بررسی وضعیت Traefik و داشبورد مانیتورینگ ، استفاده کنید. این خروجی را کپی کنید ، بعدا آن را جای گذاری می کنیم.

برای پیکربندی سرور Traefik ، باید یک فایل با نام traefik.toml که از فرمت TOML استفاده می کند ، ایجاد کنیم. TOML یک زبان پیکربندی مانند INI است ولی استاندارد شده. از این فایل برای پیکربندی سرور Traefik و یکپارچه سازی ها یا سرویس دهنده های مختلفی که از آنها استفاده می کنیم را پیکربندی کنیم. در این آموزش از سه سرویس دهنده فعال Traefik استفاده می کنیم : api , docker و acmp که از TLS با استفاده از Lets Encrypt پشتیبانی می کنند.

این فایل را با یک ویرایشگر متن باز کنید :

در ابتدا دو نام ورودی http و https را برای دسترسی پیش فرض همه backend ها اضافه می کنیم :

بعدا ورودی های http و https را پیکربندی می کنیم.

در ادامه سرویس دهنده api را تنظیم می کنیم که دسترسی رابط داشبورد را برای شما فراهم می کند. اینجا جایی است که باید مقدار خروجی دستور htpasswd را که کپی کرده بودید ، جای گذاری کنید :

داشبورد یک برنامه تحت وب جداگانه است که بوسیله مخازن Traefik اجرا می شود و ما در اینجا تنظیم کردیم که روی پورت ۸۰۸۰ اجرا شود.

در قسمت entrypoints.dashboard تنظیم می کنیم که چطور به سرویس دهنده api متصل شویم ، و در قسمت entrypoints.dashboard.auth.basic تنظیم کردیم که احراز هویت پایه HTTP برای داشبورد انجام شود. خروجی دستور htpasswd را در قسمت users باید جای گذاری کنید. در این قسمت بوسیله جدا کننده کاما می توانید چندین کاربر را برای ورود تعیین کنید.

اولین entryPoint را تنظیم کردیم ، ولی باید تنظیمات دیگری را برای ارتباط http و https استاندارد به سمت سرویس دهنده api را تعریف کنیم. در قسمت entryPoints آدرس های Traefik و مخازن لیست شده را تنظیم می کنیم. خطوط زیر را در انتهای قسمت entryPoints وارد کنید :

برای ورودی http پورت ۸۰ و برای ورودی https پورت ۴۴۳ با ترافیک SSL/TLS تعیین شده. ما تمام ترافیک بر روی پورت ۸۰ را به پورت ۴۴۳ جهت اجبار در امن کردن ارتباطات برای تمام درخواست ها انجام می دهیم.

در ادامه ، این قسمت را برای پشتیبانی Traefik از گواهینامه Let’s Encrypt اضافه کنید :

این قسمت با نام acme معرفی شده است ، این پروتکل با نام ACME است که برای ارتباط با Let’s Encrypt برای مدیریت گواهینامه SSL است. برای استفاده از سرویس Let’s Encrypt به یک آدرس ایمیل معتبر نیاز است ، بنابراین برای تولید گواهینامه برای Traefik یک آدرس ایمیل در مقدار email به جای your_email قرار دهید. سپس اطلاعات دریافتی از Let’s Encrypt را که در قالب فایل JSON با نام acme.json است را ذخیره می کنیم. مقدار entryPoint به پورت ۴۴۳ که برای ارتباطات https تعیین کردیم اشاره می کند.

مقدار onHostRule  درباره نحوه تولید گواهینامه ها می باشد. ما می خواهیم گواهینامه هایمان را به محض این که مخزن هایی  با نام های میزبان مشخصی ایجاد می شوند، ذخیره کنیم و این ها در تنظیمات onHostRule مشخص می شوند.

قسمت acme.httpChallenge مشخص می کند که Let’s Encrypt چطور می تواند گواهینامه ای را که می خواهد تولید کند را بررسی کند. ما در این قسمت تنظیم کردیم که از طریق ورودی http این کار را انجام دهد.

در انتها نیز سرویس دهنده Docker را با اضافه کردن خطوط زیر پیکربندی می کنیم :

سرویس دهنده Docker برنامه Traefik را به صورت یک پراکسی در مخازن خود فعال می کند. ما آن را به صورت سرویس دهنده watch برای مخازن جدید در شبکه web که به زودی آن را راه اندازی می کنیم ، فعال می کنیم و آن را به صورت زیردامنه ای از your_domain آماده سرویس دهی می کنیم.

تنظیماتی که تا اینجا در فایل traefik.toml انجام دادیم باید باید به صورت زیر باشد :